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  asc Task Type Severity Summary Status Progress Assigned To Due In Version Opened Last Edited
2010User InterfaceFeature RequestLoweffort tracking widgetNew
0%
2.018.07.201518.07.2015 Task Description

If effort tracking started by a user on a task, maybe we should add a small widget on the page, so
user sees which tasks are currently running as his own time tracking.

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.)

2019User InterfaceFeature RequestMediumtitle -tag Waiting on Customer
0%
1.1 devel26.07.201526.07.2015 Task Description

I vote for removing $fs->prefs['page_title'] from title-tag.

Comments welcome!

Explanation:

When the user has many open flyspray tabs, he cannot distinguish them at the first look, because the tab header is filled with redundant information of the systemwide 'page_title' name.

But the browsers also show the favicon.ico of the website (BTW: we need a better one, with some color - and the big webapp icons too for iPhone & co..)
So the user has indication that the tab is a flyspray tab and the page_title text is redundant and wasted space there.

Also search engines could better represent search results if they group together the results from one website. (google shows most relevant pages together if google is sure the whole website is the best search result for the search query (ranked #1)

flyspray> grep -r 'setTitle' *
includes/class.tpl.php:    public function setTitle($title)
index.php:$page->setTitle($fs->prefs['page_title'] . $proj->prefs['project_title']);
scripts/lostpw.php:$page->setTitle($fs->prefs['page_title'] . L('lostpw'));
scripts/newtask.php:$page->setTitle($fs->prefs['page_title'] . $proj->prefs['project_title'] . ': ' . L('newtask'));
scripts/register.php:$page->setTitle($fs->prefs['page_title'] . L('registernewuser'));
scripts/details.php:$page->setTitle(sprintf('FS#%d : %s', $task_details['task_id'], $task_details['item_summary']));
scripts/depends.php:$page->setTitle(sprintf('FS#%d : %s', $id, L('dependencygraph')));
scripts/index.php:$page->setTitle($fs->prefs['page_title'] . $proj->prefs['project_title'] . ': ' . L('tasklist'));
scripts/admin.php:        $page->setTitle($fs->prefs['page_title'] . L('admintoolboxlong'));
scripts/gantt.php:$page->setTitle($fs->prefs['page_title'] . $proj->prefs['project_title'] . ': ' . L('gantt'));
scripts/roadmap.php:$page->setTitle($fs->prefs['page_title'] . L('roadmap'));
scripts/pm.php:        $page->setTitle($fs->prefs['page_title'] . L('pmtoolbox'));
scripts/reports.php:$page->setTitle($fs->prefs['page_title'] . L('reports'));
scripts/myprofile.php:$page->setTitle($fs->prefs['page_title'] . L('editmydetails'));
scripts/toplevel.php:$page->setTitle($fs->prefs['page_title'] . $proj->prefs['project_title'] . ': ' . L('toplevel'));
scripts/newmultitasks.php:$page->setTitle($fs->prefs['page_title'] . $proj->prefs['project_title'] . ': ' . L('newtask'));
scripts/user.php:$page->setTitle($fs->prefs['page_title'] . L('viewprofile'));
2030User InterfaceFeature RequestLowshow votes of a user on user pageNew
0%
12.08.201515.01.2017 Task Description

On the user page

/index.php?do=user&area=users&id=*
or
/index.php?do=user&area=users&id=*&project=1
or
/index.php?do=user&area=users&id=*&switch=1 (project switch select)

an info could be shown how many votes a user has given.

Maybe show the tasks on mouse hover (:hover) if permission to view them exists.

Needs to be considered:

  • Show count only for current project or all projects? (project param is optional on user page)
  • counts of hidden, closed or restricted projects (user permission)
  • How to handle votes of private tasks?
  • Show votes of closed tasks too? (votes on closed tasks should don’t count for max votes per project)
  • When personal “max votes per project” (open tasks) is active, this is of more value.


2034User InterfaceFeature RequestLowreduced extended search form when applicableNew
0%
17.08.201517.08.2015 Task Description

If a project has no versions defined yet and there are also no 'global' versions defined,
there is not need for displaying the version selects.

Same for categories. If no categories in project and no global categories then no need for displaying a cat select.

Maybe a tooltip/hint in the extended search form to inform the user that the fields were hidden for that reason.

2045User InterfaceFeature RequestLowneed add option for can set default Severity and Priori...Unconfirmed
0%
204.09.201504.09.2015 Task Description

need add option for can set default Severity and Priority of new creating tasks

2046User InterfaceFeature RequestLowGrouping in Task List Unconfirmed
0%
104.09.201504.09.2015 Task Description

Need add view of grouping in Task List by Category

2078User InterfaceBug ReportMediumlayout of requested close on small displaysNew
0%
1.026.10.201529.10.2015 Task Description

currently absolute positioning overlapping deny button and not full visible

Possible better solution:

  • cssbased toggle
  • left:50%; width:300px;margin-left:-150px;margin-top:50px;
2083User InterfaceInformationLowDrag and drop tasks on roadmapUnconfirmed
0%
30.10.201530.10.2015 Task Description

On the roadmap it would make life a lot easier if it was possible to drag and drop tasks into versions.

2118User InterfaceFeature RequestLowShow overview of existing tags for usersAssigned
20%
peterdd1.1 devel09.04.201626.10.2019 Task Description

At several places it could be useful to let the user view available tags:

  1. When editing a task a toggle popup could show a list of selectable and existing tags.

I found several nice vanilla-js-multiselect-with-autocompletion scripts, but none yet that still works at a basic level when javascript is turned off.

My plan is now:

  • Keep the current basic input text field for input tags and show current assigned tags like exampletag1;exampletag2;exampletag3 separated by ‘;’ that is sent to the server when saving the task and server handles evaluation of that string (validation, duplicates, removed, added, creating new tags if allowed for current user)
  • A CSS only toggle that shows available tags that can be assigned (works even with js turned off), similiar to other places within Flyspray like advanced search toggle.
  • If js turned off, the user must type the tag - not as fancy, but at least works. (I thought also about using a html select with multiple=”multiple” attribute, but was not convinced due styling not possible in modern browsers without js)
  • If js is enabled, more fancier stuff is possible:
    • The input text field is hidden by display:none and instead the styled tags are shown.
    • The current added tags also get a little x to remove a tag by clicking it. The content of the hidden input text field is updated to reflect the current editing status. (click eventlistener)
    • A generated text input field for typing with autocompletion list shown of matching availbale tags. An unknown tag is added to the list if user is allowed to create tags. Clicking a item in the autocompletion list adds the tag and resets the autocompletion input text field for the next autocompletion action.
    • The tags within the toggle list with all available tags get also a click event listener, so clicking it adds them to the hidden text input.
    • Not sure yet if an added tag should be removed from the all available tags list or just make an CSS indication that a tag is still added, currently I tend to keep the list untouched, just highlight used tags of the task.
  • Optionally make the all available tags sortable by:
    • list_position (default)
    • alphabetic
    • global or project level
    • popularity (count of tasks using a tag (n + unnumbered private)), requires adding a data attribute.
    • group by detected prefix like shape:triangle shape:circle shape:rectangle could show a group of tags as: shape: triangle circle rectangle
  1. Make the list of tags searchable for the advanced search. added with FS1.0-rc10 by just using search key words also for searching list_tags table.
2138User InterfaceFeature RequestVery LowOverhaul dokuwiki editor buttonbarNew
0%
17.06.201617.06.2016 Task Description

Rethink the current sets of buttons and their functionality.

Maybe a mousover hint/cheatsheet of available dokuwiki syntax is more helpful in writing fast and efficient.

  • buttongroup links http,email,ftp
  • buttongroup code, code php: why a single button for php? maybe a cheatsheet or subselect for choosing a language (read directory plugins/dokuwiki/inc/geshi for that). Or even better: Let the project administrator define what source code languages are used/popular in a software project and dependend of that setting prefer/promote that languages
  • I miss a blockquote- or cite-tag for citation, which is more semantic than bold, italic, underline buttons. Update: It is the > character followed by text!
  • Show a cheatsheet (by mouseover?) of dokuwiki smileys as defined at plugins/dokuwiki/conf , update to current config of dokuwiki, facepalm for instance is missing
8-) 8-O 8-o :-( :-) =) :-/ :-\ :-? :-D :-P :-o :-O :-x :-X :-| ;-) ^_^ :?: :!: LOL FIXME DELETEME

8-) icon_cool.gif 8-O icon_eek.gif 8-o icon_eek.gif :-( icon_sad.gif :-) icon_smile.gif =) icon_smile2.gif :-/ icon_doubt.gif :-\ icon_doubt2.gif :-? icon_confused.gif :-D icon_biggrin.gif :-P icon_razz.gif :-o icon_surprised.gif :-O icon_surprised.gif :-x icon_silenced.gif :-X icon_silenced.gif :-| icon_neutral.gif ;-) icon_wink.gif ^_^ icon_fun.gif (not working as first character on a line, bug?) :?: icon_question.gif :!: icon_exclaim.gif LOL icon_lol.gif FIXME fixme.gif DELETEME delete.gif

2139User InterfaceFeature RequestVery LowAdd project setting of popular used programming languag...New
0%
1.1 devel17.06.201617.06.2016 Task Description

This is at the moment just a bit brainstorming ..:

Let the project administrator define what source code languages are used/popular in a software project and dependend of that setting prefer/promote that languages at the dokuwiki editor buttonbar.

This requires probably an additional database field in the flyspay_projects table (if just used for dokuwiki that should be ok)

If thinking further like Filter me all software projects that may ontain CSS code on the projects overview, a m:n-table setup is thinkable. But thats maybe overengineering..
Or can we use the existing tag-feature for that and just ‘tag’ projects with tags?

2193User InterfaceFeature RequestLowEdit a comment while seeing task details and other comm...New
0%
07.08.201608.08.2016 Task Description

If someone with ‘edit comment’-permission wants to edit a comment, the edit comment form is shown on an extra page.

This is not optimal, because the editor cannot see task details or the other comments while modifying the comment.

Possible Solutions

  • with javascript is enabled: Stay on the ‘task detail’-page, just the comment changes from a ‘view’ layout to ‘edit’ layout, similiar to the quickedit-feature (like in FS1.0).
  • when javascript is disabled: The ‘edit comment’-page shows task details (check permissions) and other comments too, but maybe a bit narrow, so ‘visible focus’ is on editing the comment.
2200User InterfaceBug ReportMediumIncomplete list of timezones available in the user pref...Unconfirmed
0%
26.08.201626.08.2016 Task Description

The user preferences and the add new user screens both allow you to set the timezone offset of the user, however, we are only provided with whole hour offsets from GMT. This makes it impossible to select our timezone here in India, which is GMT+5:30 - IST(Indian Standard Time - Asia/Kolkata as per TZ Zoneinfo). In addition, there are also timezones in the GMT+x:45, which wouild also require to be handled. Note, this is totally independent of DST Changes, since some of the countries use DST(Like in Australia) and others do not(Like India).

Here is a link with more details of the same - http://www.timeanddate.com/time/time-zones-interesting.html

I will be trying to identify and fix the codebase to resolve this, and will hopefully have a patch to submit soon.

Regards
R. K. Rajeev

2548User InterfaceFeature RequestLowCSS grid layout for task details page typeNew
0%
05.05.201905.05.2019 Task Description

Layouts from 320 pixel mobile portrait, tablet sizes and up to 4k monitor landscape mode using

@media queries

Mockups required not only for different sizes, but also different project configurations, user permissions, and task relations.

Should look ok whatever project configuration is done or how weird a task description is.

On wider screens the comments could be beside the task description for instance.
Or some tabs or menus could be shown directly instead of grouping in the tabs.

2549User InterfaceBug ReportLowOauth register template always shows "Username already ...Unconfirmed
0%
06.05.201906.05.2019 Task Description

RC9 running on CentOS LAMP stack

Steps done to create the problem:
Set up google as an oauth provider.
Have a user click “Sign in with Google” in the login box.
User connects their account with Flyspray.
Google redirects the user back to Flyspray
The return screen (on flyspray) asks for a username.

Expected behavior:
No warning about duplicate username should be shown on initial page load since no username was entered yet

Experienced behavior:
A warning about the username being already taken is shown.

It appears there is no logic for showing or hiding that warning in register.oauth.tpl

(It would be great if flyspray was able to just use the email as a username to make the UX even better/simpler.)

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

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.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.

1999XMPP/JabberFeature RequestMediumjabber xmpp configurationNew
0%
8122.06.201511.02.2017 Task Description

There should be some help at the configuration sections for setting up jabber/xmpp notifications.

How someone can test it?

Must the admin setup his own jabber/xmpp server or are there recommended servers?

I registered with psi+ instant messager as peterdd@ubuntu-jabber.de at ubuntu-jabber.de for testing
and configured it here in my account too, but got no jabber messages.

Email notifications works and I set up both sending.

2020XMPP/JabberFeature RequestMediumFunction to test jabber/xmpp configuration New
0%
1.1 devel1131.07.201519.09.2015 Task Description

The flyspray admin users should be able to test their jabber/xmpp configuration, check if sending jabber notification is working and if not, give useful error messages back, so the user is able to fix the configuration.

Showing tasks 301 - 323 of 323 Page 7 of 7

Available keyboard shortcuts

Tasklist

Task Details

Task Editing