Flyspray - The bug killer!

• Use github releases for the release? peterdd: Yes, currently only source releases without 3rd party vendors.

The Flyspray 1.0alpha1 .zip file release unzips directly to the current directory.

.zip files from github unzip to it’s own directory (flyspray-master.zip unzips to flyspray-master/ ). This is a bit safer, because you cannot accidently mess your directory structure with it.

• The release should contain the binary fontawesome files instead of linking to the external CDN. Removes one dependency/singlepointoffailure. How this can be configured for automation? included in Flyspray source now.

• document how a release is exactly created. (consistency, reliability, automation, knowledge sharing for maintainers see below )

• Get in contact with os distributions, that could add Flyspray releases to their repositories (*BSD, Linux distributions, ..) This repositories could add the dependencies like ADODB within the packages (.rpm, .deb,..)

• Get in contact with web hosting providers who provide integreated 1-click installs of software for their web hossting customers.

• Get in contact with container builders (docker, ..)

Steps how to do a Flyspray release (since Flyspray 1.0 RC)

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

It's old. There has been a newer version 2.0. Even that one is not supported anymore, although some documents still remain available. The calendar component relies on its language translations files to be complete, or it breaks. Unfortunately, as I found out a few weeks ago, they are not, after switching the default language from english to my native one. Without having a good replacement for it, some of the translations for flyspray itself we've been getting lately are half-way unusable. Not for an ordinary user, but for anyone actually having to edit a task and its due date.

Got "wrong token" on creating a task whose form were open for a while in browser tab.

That means probably the session timed out on bugs.flyspray.org, so the anti csrf token doesn't existed anymore on the webserver.

It would'nt be a big problem if the browser backbutton works showing the ready written form again, but it was empty.

One solution would be temporarly storing it offline in the browser storages which are available with html5. But open for other simpler solutions..

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.

Thomasz wrote:
The other thing that I cannot find how to make the text to be visible in the whole column (as with the summary I get the ... at some point of the text).

The root of this is found in scripts/index.php in function tpl_draw_cell():

case 'summary':
            $value = tpl_tasklink($task, utf8_substr($task['item_summary'], 0, 55));
            if (utf8_strlen($task['item_summary']) > 55) {
                $value .= '...';
            }
            break;

We live in a world now, where the view port ranges from 320 pixel width mobile screens up to 4k+ wide tv screens, the amount of columns is configurable from minimal to all available fields of a task. We currently let the browser automatic decide how wide he renders each column depending on table content and available window size.

Well, that ellipsis problem can be handled at different levels:

• motivate the task creators to use short task summary if possible (e.g. show a hint/tooltip when typing the summary gets over a limit, in our case the hardcoded limit is 55. ). Short task topic/summaries are easier to read/scan for the users.
• replace the hard ellipsis by a pure css solution, that adapts to users browserwindow size/space in in the columns for summary
• drop the ellipsis thing complete, task summary always shown full length, table rows adapt in height automatically.

Possible CSS solution:

• text-overflow now works in all big browsers. For instance see http://stackoverflow.com/questions/2108740/how-do-i-indicate-long-text-into-a-smaller-fixed-column-with-css
• Combined with :hover on the shortened summary the full summary can be shown without the list table starting to flicker/resize.

One of my task has 8.9166666666667 days left. This is very very very very accurate !

A rounding would look better !

Running Alpha2 now, Cannot use this on 'reported version' here on this site

Edit: Rounding is adhoc fixed on 2015-06-21 in dev in template file, but code should IMHO be centralized, not template, see comments

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.

This could be done by a textarea field (like comment text or task description) on the myprofile page and stored in a new field (of type text for instance) in the user table.

This allows the user to introduce himself to the other users.

Should be restrictive, for instance only simple text allowed, no html or tags.

I see php deprecation notices with php 5.6+ from the geshi syntax highlighter plugin of dokuwiki plugin sometimes. (seems to be go away on the second view, so probably not seen on cached views)

It can't be found easy with

grep -r preg_replace | grep '/e'

Because the preg_replace modifiers are added dynamic depending on the target programming language. At least in the version we have in flyspray.

The Flyspray Manual ( http://www.flyspray.org/manual/ ) does not even hint of it, and as long as i am not logged in there's no indication anywhere in the interface that i would eventually get to do it after i manage to log-in.

In fact, i've come here to learn how to use your software, considering the fact that the site where it was deployed did not provide much help. And after i logged in into that site ( http://www.uzbl.org/bugs/ ) i still don't see any "add new task" option. That's IMO a discover-ability fail, and it originates in your own design: disabled features should not be hidden, lest users think you didn't bother to code such features. Also, you say i shouldn't report bugs against versions earlier than 0.9.9.7, but how do i know which version of Flyspray are they using?

There are 5 possible cases that IMHO should be handled more user friendly:

1. There is no cronjob for the reminder (schedule.php) setup → Reminders are never sent
2. Reminding is disabled in the global settings → Reminders are never sent
3. Reminder setting 'email' only → Reminders are only sent to users who set their notification setting to 'email' or 'both' and setup an email address
4. Reminder setting 'jabber' only → Reminders are only sent to users who set their notification setting to 'jabber' or 'both' and setup a jabber address
5. Project notification setting not set → ??? (research...)

• If notification is disabled (1. or 2.), the notification tab on 'task details page' should adapt to that I think. (by css style or message or tooltip)
• If notification is restricted to only one notification channel, the current user should be informed on notification tab on 'task details page' if he would receive notifications with his current notification settings.

Some project and user settings should be able to set back to its default or 'auto' option.

• flyspray or project wide task list length, currently hard coded to 250
• user tasks_perpage setting
• user notifytype
• user timezone
• user language (system/project and auto (browser detection) selectable)
• ...

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.

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

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'));

Keyboard navigation is not documented

grep -r 'accesskey' *

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

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

Section names in these pages

Task view page

Toplevel project overview /dashboard

New Task page

Reports page

Roadmap page

MyProfile page

My company maybe changes to a MS SQL Server backed ERP.

In this case it could be nice to have Flyspray customized as CRM working on the same database for integration with ERP.

Well, currently just an idea.

Currently the appearence of the task list table is configured system wide for all project view and project wide for project task list views.

Even more fancy and for power users would be if the user can set his own project column list view preferences for projects.

While the project columns for the task list are configured by "visible_columns"
we could use the project wide "visible_fields" as allowed columns the user may configure as his personal preference. If the user doesn't configure his own list, the project default list is used. The user should have the option to reset to project default. (e.g. empty personal "visible_fields" )

In this case the description for setting "visible_fields" on the project management configuration page must be adapted too.

Probably a new table required something like:

CREATE TABLE {user_projects} (
user_id int,
project_id,
columns varchar(255) DEFAULT '',
);

or

CREATE TABLE {user_projects} (
user_id int,
project_id,
columns varchar(32) DEFAULT NULL,
sort int,
);

Tags can only be added on the "new task" page, not managed on the "edit task"-page.

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.

Currently only a small portion of adjustements on a task is available in the “edit task” view.

To add or modify stuff in the current tab sections (comments, related tasks, notifications, effort tracking,..)
a user must go from edit task to view task page.

This not optimal for work flow.

To solve this quite much changes are needed. Because currently they are different http requests each with its own checks and request anwsers.

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.

I find it irritating to have the oldest activity on the right side and newest activity on the left side of the small activity bars.

There is also no time scale description. This could be added by showin it on :hover to keep the simple appearance.

A complete new feature would be to replace the image generation by rendering the bars in the html in the same request, e.g by inline svg or canvas element. This would enable adding some interactivity with the activity bars..
A related feature request is FS#1991 (project progress)

Currently it seems a user needs two accounts
to login by normal user-password and oauth2 login with facebook,g+ etc.

Better would be if a normal username-password registered user could connect a oauth2-login with his existing login.