Free plan: How to allow a single user to edit/delete issues

Question

I’m an admin of a Jira organization that initially used a Premium trial and has now been downgraded to the Free plan.

During the Premium phase, we managed permissions via permission schemes. Now, on the Free plan, I can no longer manage permissions, but I still need one specific user to be able to edit and delete issues.

From what I understand:

* Permission schemes are not configurable on the Free plan.

The only way I can think of is to grant broader rights or to be making the user a project admin or org/site admin, which feels too powerful for this use case. Is there another way?

Christos Markoulatos -Relational- · Accepted Answer

Hi @Jan

On the Jira Free plan you can’t change permission schemes at all, so it’s not possible to give a single user edit/delete permissions without also giving them broader admin access, the only real options are to make them a project admin (which is the only role that inherits the required edit/delete permissions on Free plans), make them a site admin (even more powerful), or and only for delete operations, use a manual‑trigger automation, but even that can only be executed by site admins, meaning it still doesn’t solve the single normal user requirement. In short, Jira Free doesn’t support granular permissions, and upgrading to a paid plan is the only way to customize these rights.
Unfortunately there no workaround that i know of!

Rebekka Heilmann (viadee) · Accepted Answer

Hi @Jan

If i interpret this article correctly...: Permissions limitations in Free Jira sites | Atlassian Support

If you downgrade from a paid version of Jira or migrating from Jira Data Center to a Free Jira Cloud site, your existing permissions schemes, space roles, and work item security schemes will be preserved but can’t be edited.

The only way to make changes to them is to upgrade to Standard, Premium, or Enterprise versions of Jira.

So:

Start another free Trial (Standard or Premium)

Create a group "delete-permission" (or whatever you want to call it)

Add that group to the Permission schemes of the projects OR add that single user, but the group gives you more flexibility. Remove any Space role etc. from the permission that you don't want

Make sure all Spaces have that scheme

Downgrade to free

Schemes and Permissions should be preserved and therefore anyone in the delete-permission group -and only them- should be able to delete issues.

Not tried myself but that'd be my approach.

Ollie Guan · Accepted Answer

Hi @Jan ,

On the Free plan, if you don’t want to upgrade but want only one user to edit/delete issues:

* You can’t configure permission schemes (no permission UI on Free).

* You only have:

* Site/organization admin

* Project admin

* Any old, preserved permission scheme (not editable).

So the simplest non-upgrade solution is to make that user a project admin (or site admin) so they can edit/delete issues.

This gives them broader access than just edit/delete, but there is no more fine‑grained option on the Free plan.

Trudy P Claspill · Accepted Answer

Hello @Jan

When you have a subscription that was on the Premium (or Standard) plan and you customized permission schemes, then you downgrade to Free, the permission schemes you previously set will still be enforced, and the assignment of users to Project Roles will be retained.

However, you won't be able to assign more users to Project Roles going forward. So the recommendation to assign the user to the project Administrator role, as advised by others in their responses, won't be available to you.

This is stated here:

https://support.atlassian.com/jira-cloud-administration/docs/what-is-the-free-jira-cloud-plan/

You can temporarily upgrade your subscription to Standard to again get access temporarily to assigning users to Project Roles and modifying the Permission Schemes. When you downgrade again, the changes will be retained.

Given that you want to stay on a free version ultimately, the better path forward would be to temporarily upgrade, modify your Permission Schemes to leverage User Groups instead of Project Roles, and then go forward with assigning user to User Groups to manage their permissions.

After downgrading again you will still be able to add and remove users in User Groups. And you can change projects to use the customized Permission Schemes you set up while upgraded. In that manner you can enforce more customized permissions in your projects.

For any new projects you create that don't share one of your custom Permission Scheme the project will get the default scheme where "Any logged in user" has essentially all the permissions - the most open of the permission configurations.

Note all the above applies only to Company-managed projects. For Team-managed project permission management is different.

Normally in Free plans where there was never a time in a Standard or Premium subscription and permissions/roles were never customized, all people granted a User license for the app are the equivalent of Project Administrators without explicitly being assigned to the role. And the default permission schemes grant all permissions to "Any logged in user".