Prevent users from Accessing Jira Cloud during change.

Emerico Vespucci November 19, 2022

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

Suggest an answer

Log in or Sign up to answer
1 vote
Answer accepted
Alex Koxaras _Relational_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 19, 2022

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

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_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 19, 2022

@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
Emerico Vespucci November 20, 2022

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
Gary Spross
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 19, 2022

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

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

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
Emerico Vespucci November 20, 2022

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

S Fong November 27, 2022

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
Johnny FromCanada November 19, 2022

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

Emerico Vespucci November 19, 2022

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
Alex Koxaras _Relational_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 19, 2022

@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 November 19, 2022

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 November 20, 2022

@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 November 20, 2022

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
David Cross November 19, 2022

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

TAGS
AUG Leaders

Atlassian Community Events