-
Suggestion
-
Resolution: Fixed
This is related to JRA-2814 in the sense that it is useful for large installations.
Currently for every project I create, I typically need to create one or more groups. This might be the "developers" or maybe "release managers" or other such roles.
Once I establish these roles using groups, I unfortunately have to create a separate permission scheme that map to these specific group names. This leads to a very large number of permission schemes, usually 1-to-1 with the # of projects.
Instead it would be nice to define some custom project-level attributes such as the "group that is the developers" or "group that are the administrators". Then my permission scheme could just be the scheme that says the developers could do this and the release managers could do this and the testers could do this and the internationalization team can do this.
Right now "scheme" is a bit misleading for permissions because it's not really so much a "scheme" so much as a straight-forward ACL. By allowing a project to have ad-hoc project-specific groups, my permission scheme can become a scheme in the policy sense, and the project then maps to groups which becomes the ACL. Poorly worded, but hopefully you can see where I'm going.
- is duplicated by
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Closed
- relates to
-
- Closed
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-2816] Role based permission schemes (eg. 'grant BROWSE to ${project}-users')
Paweł Piskunowicz
added a comment - Very important (to me) is possibility to use role in post function in workflow (e.g. changing assign to this role)
Best regards
Pawel
Paweł Piskunowicz
added a comment - Very important (to me) is possibility to use role in post function in workflow (e.g. changing assign to this role)
Best regards
Pawel Nick, this is not a evolution - this sounds like a revolution to me 
.
Really looking forward to 3.7 !!!
Thanks a lot
Ahmad
Ahmad,
Brief Description....
You will be able to configure roles (developer, tester, administrator, ...) on a Global Scale.
For each project you can allocate users to these roles (there are also Global defaults).
You can then specify these Roles in notifications schemes, permission schemes, security levels...
If you have more than a dozen projects, this will drastically simplify administration
I have seen systems with 1000+ groups and a different scheme for 100s of projects been simplified to a handful of groups and a single permission scheme.
3.7 is still at least a month off.
Cheers,
Nick
Dear JIRA-Team,
I'm setting up a new JIRA environment and I need to migrate quite complex Bugzilla permissions to JIRA.
Since role based permission schemes is done in 3.7, would you please give me a brief description how the feature works (e.g. some examples)?
Probably I would postpone the setup instead of doing a large rework after 3.7 is released.
BTW, any schedules for 3.7 ....?
I manage my projects exactly the same way as Serge has described, and would also love for it to be a bit more automate-able.
Hi Denis,
As far as I know this has not been scheduled for JIRA 3.6, beyond that I can not say. If you would like to read more about how we decide which features will go into a release you can read about it here.
Thanks,
Dylan
Denis Yurkin
added a comment - > This is likely to appear in 2.7 or 2.8, after we finish workflow improvements.
No updates on planned version so far?
Denis Yurkin
added a comment - > This is likely to appear in 2.7 or 2.8, after we finish workflow improvements.
No updates on planned version so far? 
Jeff Turner
added a comment - Once roles are defined, we'd need a screen on the User page listing their roles, and warn admins when deleting users if their roles would be unfilled.
Jeff Turner
added a comment - Once roles are defined, we'd need a screen on the User page listing their roles, and warn admins when deleting users if their roles would be unfilled. Eric,
Thanks for sharing this with us. We understand this limitation and are hoping to improve on this in the future.
Thanks again,
Anton
Project roles implemented in 3.7 is not what I think about... (described in
JRA-11147)3.7 roles are similar to groups.
My idea was: project role one-to-one to user.
Then I could define role Test Leader and define in my workflow auto assigning issue to this role.
Using such a role I could ease redefine Test Leader (eg. holiday time) don't even touching my workflow.
In 3.7 I still can't do auto assign issue in my workflow to project role because in one project role could be a lot of people.
Best regards
Pawel