Administrator vs Manager Functions

[Maulik Mistry]

I have noticed a jira-managers group. I believe the best way to allow another employee the ability to administer projects and issues without administering the system by adding the user and permissions to this group. Another option was to make that employee a Jira Administrator without being a Jira System Administrator. Which process is better and more secure?

I have made continued efforts to teach Agile methods alongside developer commitments and ownership, but I was asked to allow all managers to have the ability to move, assign, complete, delete, edit, any issue in any project. I was concerned to let it go too far into the system itself, and therefore I have been attempting to make the system secure without limiting the managers' abilities to work on any project when they review an employee's work. What do you think is the best way to allow this request to be met, in addition allow it to continue in any newly created project?

[Nic Brough -Adaptavist- · Accepted solution]

It's definitely better to keep "System Admin" away from "Managers". For your needs, I'd simply define a new role of Manager, edit the permissions to allow move, assign, edit (I'd think twice about "delete" because it really does destroy the issue entirely), and then amend your workflows to alow the role to complete (As that's not a Jira function, I'm assuming it's in the workflows). Then you can add your managers into this role for the projects they own and you're done. Without giving them the system-admin stuff.

[Lisa Rahder]

What is the most restrictive "permission" you can assign that allows the person the create sprints in a given board?

[Maulik Mistry]

One need not fulfilled is the ability of some managers to be able to change categories. Only the system admin has this ability. Any other way to put together projects that you have thought of?

[Markus Lepper]

@Nic & all:

I like tho concept of roles, BUT roles could be changed by the project leads!!

In our case this corrupted our access policy as some leads added too many people into some roles.=> information too widely spread.

Our "solution" is to use groups which are linekd in permsission schemes.: This is more secure as schemes could only be changed by admins.

Any better option?

BR, Markus

[Markus Lepper]

Just an addition to Nic's comment:

Ah, but Jira will track their changes. If someone does make a mess of it, you can look at the the issue history, see who did it and blame them :-)

Right; for all text based fields you'll see the old and new content.

If attachments get deleted you could not restore them; the only remainder is the filename of the attachment but no content.

[Maulik Mistry]

Thank you Nic Brough. I followed your advice and established the following, which makes me nervous but leaves things as safe as I can make it:

1. Created a jira-manager group so that I could easily move users in and out of management as changes arise.
2. Created a Permission Scheme that added the jira-manager group to have specfic allowances in projects beyond the default ones shown in JIRA. This process will allow me to easily change permissions for the managers/developers in case challenges arise.
3. Created a workflow that removed restraints as I was requested. This is the most dangerous allowance as someone may be able to go through and mess up a lot of issues for example without having to account for changes.
4. Applied the Permissions Scheme and the Workflow Scheme to projects that are being supervised by that manager.

System admin materials preserved with options for management fulfilled.

[Jon Cotter]

He mentioned creating a Role for managers as well, which gives you the option to assign different permissions to them in different projects, or to have different managers in different projects. I do this as well and find it immensely useful for managing Permissions as well as Notifications.

http://confluence.atlassian.com/display/JIRA/Managing+Project+Roles

[Nic Brough -Adaptavist-]

> This is the most dangerous allowance as someone may be able to go through and mess up a lot of issues for example without having to account for changes

Ah, but Jira will track their changes. If someone does make a mess of it, you can look at the the issue history, see who did it and blame them :-)

[Maulik Mistry]

Awesome help Nic and Jon. Thanks for the heads up and helping me get more familiar with fine grained JIRA control. I guess they can take the time to fix it if they do mess it up.