Feature #1919
closed
Separate permissions for changing assigned-to, % finished and target version
Added by Finn Gruwier Larsen about 16 years ago.
Updated over 12 years ago.
Category:
Permissions and roles
Description
Currently, access to these fields is controlled through the status workflow permissions. It would be better if they had there own permissions in order to get more fine-grained control over user permissions. My actual problem is that I want to create a "customer" role that should be able to make some status transitions (f. ex. open > closed), but customers should not be able to change assigned-to, % finished and target version.
+1
I would very much like to restrict the same fields for a reporter role.
+1
Another one interested in such a feature
+1
would be useful for custom fields too.
- % Done changed from 0 to 90
- % Done changed from 90 to 0
++
I think it should be possible to restrict every field to the roles.
Also custom fields...
Added relation to issue #703 (and thus its related issues).
This is a "must have"....
I have the same problem related by Gruwier. My costumers have an area to add tickets in a especific workflow.
Still waiting for this feature.
- Target version set to Candidate for next major release
+1
we also use "customer/partner" roles and something we'd like to do is to hide "estimated time" and "time spent" fields from them.
it could be somehow configurable which fields (including custom fields) are visible by roles.
This issue is very narrowly-focused and discrete, which I think makes it a great candidate for near-term implementation. Judging by the number of related (and still open) issues, plus the number of comments posted to those issues, the demand for this functionality is overwhelmingly large:
- #703: refers to required fields, which isn't really related to permissions
- #3090: duplicate
- #5011: duplicate
- #5037: makes reference to custom fields, which is larger in scope than limits placed on built-in fields
- #8050: would address this issue, but is much larger in scope
As a product manager, I'm a big fan of prioritizing small, discrete features that can have a big impact, and this issue certainly seems to fit that description. Please consider this my strident vote for incorporating this feature in the next release.
+100500
Much insterested in! My Customers/Reporters must not have the right to assign or reassign issues as this misleads my side developers. In my situation only project managers have the authority to do that. Used side plugin to handle the situation, but it blocks major version updates due to incompatibility.
BTW, I deployed the Field Permissions plugin by Romain Silva and it addresses most of this issue. Per role, you can enable/disable access to Assignee, Target Version, Estimated Time and Due Date. Definitely a step in the right direction.
Eric Strennen wrote:
BTW, I deployed the Field Permissions plugin by Romain Silva and it addresses most of this issue. Per role, you can enable/disable access to Assignee, Target Version, Estimated Time and Due Date. Definitely a step in the right direction.
Me too, but it worked only for 1.3.x. After upgrade to 1.4.x I faced troubles running this plugin, so I had to roll back.
- Status changed from New to Closed
- Target version deleted (
Candidate for next major release)
- Resolution set to Duplicate
Implemented as part of #3521 for 2.1.0.
Also available in: Atom
PDF