I have a big installation where we have about 50 people in jira-administrator group (that's mainly because jira does not allow non admins to add fields and perform other common tasks).
The problem is that if someone tries to contact the site admin using the form, most of the times users getting permission violation messages, this message will be sent to all jira-administrators and worse they are get the email individually, so they do not know that others may receive the same message nor they can reply to all.
How can I solve this problem?
I need to allow people to be admins but still keep a shorter list of real admins, the ones that do process user requests.
This may be the solution but I will have to do some additional tests for these. If would be silly as it would work the other way: moving people with less responsability to jira-system-administrators just to prevent them from receiving notifications.... giving them more permissions in order to receive less email (spam from their point of view).
i just tested...
it works as expected.
my own user is not in group "jira-administrators" but in "jira-system-administrators"
i logged of from jira and choose to contact Jira Administrator
i entered some dummy values...only the admin user from administrator group recieves this mail. not me
you may got sth wrong on the groups.
jira-system-administrators is higher than jira-administrators
from the global permissions you can see
Ability to perform most administration functions (excluding Import & Export, SMTP Configuration, etc.).
JIRA System AdministratorsAbility to perform all administration functions. There must be at least one group with this permission.Note: People with this permission can always log in to JIRA.
You can't. The setup is simple - either you are an administrator or you are not.
The proper fix is to reduce the pool of administrators. 50 is silly, I know you think you need them all, but have you trained them all on how to avoid duplicating configuration, reusing existing structures, how not to break other people's stuff when they're making their own changes? Every place I've seen that does this ends up with a Jira in a monumental unmaintainable mess.
Edit because I found my bookmark: Basically, we need https://jira.atlassian.com/browse/JRA-3156 fixed, but I don't think there's any workaround for your situation - you need to reduce the list of administrators, or your admins need to accept that they're going to keep getting admin related emails.
Thre are few jira administrative permissions that do need to be accesible to a broad tane of users: adding user, managing groups, roles, and changing project leads. Things are chaning very fast and when you have instances with up to 100 projects you cannot have a very small number of admins.
Recently Atlassian added teh jira-system-administrators group, wich have an additional set of permissions.
The silly part is that in order to prevent all admins from receiving these notification you have to move them to jira-system-administrators which means more permissions, not less. Still, this hack will solve the notification problem.
Atlassian could easily solve this by allowing us to define which group gets the administrators notifications. By default this should be jira-administrators, like now, but it should be configurable. Seems like somethign quite easy to implement.
Read this for an alternative solution - https://answers.atlassian.com/questions/127200/setting-up-the-contact-administrators-form
Disable the contact administrators completely and use Issue Collector, trackable, customizable request handling (no more emails).
This is not a good option and I will explain why: most of my reports are received from people getting permission denied messages. The default form does provide information about this, if I diable this I will get manually introduced reports which are always incomplete.
Create your admin project with a good create screen to collect whatever information you want from the user (for example, a select list asking for the reason why they are contacting). This gets automatically captured in JIRA. In fact, using the issue collector gives you the best possible reporting than handling the contact requests via emails with no tracking to closure. IMHO.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG