When JIRA (3.13.5-#360) had been put into production at Gazprombank, the requirement of JIRA administrators and information security administrators was that Project Administrators should not be able to change project role membership.
According to the approach used at Gazprombank any changes to user rights and permissions (in case of JIRA, project role membership) are performed only by administrators who act according to applications confirmed by information security administrators.
So we were forced to customize JIRA functionality in this part.
Namely, we replaced DefaultProjectRoleService.class (\atlassian-jira\WEB-INF\classes\com\atlassian\jira\bc\projectroles) with a changed class (the modifications include calls to hasAdminPermission(currentUser) function):
1) method removeActorsFromProjectRole
if (hasProjectRolePermission(currentUser, project) && hasAdminPermission(currentUser) )
2) method updateActorsToProjectRole
if (!internalError && hasProjectRolePermission(currentUser, ProjectRoleProject ) && hasAdminPermission(currentUser) && actors.size() > 0)
else if (!hasProjectRolePermission(currentUser, projectRoleProject) || !hasAdminPermission(currentUser) )
We needed a quick way to do that so we acted like this (sorry!).
However, our suggestion for future versions of JIRA is to divide Administer Projects permission into two separate permissions:
1) Administer Projects (ability to edit project components, project versions, and some project details ('Project Name', 'URL', 'Project Lead', 'Project
2) Administer Project Role Membership (to edit project role membership).
Please, consider this suggestion to be implemented in JIRA.