Flyspray - The bug killer!

This is the Bug Tracking System for the Flyspray project. This is not a demo!

2019-04-22: Flyspray 1.0-rc9 released See https://github.com/Flyspray/flyspray/releases

ID Category Task Type  asc Severity Summary Status Progress Assigned To Due In Version Opened Last Edited
2062User InterfaceTODOLowreview do=admin&area=editallusersNew
30%
329.09.201515.04.2020 Task Description

Bugs

  • Small javascript issue: When checkbox of one users row clicked, it doesn’t select the checkbox because the row click event handler doubles the click (check and uncheck, tested with firefox41). Clicking in the row (not on the name) selects the checkbox. fixed
  • browser back button after delete of a user not working as expected. (fix it by redirect 303 , see modify.inc.php how it done for other form submits)

Missing features

  • no sorting possible of the table (like tasklist)
  • no pagination (like on tasklist) OK, probably not needed: ~2000 user registrations on bugs.flyspray.org and no problem rendering the table in browser. Archlinux has over 12k users and my test with 30k generated users showed problems handling the huge query results. So we need this!
  • no filtering of user list possible
  • no helpful information for admins like registration date and last time of login of users (last login time requires a new field in flyspray_users) implemented in Flyspray 1.0-rc7
  • no summary about users like how many exists or how many are currently online (requires storing sessions in a db session (e.g. flyspray_session) table instead php default session directory) on the install. Or a statistic graph of activity or peaks of new registrations over time.
  • maybe show user profile image too in the list.
  • choosable user field columns - partially implemented since 1.0-rc7 by selecting groups of user fields and calculated user fields: user stats, user settings
2586Backend/CoreTODOLowPHP7.4New
50%
peterdd1.0-rc10312.12.201918.02.2020 Task Description

PHP 7.4 is out now and a few things should be done to make Flyspray work well with it.
Nothing really breaks, but a view deprecation warnings should be fixed.

Flyspray source itself: Just a few new notices, most are yet fixed in the master branch.

Watching the PHP7.4 compatibility of dependencies defined by composer.json:

  • ADOdb/ADODb: 5.20.15 should be OK for Flyspray
  • swiftmailer/swiftmailer: We still use 5.* branch, so either do quickfix for a notice in a fork or upgrade/rewrite our integration to the 6.* branch.
  • ezyang/htmlpurifier: 4.12 OK
  • thephpleague/oauth2-client: unknown, we still use 0.13, last real source change was Nov 2018, to upgrade requires rewrite of integration into Flyspray and there is low demand for OAuth2.
  • dapphp/securimage: seems to be OK
  • jamiebicknell/sparkline: OK, but probably obsolete for us in future due
    • still annoying problems with our github/travis tests (problem of travis, not sparkline itself)
    • better solution (interactive hover infos, scales, screen size adaptive) by Flyspray source planned
1973Backend/CoreTODOLowurl rewritePlanned
80%
1.1 devel214.03.201511.02.2016 Task Description

Well, it needs a cleanup, per example:

fixed now http://127.0.0.1/flyspray/task/3?project=1

That should be something like:

The actual one is actually half a rewrite and half a GET version

1981Backend/CoreTODOLowUnify event logging and notificationsConfirmed
0%
1.1 devel220.03.201522.03.2015 Task Description

They are currently two separate mechanisms. Shouldn't be so. Events happen always, notifications when someone should be or have chosen to be notified about those events.

Besides, the current code is just a total mess that should be fixed/rewritten anyway, and we unfortunately also overlooked during the development phase 2 things: one new table, users_emails, and the fact that the user is now allowed to give several email addresses separated by a semicolon.

2114TranslationsTODOMediumStandardize the priority meaning across flyspray transl...New
0%
207.04.201626.03.2018 Task Description

Standardize the priority meaning across flyspray translations.

Idea:

0 - priority unset (database field default value)

1 - defer (or very low priority, often results the task is defered, see “Eisenhower principle”)
2 - low
3 - normal
4 - high
5 - very high

6 - flash (house burns, catastrophic event, website down, “boss” decision)

Some other software (other task planers/ email programs) use a 1-5 step priority. So an export feature to other software may merge priority 6 to priority 5 for such software.

In 2012 meaning was changed only in english translation.

Before normal was priority 2 in a 1-6 range, after it is priority 4 in a 1-6 range.
It should be IMHO 3 in that 1-6 range.

2143TranslationsTODOVery Lowjscalendar: week start should be monday, ISO 8601Confirmed
10%
201.07.201603.03.2019 Task Description

The current jscalendar shows sunday as the first day of the week by default.

Could be modified for a language by adding

// First day of the week. 0 means Sunday, 1 means Monday
Calendar._FD = 1;

js/jscalendar/lang/calendar-XX.js

See also https://github.com/Flyspray/flyspray/commit/f7831b7f6845e237b79da2a68d475f21a24fff72#diff-70a18ca66e215fc5aa282d4c58fed4ab

It should default to Monday as defined by ISO 8601.

https://en.wikipedia.org/wiki/ISO_8601#Week_dates

https://en.wikipedia.org/wiki/Week#Week_numbering

2553User InterfaceTODOLowintelligent accesskey shortcut helper dependent of OS, ...New
50%
106.06.201929.07.2019 Task Description

The HTML accesskey attribute feature is differently accessible dependent of operating system, web browser and web browser configuration, and users keyboard layout and user language.

By taking advantage of the User-Agent HTTP header value provided by default by web browsers, Flyspray could better know of what kind of keyboard and browser the user sits in front off and show the key combinations for the accesskey feature that best fits the users environment.

2573Backend/CoreTODOLowadd rel nofollow,ugc,.. settingsNew
20%
peterdd114.09.201915.09.2019 Task Description
  1. Find a good configuration name just reuse relnofollow as used by dokuwiki
  2. Find a good translation keyword for that config relnofollow
  3. Find a good translation keyword for config description (title attribute)

Goes into prefs table as it is sitewide configuration.

As first implementation a simple checkbox should be ok. Should be on the tab with other spam handling stuff like captcha configuration.

Is enabled by default (1).
Adapt setup xml files, upgrade procedure.


	
2008User InterfaceTODOLowdifference between related tasks and related linksNew
0%
18.07.201518.07.2015 Task Description

It should be made clear to the user what related links are in the
"new task" and "edit task" form and what a user should input in these fields.

2016User InterfaceTODOMediumheading and h1, h2, h3New
0%
1.1 devel23.07.201523.07.2015 Task Description

We should change the document logic a bit here. For public projects search engines like well structured pages more then others. And we get a consistent structure too in future for Flyspray.

This I have in mind

Project area name ("All Projects" or "Project name")

  • Currently: h1-tag
  • My wish: not a h1-tag anymore here

Admin setting / Project setting pages, title of the sub pages

  • Currently: h3-tag!
  • My wish: h1 tag

Section names in these pages

  • Currently: h4-tags
  • My wish: h2 tags, subsubs then h3,...

Task view page

Task name=summary

  • Currently: h2 tag
  • My wish: h1 tag

Task descriptions then can use structuring their task description starting as h2,h3,h4 (done by dokuwiki renderer for example)

Toplevel project overview /dashboard

  • Currently: h2 for each project name
  • My wish:
  • * keep h2 for each project name
  • * h1 for the page heading (maybe hidden by css)

New Task page

  • Currently: h2 for summary and tags. Wrong logical nesting!
  • My wish: drop the h2 for form field labels

Reports page

  • Currently: h3 tag
  • My wish: h1 tag

Roadmap page

  • Currently: h3 tag for each milestone
  • My wish:
  • * h2 tag for each milestone,
  • * h1 tag for heading (maybe hidden by css)

MyProfile page

  • Currently: h3 tag for each section
  • My wish:
  • * h2 tag for each section
  • *h1 tag for heading (maybe hidden by css)

(Sure the theme.css must be adapted to this change.)

2039Installer and UpgraderTODOLowReview INSTALL, README, documentation files for release...New
30%
1.023.08.201509.04.2016 Task Description

Check if the install, setup and upgrade instruction are correct:

  • dev/github versions (using composer for dependency resolving)
  • release versions (using composer or complete bundled binary releases containing all dependencies (ADODB, oauth2, ..)
2554User InterfaceTODOLowkeyboard shortcuts help box should adapt to current pag...New
0%
06.06.201906.06.2019 Task Description

The shortcuts help infobox should adapt to the current page type.

So when in editing a task for instance, the n (next task) and p (previous task) shortcuts are not available for a good reason. Listing them there with same priority as other keys then is not helpful.

The simpliest solution is probably putting some if-statements depending on the $do variable into CleanFS/templates/shortcuts.tpl ..

2572User InterfaceTODOLowadd link attributes ugc and nofollow to user generated ...New
0%
13.09.201913.09.2019 Task Description

no task description

2585User InterfaceTODOMediumUpgrade CKEditor to 4.13New
0%
peterdd02.12.201917.02.2020 Task Description

To fix some other open tasks, an update of the CKEditor4 files is probably the best way.

Starting with CKEditor4 ‘Basic’ preset, evaluate every additional Plugin before adding them to the config.

Because the selection of plugins starts with the ‘Basic’ preset, some configs are disabled in the resulting config.sys like the ‘Strike’ button or the Copy/Paste functionality.

I am also evaluating the possibilities to make some of the options configurable within the Flyspray configuration. It is probably required to analyze if a setting applies to only CKEditor syntax or would be also by used for installs using dokuwiki syntax/engine.

I can also imagine enable/disable features based on Flyspray user permissions. (but that requires not only CKEditor config, but also server side changes like HTMLpurifier settings.)

Languages

Just choose all languages available in the CKBuilder.

Probably we need to adjust the CKEditor to use the users Flyspray language settings too. I changed my language to french in a test install but the CKEditor still shows german user interface. (probably detected by browser http request headers)

Compare that the used language abbreviations work together between files in lang/ of Flyspray and that of CKEditors. (Flyspray: lang/pt_br.php vs. CKEditor: js/ckeditor/lang/pt-br.js)

Theme selection

Probably use a CKEditor source maintained Moona-Lisa or Moona as these are easier to modify their color themes like auto light/dark mode browser detection or base colors that match the theme.

Moona Color currently has issues and not maintained by CKEditor guys.

Plugins

The previous contained CKEditor 4.4.7 probably hat the standard preset used.

Following I keep track of plugins we should add to the basic preset. This list is growing/edited until the final config that ships with Flyspray is found.

Mentions

This would enable choosing a user by their username, like @peterdd.

Requires writing an extra php file for retrieving a matching list of users, that respects current user permissions and status of users (like not fetch disabled users).
This extra php file could be also used for the editor textareas with a dokuwiki toolbar.

Auto Grow

This is just a promising usability improvement. No scrollbars needed when writing longer texts.

Turns just typed urls like https://www.flyspray.org into real links (like dokuwiki does it when rendered on page.)

Baloon Toolbar

This just sound like a promising usability improvement. Not tried yet. Only add when there is use case (other plugins usability profit from it) for Flyspray.

Blockquote

Probably required because existing Flyspray installs had it too and citing a comment/text snippet should be also able.

Code Snippet

Probably requires deeper look how secure integrate with server side cleanup (HTMLpurifier).

Format

h1-h6 and other tags. Probably required as previous Flyspray versions used that too. (TODO: What happens to old content with h1-h6 tags when editing with a CKEditor without the Format plugin?)

Also configure it to accept only tags useful for within Flyspray. (see also server side configuration of HTMLPurifier)

Remove Format

Existing Flysprays had this too and probably a good thing when the user can cleanup their word/whateverwhere pasted stuff cleaned before HTMLpurifier does it server side too with maybe surprises to the end user.

Show Blocks

Gives the user some confidence on command if his current editing has the right/intended structure.

Well, that missing is one of the reasons why I hated WYSIWYG or wannabe WYSIWYG editors in the past. Uncertainty by the end user, and pain for the admin/webmaster when he sees the garbage stored in the database (endless spans and other garbage tags partly wrong nested by just pasting from Word documents.)
(little bug in CKEditor 4.13.0: doesn’t expand the area with plugin Auto Grow enabled)

Source Editing Area

Useful for people that can read HTML or are responsible to fix things.

2587Backend/CoreTODOMediumdisplay_errors=1 should not set in release candidateUnconfirmed
0%
18.12.201918.12.2019 Task Description

display_errors = 1 should not set in include/fix.inc.php for releases or releases candidate, because with this it is not possibele to disable the error reporting globaly.

The problem is, if I want to enable full error reporting to logfile via “error_log=…” in php.ini, then the error will also full reported to user. Full error reporting is a hig risk for security.

Did you installed an official release or did you used an inoffical docker?!
flyspray-1.0-rc9

Steps done to create the problem:
Create a file php.in in base directory with follow contens:
error_reporting = E_ALL | E_STRICT
log_errors = On
display_errors = Off
error_log = /var/log/php-flyspray-errors.log

Expected behavior:
Errors only to log file

Experienced behavior:
All errors goes also to user.
The option “display_errors = Off” has no effect.

2594Backend/CoreTODOHighpagination of user listAssigned
50%
peterdd1.0-rc1023.02.202012.04.2020 Task Description

For Flyspray installations with many users (several thousands) a pagination of the user list in the admin area is required.

2000 users no problem to display (aside the PHP max_input_vars limit which is only 1000 by default, so maybe not all checked checkboxes are handled.)

More users might send your mysql to long running blocking queries creating temp tables … bad!

(I killed them by watching show processlist; and kill id; on mysql console.)

Showing tasks 301 - 316 of 316 Page 7 of 7

Available keyboard shortcuts

Tasklist

Task Details

Task Editing