Prevent users from Accessing Jira Cloud during change.

[Emerico Vespucci]

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

[Alex Koxaras _Relational_ · Accepted solution]

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.

[Emerico Vespucci]

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.   

[Alex Koxaras _Relational_]

@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.

[Emerico Vespucci]

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.

[Gary Spross · Accepted solution]

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.

[Emerico Vespucci]

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.

[David Cross]

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.       

[Emerico Vespucci]

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

[S Fong]

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.

[Johnny FromCanada · Accepted solution]

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

[Emerico Vespucci]

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

[Alex Koxaras _Relational_]

@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.

[Emerico Vespucci]

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.  

[Johnny FromCanada]

@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.

[Emerico Vespucci]

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. 

[David Cross · Accepted solution]

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