How to copy Security Level in Security Scheme

[Deleted user]

We have some list of projects, and each of project use his own security scheme.

And each security scheme have ~ 10 security levels, and each level have almost 10 options groups\roles inside each level.

Every time when we need to add new level we need to create new level, and each time add same list of options in level and add some changes like different group.

If there some workaround, without using database to easy copy security level inside security scheme to fast modify and remove routine.

[Nic Brough -Adaptavist- · Accepted solution]

There's no way to do this (and you'll almost certainly just break your Jira if you try to do it in the database)

It sounds like you are building over-complex security schemes.  Why do you need loads of new levels?  Why so often?  Why are you not sharing the scheme across projects?

[Deleted user]

• There are different offices that work within the same process in one project, offices are separated by "security level".
• We cant use one permission scheme for all process
• Why?
  Different projects are different processes, recruiting, onboarding, etc., depending on the project they are completely different people.
• It is impossible to give everyone one group and one scheme, otherwise people involved in the preparation of a conditional job will have access to recruitment, which should not be the case.

In other words, an office called A should not see an office called B.
But Office A should not see Office B as part of another process because other people work there. Make a copy of project for the same process but for another office is not resolution.

p.s. yes make changes in database not recommended 

[Nic Brough -Adaptavist-]

Thanks for the explanation, my question was asked by my curiosity as to why it's got complex rather than anything being wrong.  It sounds like you've just got a complex set of security needs.  I would question why you're not just using roles in the security levels, which would vastly simplify them and allow for some sharing, but that might lead to problems if you can't trust your project admins to get the security right.

[Deleted user]

ok, but

1. Role give some permission. (transition, comment, edit, etc)
2. Group add to role (members example)
3. Group add to security level to see office A in security level A
4. the same for group B for security level B

If you mean to use role, its mean hundred roles in instance? and new role will be used only in one project not in. Or i dont understand

We use matrix for access (example)

name of service - key of project - role - prefix (optionally)

jira-abc-members-usa

jira-abc-members-den

jira-BBB-members-usa

jira-BBB-members-den

• Roles wouldn't fix it, members from office A mustn't see office B in one project.
• Members of group in project "abc" not the same in group of project "BBB"

[Nic Brough -Adaptavist-]

No, you're mixing up roles with groups here.  They do not do the same thing.

If you do security levels by role, you don't need different roles, you can control access with one scheme across many projects by simply putting people or groups into the right role.

[Deleted user]

I don't think we understand each other. Project A can be different to project B, I thought you understood me when I said that these are different processes of recruiting and onboarding for example, I want to emphasize that different processes may differ, and therefore different additional access settings can be applied, this is not a template and we are not like robots who do the same thing

What i say

1. we have simple permission scheme which grant permission for "member" role
2. we create group "jira-abc-members-usa" and add this group to role member in project A
3. we create security level which grant only access for this group in security level "usa"
4. the same we do for next level
5. we create group "jira-abc-members-den" and add it to role "member" in same project
6. we create security level which grant only for this group in same project
7. Сonclusion - usa work and dont see den, and same den dont see usa in one project for one process

We have project B which have same settings, but in groups different people, and some changes in security level i think you dont listen me

---

Lets i try to write step by step about roles, please fix me where i will be wrong

If you say create roles for this people? 

1) we add each role to permission scheme, because each role must be added to permission scheme, and we will need to make big list of options in permission scheme... why?

members-usa (role)

members-den (role)

we add them to permission scheme

2) we need add people to this role in project, but we dont add people directly to role, we use groups, because we have 1000+ people in company, manage project directly with people not by groups its nightmare in our example after few days management will be very hard (its not small team)

3) what next? how to give permission to see only issues for group A but dont give permission for group B ? i need to create security level

4) we have more work with roles, and same process to create additional security level, because all groups cant be in one level, because they 

5) why i need 10+ roles that will be used only in 10 projects for internal use, and wouldnt be used in another 100+ ? Why should I create things that make extra garbage in instance? 

We have standart list of roles (admins, developers, members,watchers,guests, and 3-5 additional) and all worked perfect. Why i need to do more roles? how it solve it? explain please 

[Deleted user]

p.s. we have clean security scheme for each project which have only list of roles, groups what we need in each level

create one scheme, and extend one level to add there 10-20 option in one its solution you have right, but you increase the risk of error and the human factor. we are not considering this proposal

Access management in one project is much easier when you have 5 options than 20, the chance of mistake and that the wrong person will get access is bigger, do you think that mistakes never happen?