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 Severity Summary Status Progress Assigned To Due In Version  desc Opened Last Edited
2577User InterfaceFeature RequestVery Lowdistinguish between anonymous reporter and deleted userNew
0%
18.10.201918.10.2019 Task Description

When a user is deleted from Flyspray, their opened tasks, closed task and task comments are then shown as Anonymous Submitter, the same way as anonymous reporters (not really anonymous, just that user does not have login account, but usually their email address is stored within that task data).

Currently just the entry from users table are deleted when a user is deleted. Their internal user_id integer is still within tasks and comments fields, and maybe some other tables too. So there is not a ON DELETE SET NULL rule or something like that applied. As it is just an autoincremented number by the system, this is not personal data imho and should be no problem for GDPR, but gives Flyspray the ability to distinguish between anon reporters and deleted users. Well, we could also look if there is an email address within task table entry for notification of anonymous reporter, but there are also tasks possible that have no user_id nor an email address.

It might by useful to present that information differently like deleted user or showing the info differently like icon + title-tooltip with explanation.

Also interesting what happens with mentions of a deleted username in a comment or task description. (see FS#2322)

The user isn’t in database, but deleting that now gone user should not modify tasks or comment where that username was mentioned I think.
But what if another user registers under that now gone username? In that case that new user would inherit that mentions. Probably we can ignore that edge case as there will be not much things will happen with an old mention in old tasks/comments.

2581User InterfaceFeature RequestLowreplace bitmap icons of default themeNew
0%
31.10.201907.12.2019 Task Description

I played with adding a dark mode color theme to the default CleanFS theme.

To make the dark theme just simple exchange some colors, the bitmap icons should be replaced with alternatives.

Easiest would be using the fontawesome font icons as Flyspray still uses them and they can simply get a css color assigned.

Examples

  • caret of tasklist
  • the ‘select all’ icon of tasklist, but also used at some more locations.
  • some icons in the Flyspray main toolbar (Overview, Tasklist, Event log, ..)
  • the black calendar icons for date selects
  • maybe the file type icons for attachments

Editors

  • Dokuwiki toolbar
  • CKEditor: some modern CKEditor themes support color/dark mode, I will probably choose the moona-lisa theme as default.
2585User InterfaceTODOMediumUpgrade CKEditor to 4.13.0New
0%
peterdd02.12.201903.12.2019 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.

Showing tasks 301 - 303 of 303 Page 7 of 7

Available keyboard shortcuts

Tasklist

Task Details

Task Editing