Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Restricting access to particular issue type schemes, workflow schemes, screen shemes,etc.

I want a few Jira Schemes(workflow, issuetype, screen, field configuration, Notification schemes) which are associated to a few projects  to be locked down so no one but system admin or a very exclusive group can edit them. 

Is there any way we can do this in Jira now? 

Can we use Power script or any code to achieve this programmatically?

3 answers

0 votes

Hi @Soham Das 

As @Joe Pitt mentioned first make sure there are not many admins and set a change control process and for automating creation of these configurations as @Nic Brough _Adaptavist_ mentioned you can use ScriptRunner for Jira. If you are looking for some working examples then you might find this video useful where you can use a script to create a project.

ScriptRunner for Jira utilises Jira Java API but if you want to do these things from outside Jira then you can use Jira REST API. I explained how to create a project using REST API here.

I hope it helps.

Ravi

0 votes
Joe Pitt Community Leader Dec 09, 2021

Put JIRA under CR

 I STRONGLY suggest you treat JIRA like a production system, put it under change control (CR), and track all requests for any updates, especially new projects, new custom fields, changes in any of the schemes, etc. That way at least the reporter will know when the actions happen and you'll have a audit trail. I've worked many similar tools to JIRA and too many times no one knows anything about why they are configured why they are because there is no requirements or CR. Things are just done based on emails that have disappeared and hallway or lunch conversations.  

 If you don't already have a separate change control tool create a JIRA project. I use a basic workflow with a few custom issue types:

 Custom field: with a select list of create, update. The description would be to create a new field or modify a current select list, buttons, etc. of a current one

 Create Project: I would have text fields for issue types, custom fields, select list/values, per issue types

 New Issue Type: description would include all fields and workflow desired.

Workflow: Select list of Create, update, delete. Description of what needed.

Other: Select list of Notification Scheme, permission scheme, field configuration, other

 This should get you started. If you aren't familiar with your CR process there should be a configuration management person to talk to.

 The goal is to manage what you do and be able to track who asked for what. For instance, if someone wants a new custom field you want to check to see if there already is one you can use that they don't know about. JIRA will let you have multiple custom fields with the same name, which will just confuse you.

0 votes

You can do it with apps (I don't use a lot of Power Scripts because I almost always have Scriptrunner on tap, but it might be able to support you.  I know SR can).

But you'll need to build somewhere for the scripts to go.  You'll need to builf projects with issues and workflows that your non-admins can use to trigger scripts that can update the schemes without granting admin to the users, and that's going to get complicated (and expensive) fast.

I'd recommend looking in the marketplace for delegated administration apps in stead.

Hi @Nic Brough _Adaptavist_  My requirement is that I want to rerstrict jira admins who already have the right to edit workflow schemes, issuetype schemes, etc.  from editing a few particular schemes. I believe what you are suggesting is a reverse of that- that any non admin can trigger a script to make changes to the scheme.

Joe Pitt Community Leader Dec 10, 2021

@Soham Das Frankly, if you can't control your admins and don't have a change control process you system is out of control and remain that way. 

Your "requirement" is not really a requirement, it's an attempt to fix something that is broken with a technical solution.

Your reuirement is actually "get admins to stop breaking things".  The real fix for that is to stop having admins who don't know what they are doing.

Like Joe Pitt likes this

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