Flyspray - The bug killer!

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.

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.

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

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.

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.

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.

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.

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

Just moved issue #110 from https://github.com/Flyspray/flyspray/issues/110 to here for centralized task tracking.

Maybe just needs testing with current github master.

As discussed with the team some time ago, a consolidation of places where issues are discussed is wanted.

One of the results was, that we do not want people post issues to github.com Issues and instead use our own bugs.flyspray.org
and to prefer "to eat our own dogfood" and a have central place to handle tasks.

As a result we tried to reduce the open issueas on github.com. I was in the process of moving 2 of still 7 open issues there to bugs.flyspray.org when suddenly the Issues on github.com were closed. Now the last 5 issues there are lost at the moment for me and the audience, which where mostly informations to interested users, not bugs.

I think just closing it without an easy accessible alternative is not the best solution.

At least we should wait until the oauth2 authentication for github users should be implemented and setup on bugs.flyspray.org , so people browsing github.com, finding Flyspray project just can
"Login with github"-feature on bugs.flyspray.org.

The blocker to do this: Currently there is missing an option to "connect" an oauth "Login with github"- Login with an existend flyspray userlogin.

So that one userid in flyspray can:

• login with username and password
• login with one or more of his social accounts (github, facebook, microsoft, g+) if they are enabled (would it restrict to github.com accounts for bugs.flyspray.org)

We have no API yet for Flyspray.

But someone could write a simple php-file that can be called by a github.com auto notification, whenever:

• a commit on github.com for Flyspray/flyspray is made

Github.com provides the configuration of such notification for a possible target like

https://bugs.flyspray.org/api/github.php

or

https://bugs.flyspray.org/api/github.php?project=1

in the settings of a project.

What the file needs:

• import some of the existing Flyspray classes from includes/
• config or load the secrets that are provided by github.com in the setup for the automatic notification
• check that secrets and more for authentication and authorization of requests coming from github.com
• parse the messages for Flyspray identifiers like ' FS#1234 ' or 'fix  FS#1234 ' or 'related to  FS#1234 '
• take actions on the results of that message parsing like making adding comment or modifying a task status

Currently on

• do=pm&area=version
• do=pm&area=os
• do=pm&area=resolution
• do=pm&area=status
• do=pm&area=tags
• do=pm&area=tasktype

a count of usage in tasks is shown for every property.

Interesting would be if the counter shows the count for open/closed tasks on each row.

I wanted edit/fix the comment of an anonymous reporter, but the edit shows empty content on editing..

(here on closed, but non yet implemented  FS#218 )

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;

My tests showed that the html accesskey feature is not well and consistent supported by current web browsers and is quite cumbersome to use.
And it seems it will not be better in future..

The only solution I see dropping that feature or replacing them with simple single-key-event javascript listeners, like it is currently done with keys o, j, k, n, and p.

accesskeys in Flyspray I talk about:

• l (current SHIFT+ALT+l Firefox) login dialog / logout
• a (current SHIFT+ALT+a Firefox) add new task
• m (current SHIFT+ALT+m Firefox) my searches
• t (current SHIFT+ALT+t Firefox) focus taskid search
• e (current SHIFT+ALT+e + Enter Firefox) edit task
• x or y? (current SHIFT+ALT+y Firefox) close task
• s (current SHIFT+ALT+s Firefox) save task

Also related to Keyboard navigation: tabindex

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

icon_cool.gif icon_eek.gif icon_eek.gif icon_sad.gif icon_smile.gif icon_smile2.gif icon_doubt.gif icon_doubt2.gif icon_confused.gif icon_biggrin.gif icon_razz.gif icon_surprised.gif icon_surprised.gif icon_silenced.gif 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 icon_lol.gif fixme.gif delete.gif

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?

Flyspray should show a warning, and maybe set the focus back to the field (only when it is a this-one-field-only-form.)

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

Notice: Only variables should be assigned by reference in /*/setup/index.php on line 883 
Notice: Only variables should be assigned by reference in /*/setup/index.php on line 949

There is a request for cloning a project on Flyspray mailing list:

Would be a very welcome features to have Project Templates for repetitive workflow. Any idea if its in the pipeline?

Thanks

Well, not yet.

The question is, how exactly you want that project clone.

Do you want just a rough copy of the project table entry?
Thats quite easy and can even be done without programming or writing a line of SQL just by using PHPMyAdmin (or similiar Tools for PostgreSQL) and copy a row of the project table for example.
See yellow marked project table on the right of the attached dbschema screenshot.

The other extreme is copying every project depending list table entries to new ones.
This sure requires some programming, but not too hard to add this to Flyspray. (all yellow marked tables in the attached dbschema screenshot.

I attach a rough form mockup how could this could look like.

Possible solution

There is a wish on the Flyspray mailing list:

Is there a way of hiding the TAGS input field from the Add New Task form?

Alan

If it is just hiding on that form, there are several options to achieve this (from simple to complex)

A) Hide by CSS

#edit_tags{display:none;}

B) Hide by CSS (better)

#edit_tags{display:none;}

D) Edit themes/CleanFS/templates/newtask.tpl directly

E) Use a custom template

D) Nag or caress someone

I’ve tried inserting an image in the intro message but it doesn’t show. Is there something broken in the formattext.inc file? Seems unlikley because it’s so old but can’t work out why nothing shows.

Alan

I had to disable some parts last year within dokuwiki quickly due sever reported security issues in that area.

As tradeoff embedding images currently don’t work within dokuwiki textareas in Flyspray.

As I too wish that feature reappear working for my projects, this is on my personal list. But requires focused free time because must be made secure.

Maybe instead of using fetch.php of dokuwiki, we can use Flypsray’s ?getfile=id , which also checks permissions.
But must check also securly file types and maybe resize images to fit into the desired page (thumbnails).

Quick anwser: enable swap partition on your server.

Tried upgrading a rc4-dev to rc5-dev/rc6/flyspray-master on a virtual server with 500MB RAM and php5.6.30 on the commandline (debian)

After file upgrade, I wanted also update the vendor stuff according to composer.json changes.

But surprisingly this failed:

php composer.phar update

and also after

php composer.phar selfupdate

to version Composer version 1.5.2 2017-09-11 the memory limit bug exists:

The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details

PHP Warning:  proc_open(): fork failed - Cannot allocate memory in phar:///var/www/***/composer.phar/vendor/symfony/console/Application.php on line 979

Warning: proc_open(): fork failed - Cannot allocate memory in phar:///var/www/***/composer.phar/vendor/symfony/console/Application.php on line 979

  [ErrorException]
  proc_open(): fork failed - Cannot allocate memory

Also doing a more fresh vendor install like

rm composer.lock
rm vendor/*
(keeps the .htaccess there)
php composer.phar install

300 MB not enough for a handful of php package installations? wtf, but didn’t dig deeper..

I temporarly solved the problem by making a swap partition on this vServer like suggested at
https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
chmod 600 /var/swap.1
/sbin/swapon /var/swap.1

free
             total       used       free     shared    buffers     cached
Mem:        506300     374920     131380      30628      21904     143872
-/+ buffers/cache:     209144     297156
Swap:      1048572          0    1048572

This is just documentation and is for the people who prefer a Flyspray development version from github.com

Full Flyspray release download files do not needs to fiddle with composer.

Maybe an entry for the FAQ

Currently the category_id is not checked if the value is legal for the project when a new task is created.

• must be unsigned int
• must be an active category_id of the project or global category.
• setting a category_id must be allowed - see project settings.

If invalid category_id is sent, deny creating task and show error message and show filled form again.

If no category_id is sent (or empty string) and category select is enabled:

• either choose a default category

or

• implement feature request FS#2451 and show that user should select a category.