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.
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?
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.
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)
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
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?
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?
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