nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Comments

Gary Spross_o1iwv6

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.

Alex Koxaras -Relational-

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.

David Cross_g591vx

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

Johnny FromCanada

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

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.

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

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.

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.

David Cross_g591vx

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

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.

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.

Emerico Vespucci

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud