Flyspray - The bug killer!

Fatal error: Class 'League\OAuth2\Client\Provider\Github' not found in /html/bugs/includes/GithubProvider.php on line 11

I have downloaded this:
Precompiled with 3rd party libs for PHP5.6: flyspray-1.0-rc1_php56.tgz
and the file seems really dont exist.

An assigned ticket can't be edited by a lower privileged user.

I need metrics for flyspray projects about a rest api. For example the count of issues for status, priority. I want use this values for my code analysis system http://www.sonarqube.org/ and other internal tools. It is possible to create a rest api with user authorization and only for metrics data?

Please support Central Authentication Service, thank you.

It would be helpful to have communication with LDAP via TLS

I have done a very quick bit of work to bring ldap (through active directory) authentication to flyspray for our implementation in the office. I hope it will be of use to others. There is a readme.txt inside talking through the process and the patch to apply. My plan is to expand on this and make it part of the setup process but this will take a bit longer.

Hi

Please advise if there are known issues when integrating Flyspray with Active Directory using LDAP.

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

With the existence of now two peoples named “Peter” on bugs.flyspray.org (I - peterdd , and PeterTheOne)
there are several places where the full names are display instead of usernames and the user can’t know who is which “Peter” until he visits the users profile page.

Different solutions possible:

• more profile image/gravatar usage where user names are shown, on mouseover link title attribute shows username and realname
• display user name (username) instead of full name (realname)
• display full name and username (where much space available and precision needed)
• …

When adding the mention feature, the username will be probably the prefered setting as the username is unique but the realname not.

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

A very useful feature would be to be able to manage a list of custom fields by project, and to be able to add and fill any of these fields to any task.
So we could be able to search on the presence and content of a field.
We could be able to sort the tasks by this field when they are displayed in a list.

A use example is when you create a bug by reference to another external list. It can be very useful to have a field that references a line in the external list.

Sometimes comes this message with a lot of backtrace log.
If you are reporting a bug please provide as much information as possible to help understand and reproduce the problem:

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

mysqlnd 5.0.12-dev
Linux 64bit
PHP Version 7.2.25

Steps done to create the problem:
Wait some weeke and edit a ID.

Experienced behavior:

[18-Dec-2019 13:19:41 Europe/Berlin] PHP Notice:  session_start(): ps_files_cleanup_dir: opendir(/tmp/.priv) failed: Permission denied (13) in /var/foo/htdocs/flyspray/includes/class.flyspray.php on line 1006
[18-Dec-2019 13:19:41 Europe/Berlin] PHP Warning:  session_start(): Cannot send session cache limiter - headers already sent (output started at/var/foo/htdocs/flyspray/includes/class.flyspray.php:1006) in /var/foo/htdocs/flyspray/includes/class.flyspray.php on line 1006
[18-Dec-2019 12:19:41 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/foo/htdocs/flyspray/includes/class.flyspray.php:1006) in /var/foo/htdocs/flyspray/index.php on line 96
[18-Dec-2019 12:19:41 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/foo/htdocs/flyspray/includes/class.flyspray.php:1006) in /var/foo/htdocs/flyspray/index.php on line 97
[18-Dec-2019 12:19:41 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/foo/htdocs/flyspray/includes/class.flyspray.php:1006) in /var/foo/htdocs/flyspray/includes/class.csp.php on line 76
[18-Dec-2019 12:19:41 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/foo/htdocs/flyspray/includes/class.flyspray.php:1006) in /var/foo/htdocs/flyspray/includes/class.csp.php on line 80
[18-Dec-2019 12:19:41 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/foo/htdocs/flyspray/includes/class.flyspray.php:1006) in /var/foo/htdocs/flyspray/includes/class.csp.php on line 82

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.

I have installed flyspray on an internal server and have problems with the renaming of internal links.

For example:
I want to put this link in the comment section.
\\192.168.200.5\Folder\example.docx

it shows the link correct,
but when you hover over the link it shows:
file://192.168.200.5/Folder/example.docx

And on clicking on it, of course I can´t access the file, because it´s trying to open an external link.
I dont want it to be renamed from ‘\’ to ‘/’.

Can somebody help me please.

I tryed to find it in the sourcecodes, but I have almost no experience in PHP.

Thank you!

Motivation

Proposal

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.

I gave a role the following privileges:

• view own tasks

• modify own tasks

• view comments

• add comments

A user with the assigned role can still modify the task descriptions and task details. (I want that user to only be able to add comments.)
I think there is a bug.
Is there a fix or walk around?
Thx

Closing a task with selected close reason duplicate should warn when there is no comment or FS # id is given in the close comment text field.

The task is closed as duplicate without any further notice. The information to which task it is duplicate or a description (if the problem is logged/handled outside Flyspray) is lost.

Possible solutions

Frontend hints

Backend deny

So closing a task

FS#1

with

reason: duplicate

and close comment

FS#1

referencing to self should be detected to avoid such user mistakes.

I understand this is likely due to some sort of XSS CSRF protection, but the delay doesn’t appear to be long enough to be useful for a lengthy comment to be posted. I’ve now lost two detailed comments in our tracker because the software threw everything out and generated a meaningless error.

Further, attempting to do the normal thing and making the browser resubmit the page results in Flyspray throwing “Error #3” something something repeated action and causing a redirect to the homepage.

Surely there has to be a better way to handle this that doesn’t incur data loss?

I have been working with Eventum (http://www.mysql.org/downloads/other/eventum/) for quite sometime now and in contrast, I like Flyspray for its simplicity and practicality. But one thing I badly miss (and something that Eventum scores high) is a Workflow Engine. If not a sophisticated W.E., I (as an Admin / Manager) should be able define role-based state transition rules of the tasks reported in a particular project. For example, I should be able to implement the following scenario:

1. For a “Developer”, the subsequent tasks from various states. Likewise for other roles
2. “Developer” should not be able close out the bug reports. He/she can only flag them as implemented. The “Reporter” of the bugs or the “Manager” alone should be able to close out issues
3. ..
4. .. it will go on like that

This feature, in my opinion, is very crucial for corporate organizations to give a serious consideration to Flyspray.

Currently the sessions are stored by the webservers default settings.

Having this sessions under control by Flyspray by storing it in the database has following advantages:

1. Allows handling of all sessions of a user by Flyspray.
2. Providing a session management for each user. The user can see on which devices he is currently logged in and could also force a logout on selective devices.
3. A forced logoff of all or some user sessions is easy implementable for admins.
4. Statistics about how many users and who is logged in. (user status: hide always, online, offline, do not disturb, ..)
5. Could make onpage-notifications easier to implement.
6. .. ?

Disadvantages:

1. A potential unknown security bug in Flyspray that could lead to reading a session db table could leak informations like who is currently online/active and make further attacks more focused or makes session takeover easier.
2. .. ?

You cannot select the fields for export to csv. This means that the commentfield (edit: you mean task description, right?) is always exported too. As this commentfield task description (?) could contain quotes, comma’s etc (like people inserting copies of emails on an issue) it corrupts the output file and the file cannot be read by excel.

Moving task to another project seems to require fields updated to target project options. This operation is not possible on the task category field and possibly others. Attempting to submit changes gives error:

“Oh, there are some incompatible properties set that must be resolved before moving this task to a different project.”

However, you cannot select a new value (from the target list) for the properties in question.

When a Flyspray installation allows user self registration and has public but also more private projects, this feature could make the required configuration more clear:

In this case, keep the number of global user groups as low as possible and the global user group for basic or just registered users has only the ‘can login’ permission and nothing more.
Because that only would be useless for new registered users, adding them also to a basic user group of a public project could be useful.

So my suggestion is:

A new optional global setting: Something like ‘default project user group’ (store 2 values: a project_id and a group_id). Validity of that setting must be checked during any user registration, so that project must exists now and at later time as also that project user group within that project. (’Checks’ of admin prefs)

So it would be like this for a new registered userA:

1. userA is in a basic default global user group: only login permission to handle his account registration (login, logout, user preferences, password forgotten)
2. userA is in project X default user group: some basic permissions you want allow for every (new) registered user in project X
3. project Y: all ‘allow anyone ...’-settings are unchecked, userA not in any user group of project Y

The setting is probably best put below the ‘Default global group for new users’ setting in the global admin prefs tab #userregistration as

Either: A dropdown list with all public projects with an existing user group and dependend on the selection the available basic project groups are loaded by ajax as a select list too.

Or: Only one dropdown list that contains a list of public projects with possible project user groups. Would not require extra ajax calls and is maybe enough because we could exclude project groups that have project manager permission or such configuration nobody would allow new registered users.

no default project user group
public projectA - simple user groupA1
public projectA - simple user groupA2
public projectB - simple user groupB
public projectC - simple user groupC

This idea could be enhanced further (put the new user to multiple public projects when he registers or let user choose from public allowed projects during registration process), but lets start simple.