Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

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,463,543
Community Members
 
Community Events
176
Community Groups

Prevent users from Accessing Jira Cloud during change.

We will be releasing a new workflow in the coming weeks. I need a mechanism in which to prevent the users from accessing and creating content in Jira Cloud during our changes. 

My team, the admins, will need access to apply the changes.

We had a process in datacenter, but I want to see what is recommended. 

 

Thanks

 

4 answers

4 accepted

1 vote
Answer accepted

Hi @Emerico Vespucci 

If this workflow is for one project or for a bunch of project with shared workflow (and permissions), then remove the create/edit/assign/transition issue, modify reporter etc from all users but admins.

Luckily, our shop utilizes the same workflows and all scheme types for all projects. This initiative will be converting issue types, statuses, workflows, etc for the centralized objects.   

@Emerico Vespucci then you have to make your project read-only and make the changes. After finishing the migration of the workflow and all relative jobs, then revert back to the original permission scheme. You can either tweak the current, or create a new one, assign it to the project till maintenance is over and then associate back the old one.

Like Kalin U likes this

As of now, my intent is to replicate what we used to do on datacenter. Create a copy and modify the current permissions scheme.  Attach it to all the projects before the changes and then associate the original permission scheme back once complete.

Like Kerli Loopman likes this
1 vote
Answer accepted

I had to do a workflow change just recently. The project has over 80k issues so I knew from testing it would take around 2 hours to complete. I just warned everyone ahead of time and did it after hours when I knew nobody would be making changes.

All that said, another option I thought of, for future changes, was to have a permission scheme ready that would limit the project to just the jira-administrators group. That would ensure nobody else could be making changes.

Hello Gary, Yes, that is one option we applied in the past. We created an active directory group, which is added to the Jira Software group. All jira users are requited to be in this group. In the past, in datancenter, we removed this group from the permission scheme.

I suspect it'll be safer and better in the long-term to create a copy of the existing permissions scheme, change the copied scheme so that only site-admins can make changes, associate the copied scheme with your projects, make your workflow changes, then re-associate the original scheme to your projects and retain the copied scheme for future changes.       

Like # people like this

That is what we will be doing. This was our practice on datacenter. Thanks 

I am about to say the same...create a new permission scheme and temporary switching it to prevent the status update for this specific project only.

0 votes
Answer accepted

Is a single shared workflow really that far-reaching that it needs such lock-out control?

Yes, the whole company uses the same workflow as well as all other schemes. Thank goodness. We have another instance we are migrating off of, which resembles the wild west

Like Johnny FromCanada likes this

@Johnny FromCanada 

  • @Emerico Vespucci never mentioned that this workflow is shared. We all make assumptions.
  • A new workflow can be complicated if this involves new custom field, workflow automations for imposing security levels and micro-management of issues in a single status, which for a strange reason should be migrated to more than one new statuses.

In any case, it would be handy if we knew the reason for his requirement, if we wanted to propose a more suitable solution, but to me is irrelevant if he and his team chose to proceed with this decision.

Correct. The new workflow will involve mapping old statuses to new statuses. adding post functions and conditions. In addition, we are deprecating an issue type and converting it to another.  This takes the system three hours.

Regardless of why we are doing it, the system will take hours to complete these tasks as it has to update all stories for all projects using the old statuses and issue types. 

We do not want users creating additional content during this process.  

@Emerico Vespucci - Is this change-over urgent?  What is the need for the whole org to have the same workflow?  You could consider self-organizing / self-managing teams, and decentralize ownership of their way of work (where you still assist them with admin).  And now could be an ideal time to make such a transition happen.  Just some thoughts.

We are centralizing off of multiple Jira instances where there was infinite workflows, issue types, statuses, permission schemes, screen schemes, etc., etc. 

We now use Jira Align, which expects statues and many other consistent entities. Jira Cloud is part of our release management process for developers and connected to our devops tooling pipeline. Bitbucket, SonarQube, Cloudbees, Checkmarx, Artifactory, etc

The centralized model provides for a full vision of all the work across the enterprise portfolio. We can now accurately track our initiatives across the organization using a consistent model. Jira is one component. 

Our other Jira instances are like you described. The wild west. We're shutting those down. 

0 votes
Answer accepted

Depending the precise scenario you might find it useful to create a new temporary permission scheme and associate it with the projects that you don't want folks to change.

This page describes the general approach albeit for a different scenario creating read-only users.

https://confluence.atlassian.com/jirakb/jira-cloud-how-to-create-a-read-only-user-779160729.html

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events