Feature #1919
closed
Separate permissions for changing assigned-to, % finished and target version
0%
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.
Related issues
Updated by Mike D. Smith over 15 years ago
+1
I would very much like to restrict the same fields for a reporter role.
Updated by Paulo Aguiar over 15 years ago
+1
Another one interested in such a feature
Updated by Tomáš Řihošek over 14 years ago
+1
would be useful for custom fields too.
Updated by Nicole Dumfart over 14 years ago
++
I think it should be possible to restrict every field to the roles.
Also custom fields...
Updated by Mischa The Evil over 14 years ago
Added relation to issue #703 (and thus its related issues).
Updated by
Updated by Assis Calazans about 14 years ago
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.
Updated by Etienne Massip over 13 years ago
- Target version set to Candidate for next major release
Updated by
Updated by Giovani Spagnolo over 13 years ago
+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.
Updated by
Updated by Justin Mayer almost 13 years ago
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.
Updated by Александр Закревский over 12 years ago
+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.
Updated by
Updated by Eric Strennen over 12 years ago
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.
Updated by Александр Закревский over 12 years ago
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.
Updated by Jean-Philippe Lang over 12 years ago
- 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.