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; } } }

Make entire Jira Data Center instance READ ONLY

Aisha M

We are currently in the process of migrating from Jira DC to Jira Cloud. Post migration, we want users to be able to view and reference their existing work in the Data Center , but not be able to make many changes - Just to give users time to adapt to the new Cloud environment,

Is there a way to make the entire DC instance READ-ONLY except for the jira-admins maybe ? We'd like users to have view access without the ability to edit issues, filters, or dashboards until they're fully onboarded to the Cloud set-up.

Would tweaking the permission scheme help achieve this ?

Any advice or workarounds would be greatly appreciated.

Will the below approach work:

Only view issue permission for users
Disable all automations
Disable Structure - As users can find a loophole and create or modify issues from here

Accepted answers

All comments

Evgenii

Hi, @Aisha M

Jira, unlike Confluence, don't have such functionality.

You can use next workaround - create separate permission scheme for migration, with view only permissions for all (and full permissions for administrators managing migration).
Assign it to all projects, and it will do what you want.

Don't forget to make a backup of permission scheme assignement before applying changes.

Nikola Perisic

Hello @Aisha M

For company-managed, a new permission scheme would be addded to the project that for Browse projects permission will only have jira-admins group.

For team-managed projects, just use Private access level where jira-admins will be added.

Christos Markoulatos -Relational-

Hi @Aisha M

Your approach is solid, and the combination you've outlined will get you most of the way there. There is no native read-only mode in Jira Data Center, it simply doesn't exist as a feature, so a layered workaround is the correct path.

For issues and projects, your permission scheme approach is right. Create one "read-only" permission scheme that grants only Browse Projects to your regular users, keep full permissions for the jira-administrators group, then associate it with all projects. This is exactly how Atlassian's own migration tooling recommends locking down projects during a migration, by remapping all projects to a new restricted permission scheme. The downside is that you'll need to reassociate every project, but if you have a manageable number it's the cleanest option.

For filters and dashboards, users can still create and edit their own personal filters and dashboards even with a stripped-down permission scheme, because those are governed by Global Permissions, not project permissions. You can remove the "Create Shared Objects" global permission (Administration > System > Global Permissions) to prevent users from creating new shared filters and dashboards, which closes the most common loophole. You won't be able to prevent users from editing their own private filters entirely without removing application access, but shared content is lockable. On Structure specifically, your concern is valid. If Structure is licensed and active, users with the right Structure permissions can still interact with issues through it, so disabling or heavily restricting Structure roles for non-admins during the transition period is the right call.

The practical summary: permission scheme for issues, global permission strip for shared filters/dashboards, and Structure restrictions for that app specifically. It won't be a single toggle, but the combination covers the main vectors.

Hope this helps!

Helpful links:

Aisha M

@Christos Markoulatos -Relational- Thank you for the detailed outline. Appreciate it !

I'm not sure my org would be willing to put in the work for associating the projects to a new permission scheme . . We have around 7000+ projects, and that would be a huge effort by itself. But on the positive side, all our projects (7000+) use 2 specific permission schemes . . Would updating the original one work ? Also, this is just to help users ease into the Cloud environment and help them with the transition. They will be having a fully functional Cloud instance with all their projects. So, changing the exiting scheme doesn't seem too bad.

About the filters and dashboards, let me research a bit more on the "Create Shared Objects". I was under the impression, stripping the create/edit permissions would work. But I also do not want the users to not be able to look back at their queries and filters, because, the Cloud has a lot of differences when it comes to filters, and I'm certain most of them would be broken after the migration.

If Structure provides the capability of helping users despite the locked permissions, we wouldn't mind restricting the edit permissions on Structures to just the admins for now.

Aisha M

@Evgenii Thank you for the reply ! I don't think we are willing to put in the effort of assigning around 7000+ projects to a new scheme. Maybe we might edit the existing one.

My biggest concern now is regarding Dashboards & Structure, if users will still be able to modify or create issues despite the restricted permissions.

Evgenii

Yes, of course.

If you have 2 sschemes for 7000 projects - you can modify them, remove all permissions, for migration process, and after migration - restore back.

Evgenii

Sorry, missed part about structures and dashboards.
Don't worry, if person can only view issue (according to permission scheme), he can't create, no matter how he will try to do it (structure, create button, dashboard, rest api, etc...)

Christos Markoulatos -Relational-

Hi @Aisha M

Yes updating them will work, just remember the changes u made to revert them before migrating, or copy them to keep a record with another name.

If u stumble upon other questions, let me know!

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-service-management

jira-service-desk-data-center

jira-service-management-data-center