nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Are there plans for Administrative Division

Kevin Paulus

We need to separate admin capabilities such that only the system-administrators can access license details & grant application access but still have other users that can fully edit their workflows (including the transition triggers, validators, conditions, post-functions). We have over 400 project spaces and the users are repeatedly asking for elevated permissions -- We have found that more than 2 or 3 system-administrators is not an acceptable state. This is Jira Server 8.10.0

Accepted answers

Nic Brough -Adaptavist-

Not on Server, it's going away.

Jira Cloud has some more delegatable permissions, more because the projects are changing shape and you don't get "system" administration on Cloud. Most notable is that Cloud already has "Site" admins who look after people and licences, but are not necessarily Jira (or Conflluence or Bitbucket etc) admins.

Jira DC - I'm expecting to see some smaller refinements, but not huge amounts. With bigger Jiras a perennial problem really is letting too many people admin their own workflows or fields etc. Cloud's Next-gen projects are delegating, but Next-gen shows no sign of coming to DC. Over the last <mumble> years, all but two of my main jobs or projects have been started with "clean up the mess made by letting too many people customise their projects".

I'd always recommend 3-10 admins. 3 is more about "cover" - you need an admin, then you need someone else to cover when the main admin is ill, busy or away, and it's a bit risky having only 2 (my classic example - the two admins at one place I went were married, so their holidays tended to co-incide a lot). I'd happily recommend a a proper team of admins though, people working in the same place (daily standup type meetings, one team lead, same line manager, that sort of group), knowing what the others are doing. Human social interactivity really limits that to 9-10 people in the team, and I'd try to stay lower, at 6-7

All comments

Nic Brough -Adaptavist-

Not on Server, it's going away.

Andrew Laden

I agree with much of what Nic has to say about too many admins and having to clean up and standardize and undo customizations.

However, if you really need the functionality, as with many things in jira, there is an add on for it.

https://marketplace.atlassian.com/apps/1213035/delegated-project-admin-pro-for-jira?hosting=server&tab=overview

Kevin Paulus

Thanks Nic -- That is as I expected. I too was handed a stack that was a disaster area: 33 users having system-administrator privileges -- and complaints that their actions were constantly being undone or overwritten. The "stuck pig squeal" lasted for about two weeks after I cut it back to 2 admins, but the users have a way of exacting revenge by seeking admin assistance for that which they can do on their own. We will be moving to DC soon and your insight is helpful. I would really like to see some granularity of control on the admin side: Split out User Management, Add-ons, Application access, and System settings.
A proper team of 4 would be my solution -- with constant/group communication, we would be able to satisfy user needs and keep the interface in good working order.

Nic Brough -Adaptavist-

The communication between admins is paramount.

I usually create an Atlassian Admin project with issue types reflecting what people might need from admins. Doesn't need to be a low level list, typically I've used issue types like "Make J/C/Bb do this", "something isn't working", "(new) project", "app request" etc. Then you enforce a rule that "no one changes Jira config unless there's an issue raised for it in that project, and they assign themselves to it". So when admins do make changes affecting others, we've got a log of who and why.

You can already do user management and application access to some extent - for any not-tiny Jira, I recommend hooking the user directories up to the organisations user management (LDAP, AD, whatever). That pushes most of the user management to the organisation, who don't need to be Jira admins. If you then get rid of groups in your permissions, notifications, security, etc schemes, using roles instead, you can delegate the rest to your project admins! (Trust me, I freed up 5 people from a close to full-time job doing group maintenance by swapping to roles overnight)

Kevin Paulus

Hi Andrew: We did try that -- but some of our project admins were unable to figure out how to use it, those that could quickly found that they were breaking their projects.

Kevin Paulus

I set up an Atlassian Service Group for the admins to follow/ with corresponding Confluence space for the meeting notes & other documentation. For the users there is the Atlassian User Support project space which is set up as a help-desk with issue collectors in Jira, Confluence, and Bitbucket. Now if only I can divorce myself from the Atlassian Admin title so that all users would use the User Support project & stop emailing me directly with their needs. The first thing I do is create a user support issue on their behalf.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-software

jira-software-server