Why does adding notification scheme to a project require global admin permissions?

[Simon Champion]

I have a question:

Why does adding a notification scheme to a project require global admin permissions rather than project admin permissions?

Surely this is project-level functionality?

I have a project admin who wants to be able to manage the notifications for his projects. I can't give him global admin rights thought.

[Nic Brough -Adaptavist- · Accepted solution]

No, it's not. There's a couple of things here.

The main one is that Jira doesn't (yet) have a granular enough admin rights scheme. Atlassian are looking at this at the moment.

The rest is mostly historical, and about controlling usage. Do you really want a user to be able to pick a notification scheme that is inappropriate? In some cases, it's fine, but in many, Jira is complex and has lots of schemes and you'd be expecting your project administrators to understand how Jira works, which isn't necessarily going to happen - you want people who understand it to do this stuff!

[Simon Champion]

Thanks for the answer.

I guess my point is that the user is a project admin: we've granted him rights to manage the project and we trust him to do it right. And the worst case scenario is that he messes up his own project, so the potential damage is limited to his own area of responsibility.

I can see the point thought: By allowing him to do stuff like this, we then have to consider whether he should be able to create notification schemes, and whether he should have visibility of all of the existing ones, etc etc etc... I can see how it can just spiral into a bit of a mess. Notifications aren't quite so bad, but I can imagine the horror of trying to apply the same rules to workflows and permissions schemes.

For the moment, I've resolved the problem by making the changes for him, but since you mentioned that Atlassian are looking at the issue, would you be able to give any deeper hints where things are heading in that regard?

[Nic Brough -Adaptavist-]

Oh absolutely, it would be nice if project admins could have some more control over their projects, in some cases.

My instinct was always that you should be able to enable a limited set of project leads the ability to choose from some of the schemes, but not letting them actually edit the schemes. That does mean the system admins have to be more careful in that they'd need to create schemes in a way that the project admins could safely pick the appropriate ones. I think there's an inherent problem there though - a lot of older, bigger Jira installs simply haven't been controlled well enough to allow that. Frankly, most of my jobs have started with "undo the mess made by letting project leads have too much control". It's all a bit fuzzy for me, I'm not really sure what the best approach would be. I've been in places where letting a project choose their own notification scheme would be great. And the next office along, an utter nightmare.

Anyway, https://jira.atlassian.com/browse/JRA-3156is the one to watch.

[Joe Pitt]

Another issue is consistancy. I've found people don't like it when project A acts one way and project B acts another. If project A sents a notification for an action, but project B doesn't they often think the one from project B got lost or isn't working correctly. They won't remember the differences. I've been at sites with 30 projects and they all use the same notification scheme with no complaints.