“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra
This is the Bug Tracking System for the Flyspray project. This is not a demo! Before opening a new task, please read the guidelines!
Do not issue bugs reports against versions earlier than 0.9.9.5
Security problem? Check the security section.
FS#1237 - Allow Multiple Owners Per Category
Opened by Nick (NickHBO) - Monday, 09 April 2007, 11:30 GMT+2
Last edited by Cristian Rodríguez R. (judas_iscariote) - Friday, 24 August 2007, 23:18 GMT+2
|
DetailsCurrently, 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. |
Exactly, your feature requests suggest way too many options, we’ll certainly not implement them all :-p
Well, that’s certainly up to you. I like flexibility in my applications where necessary; as such, when I think of features for my own or other applications, I naturally include useful flexibility and as rich an environment as possible.
I never mention an option that I see no solid use case for.
Along with assigning groups to tasks, I suggest to implement this for 1.1 or sooner since it is a rather frequently requested feature.