Flyspray

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

no task description

Motivation

Proposal

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.

When a tasklist contains the duedate column and the user sorts by duedate ascending, the tasks that do not have a duedate set should not be listed first. Instead they should be listed after the tasks with duedates.

This way a user can see the task with the earliest duedate first instead of seeing a bunch of probably not so important tasks without duedates set.

We must teach browsers not to use some input fields in the admin prefs area to offer to store it in their password manager.

Steps to reproduce:

1. Login with Firefox as admin into Flyspray. (Maybe other browsers behave same)
2. Go to admin prefs area (top right gear icon)
3. Click link somewhere else (so leaving admin prefs page)
4. Firefox browser pops up password manager as it detected some password input fields on admim prefs setting page. But in this case this is not wanted.

Either by using different input field names where the browser does not assume it is a login password field or find input field attribute to tell them.

auto-complete="off"

is not working anymore in browsers for password fields.

webbrowser: Firefox 85.0.2

Popup probably triggered by the password fields for configuring Email and XMPP notification: smtp_pass and jabber_password input fields. Firefox heuristic is too stupid to detect that these are for server configuration, not user login fields!

Neither

autocomplete="new-password"

nor

autocomplete="one-time-code"

attribute helped.

Stubborn Firefox ..

There should be only one request to

js/callbacks/gethistory.php when activating the History tab

The request is made:

• on mousedown event
• on click event

So holding down the tab sends the first request and releasing sends the second request.

For users with administrative permissions, a moderation UI for spam tasks could be useful.

For other normal users a “mark as spam”-button (similiar to voting for a task) could help moderators to identify spam tasks.

1. Modify the spam task: Move to a hidden “Trash” project, replace summary and description with a default spam summary text end empty description.
2. The decision which kind of punishment of the account who created the spam depends on several things:
   • Is it a previously normal used account who got captured by a bad guy and suddenly started spamming?
   • Is it a fresh bot created account who tried creating many spam task to promote bad websites or do search ranking manipulation?
   • Is it a sneaky smart account who waits for the opportunity to offload spam in a subtile manner?

I think this is not so easy to automate without producing false positives, especially for a project without commercial interest and funding and no huge meta informations like Google or similiar data collecting corporation who have the ability to identify spam waves across the internet.

From mailing list:

Hello,

I could not find if this was already posted before. We have this basic profile where customers only can create new tasks and receive some notifications when the status or details change. The idea is that they do not see the comments, we want to use them for internal communication.
The think is that we just realized that they can not see the comments when they login but they receive them as notifications by email!

We want this notification for the admin users involved in the task but not for the customers. Is there a way to correct this behavior?

Thanks,
Manu

[ ] ADOdb xmlschema03 issues
[ ] other warnings/notices

When there is a link to the new task action from another site to a Flyspray installation and the user is not yet logged in, there is a redirect to the Flyspray start page losing the GET parameters.

Example:

https://bugs.flyspray.org/index.php?do=newtask&project=1&item_summary=blablabla%product_category=1

Or short example (nicer urls using .htaccess rules)

https://bugs.flyspray.org.de/newtask/proj1?item_summary=blablabla&product_category=1

After login the user should see the form with the original link parameters (if the user is allowed to and parameters are valid)

Currently the user must navigate to the correct project (if there are several) and the parameters from the origin link are lost.

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 Vote functionality provides users a way to say "this issue is important to me". In addition to that functionality, it would be great for users to have a "Verify" ability on open issues; it would provide users a way to say "yes, this happens to me as well".

A "Verified" label would fit nicely right under "Votes", to the right of the label would be "Yes | No", each option being a link. After clicking Yes or No, or if unable to specify (lack of permissions), the text would display "Yes - # | No - # (% verification)" where '%' is the result of ((Yes/(Yes+No))*100).

This feature should not show up on all issues, though. It does not make sense to "verify" a feature request or todo item, for example. When defining task types, the administrator would specify if a type was "Verifiable" by checking a box in a column next to "Show".

If implemented, two great, mini extra features would be:

1. The ability for the administrator to set the number of "Yes" verifications an issue would need before it was elevated to the next priority, severity, or both (specified by the administrator).
2. The ability for the administrator to set the number of "No" verifications an issue would need before it was lowered to the previous priority, severity, or both (specified by the administrator).

Both settings should have an option to be incremental (priority / status increased every x verifications) or not (increases once, no matter how many verifications are received); an "Incremental" checkbox would do nicely. Also, a little "Enabled" checkbox next to both settings would be clearer than having zero act as the disable mechanism.

As with voting, a permission should exist to enable or disable this option for a user group. For larger projects, moderators tasked with verifying bugs could be given the permission whereas smaller projects may leave verifications up to the community.

Lastly, a way to send a notification once the number of "Yes" verifications reached a certain value would also be a great addition.

Flyspray should be able to render attached patches visually like, for example, Bugzilla: https://bugzilla.wikimedia.org/attachment.cgi?id=4807&action=diff

Allow individual users to define custom views of the task tables much like the project manager can for the entire project; only on a user scale.

An option for the user to "use default" project settings should be possible and should be the default.
Only pro users will change it to their needs, not the average reporter.

Interesting would be the possibility to change it dynamic on the tasklist view, not only on the myprofile setting page.

Open Question: Simple or complex implementation?

• Simple: A new varchar field for the user table like it is in the project table and provide the same field chooser like on project setting page.
• Complex: User settings for global tasklist view and each project. Needs extra 'project_user' (or 'user_project' ) join table. Well, maybe over engineered.

This information is already stored in the table "reminders" in field "last_sent". It might be helpful in some situations, if this date/time would be visible to the user on the reminder list, too.

In version 0.9.9.5.1 (unfortunately I couldn't select this version in the dropdown list on the left), reminders can only be created and edited by Admins and Project Managers. I recommend to give Assignees the permission to create reminders for themselves. To minimize any programming impact, his may be done as part of the "edit own tasks" permission.

This topic has been reported by Engie as part of Bug #713 for version 0.9.8 as well: "Also it would be useful if a user could create reminder for himself." Although that bug is already closed ("fixed in devel"), this part is not yet solved in the current version.

I would like the feature to have a sitemap.xml file be generated, say every xx days, set in the configuration.

the installer does not check for reserved characters when writing to flyspray.conf.php, causing parse_ini_file() to return an invalid database password.

I would love a option to allow anom users to write comments! Maybe with CAPCHA...
I allow anom users to report bugs, but when I have a question to this bug, or the reporter wants to make a additions, he has to register...

I tried hacking it in the core: In the class.user.php at the end of the get_perms method I added:
$this→perms[$proj_id]['add_comments'] = 1;

But I has nothing changed. The I removed the check if the user had the right to make a comment in the template file, now I have a comment field for everyone, but anom user get a error message saying, that they should enter a comment... I searched a lot in the core files, but I don´t find the point where the comment a written in the database... I would a great help if you could give at least a hint :)

Another thing i tried was changing the user contructor, that every user with a negative ID get the ID 2, witch is a special "anom" user. But then you could not log out, a the admin not in...

Here the link to my site: bugs.thekingdomofdarkness.de

For a combination of archiving / "notify bot" reasons I have found it useful to have a single global notification address where all bug reports / updates / comments go.

In the past I've used this to automatically dump updates into a IRC / Jabber chat room as well as provide a way for a project manager (me) to keep an idea of the amount of activity. Please let me know if you have questions about this.

Forms should be submittable by using keyboard shortcuts.
S for submit.
Set-able via the accesskey attribute on HTML inputs.

On Mac OS Safari:

I just closed a task and wrote the following into the comment for closing:

"See also F.S.#.14" (of course without the points). When I then click the link in the comment box (below the task details) I'm redirected to:
"http:/flyspray.stefan-herz%0Aog.tld/index.php?do=details&task_id=%0A14". No matter if #14 is closed or not.
It worked with Firefox.

Any suggestions?

It's a little like "text version". So you could use this exported changelog within a new release.

I think good was:

• Only resolved tasks ordered by date (but of course without displaying the date) and only public accessible tasks
• Without task number ("FS#...")
• A download function via button

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?