|
1539 | Backend/Core | Feature Request | Low | Sitemap.xml Generation | Unconfirmed | |
| 2.1 | 1 | 12.01.2009 | 11.03.2015 |
Task Description
I would like the feature to have a sitemap.xml file be generated, say every xx days, set in the configuration.
|
|
1521 | Backend/Core | Feature Request | Low | Assignees should be able to see and create reminders fo... | Unconfirmed | |
| | | 22.11.2008 | 18.04.2009 |
Task Description
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.
|
|
1518 | Notifications | Feature Request | Low | Show last date/time when a reminder was sent | Unconfirmed | |
| | | 15.11.2008 | 15.11.2008 |
Task Description
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.
|
|
1510 | Notifications | Feature Request | Medium | Function to test mail configuration | Planned | |
| 1.1 devel | 3 | 29.10.2008 | 28.10.2015 |
Task Description
Add a button to test mail configuration before notifications is accpeted
|
|
1491 | User Interface | Feature Request | Low | Custom task table columns for individual users | Unconfirmed | |
| 2.0 | 3 | 01.07.2008 | 01.10.2015 |
Task Description
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?
|
|
1487 | Authentication | Feature Request | Low | LDAP(Active Directory) Authentication | Planned | |
| 1.1 devel | 11 | 21.05.2008 | 04.09.2019 |
Task Description
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.
|
|
1485 | User Interface | Feature Request | Low | Additional extended Printview for the Tasks | Planned | |
| 2.0 | | 13.05.2008 | 11.03.2015 |
Task Description
It would be useful to print a list of tasks in a extended version. e.g. All tasks from a programmer with all the details of it.
|
|
1481 | User Interface | Feature Request | Low | Diff visualisation | Unconfirmed | |
| | 1 | 04.05.2008 | 09.03.2015 |
Task Description
Flyspray should be able to render attached patches visually like, for example, Bugzilla: https://bugzilla.wikimedia.org/attachment.cgi?id=4807&action=diff
|
|
1237 | Backend/Core | Feature Request | Medium | Allow Multiple Owners Per Category | Planned | |
| 2.0 | 7 | 09.04.2007 | 10.08.2015 |
Task Description
Currently, only one owner can be applied per category (at least, that's what the tooltip implies). The ability to add more than one user, a user group, or a mix of the two to a category would be ideal.
Often times, more than one programmer will work on and maintain a feature that cannot be divided into subcategories with the various programmers dispersed accordingly. In such cases, setting all such programmers as owners of the category is beneficial in that they will all receive notifications.
Also, having a parent category's owner receive alerts if no owners are specified for a sub-category benefits from this ability. I may have a "User Interface" group that has all of my UI developers in it; assigning the group to the "User Interface" root category means all relevant developers find out about a new issue that was not directed elsewhere.
One potential conflict does arise with another Flyspray feature. If "Auto-assign a task to the category owner" is enabled, care must be taken to assign no users or the first user to the task; personally, I would prefer no one being assigned and seeing the wording changed to "Auto-assign a task to sole category owners". Worst case scenario would be another option asking if no one or the first user would be assigned to a task in that instance; if a group is specified, the first user in the group would be chosen.
|
|
1236 | User Interface | Feature Request | Low | Mark Issue As Verified or Unverifiable | Unconfirmed | |
| | 4 | 09.04.2007 | 18.07.2016 |
Task Description
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:
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).
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.
|
|
1222 | Backend/Core | Feature Request | Medium | Workflow engine / Role-based State Transition Rules Eng... | Unconfirmed | |
| | 7 | 25.03.2007 | 05.05.2019 |
Task Description
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:
For a “Developer”, the subsequent tasks from various states. Likewise for other roles
“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
..
.. it will go on like that 
This feature, in my opinion, is very crucial for corporate organizations to give a serious consideration to Flyspray.
|
|
1134 | User Interface | Feature Request | Low | add icon/image for each project | Planned | |
| 1.1 devel | 3 | 29.11.2006 | 09.03.2015 |
Task Description
When we have several projects into flyspray, it's hard to see the project where I am when I add several tasks. It's necessary to read the text.
To improve this, I think that it's a good idea if it's possible to add a color or an image with the logo project next to project title into web page. It will more simple to know where we are when we use flyspray.
|
|
1040 | User Interface | Feature Request | Low | Close Multiple Tasks at once | New | |
| 1.1 devel | 3 | 17.08.2006 | 01.10.2015 |
Task Description
We don't close the tasks until the release is "made", that is we let them under "Requires Testing" with 100% complete. When the release/testing cycle is finished, somebody has to go task by task, and start closing them... it's a PITA ;) It would be nice to have to option to select all the tasks you want to close, and that the "popup" when you enter the reason/etc, applied to all the tasks I selected...
I recall reading something about this in the past, but haven't found it; and if this is implemented, I haven't seen a way to do it in 099beta1
|
|
920 | User Interface | Feature Request | Low | Charts (gantt, severities, OSes, opened-closed, ...) | Researching | |
| 2.0 | 9 | 06.05.2006 | 07.04.2021 |
Task Description
With all informations on flyspray, it’s possible to generate a gantt chart.
For this, some php code exists :
- http://www.aditus.nu/jpgraph/
- http://www.graphviz.org/
- http://www.phpclasses.org/browse/package/2737.html
|
|
407 | Backend/Core | Feature Request | Medium | Plugin system | Confirmed | |
| 2.0 | 14 | 04.12.2004 | 17.01.2013 |
Task Description
Everything is currently hard-coded. Create a plugin system that allows a module to be simply "dropped into" a plugins/ directory, enabled in the options, and have the plugin just work.
Possibilities might include alternative methods of notification, perhaps a documentation subsystem, or even simple things like voting for tasks.
The user should NOT have to edit existing Flyspray source code to make a plugin work.
|