Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,300,920
Community Members
 
Community Events
165
Community Groups

How to copy Security Level in Security Scheme

Deleted user May 18, 2022

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.

1 answer

1 accepted

1 vote
Answer accepted

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?

  • 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 

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 May 19, 2022

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"

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.

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 

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?

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you