Scalable User Role management

[Tim Ryner]

I am seeking advice on a user administration methodology that allows project admins to administer their own projects without Jira Admins constant involvement.  
Here is the environment:  We havhe one project that has 300 users spread across 10 user groups.  At the moment, Jira Admins must add/remove users to those groups, which is time-intensive.  We are looking to off-load this responsibility to the  Project Admins, let them manage their own users (after Jira Admins create their accounts) because we plan to increase the user base for that project from 300 users to 3000 users. 
We also have 200 projects in our environment that would be affected by global changes.

User Groups:
+ is being used to manage the project effectively.
- it's requires Jira Admins to manage the groups, which is not scalable.  

Roles:
+ Create new roles that can be used to by Project Admins to manage their own users' access to different parts of their project.
- these new roles would be seen by all projects, so it's not an ideal way to administer one project and affect 200 projects.

Components:
+ Use Roles to get users into the project, then Components to break the project into smaller groups that are managed by the Project Admins.
- cannot add users to Components, just Leads.  So it wouldn't really control the users, just gives Issues a new parameter for sorting (this is how I understand Components, not sure if there is more functionality built in that I haven't used).

Has anyone developed method that allows Project Admins to manage their users, and also break them into sub-groups, without involving Jira Admins?  Thanks all!

[Nic Brough -Adaptavist-]

Use roles.   The trick here is understanding that you don't need 100s of them and you can mix and match.  In your scenario, it sounds like you need at most 10 at the moment.

I regularly work with vast Jira systems with hundreds of active projects, and tens of thousands of users, with 99.9% of the user management delegated to project admins.  Never seen one with more than 25 roles.

[Tim Ryner]

Thanks to your advice, I just had an epiphany on how I could approach the arrangement.  
Right now, the User Groups are broken up by a 5-letter-office-symbol. 
But I just realized that the last letter describes that office's function (eg:  ATCGE, E stands for Editor, ATCPD - D stands for Developer).  That lends itself to exactly to Project Roles.  I could create Roles that allign with the last letter of the office.  
That would be specific enough to give different people different permissions based on their role in the project, while being ambiguous enough that other projects wouldn't be confused by having and Editor role available. 
I just didn't see that relationship before.  Many thanks!

[Nic Brough -Adaptavist-]

Excellent!  I'm a big fan of specific but reusable role names - user, developer or worker, admin, owner, viewer etc.