Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,362,097
Community Members
 
Community Events
168
Community Groups

Announcement: Introducing two new permissions to replace Browse Projects permission

G’day Atlassian community!

We’re excited to announce the addition of 2 new permissions to replace the “Browse Projects” permission. This is meant to give Jira administrators more fine-grained control over who can view the projects and issues.

What is the change?

As you may know, the “Browse Projects” permission has dual functionality. It is used to check both

  1. if a user can view projects

  2. and if a user can view the issues within the project.

In other words, it can be used to act at the Project Level e.g. permission to view the projects directory, and at the Issue Level e.g. the ability to view an issue. Since all the other permissions either work at the Issue Level (e.g. "Edit Issues") or at the Project Level (e.g. "Administer Projects"), the current way of working with the “Browse Projects” permission is unique and problematic.

By splitting the “Browse Projects” permission into two, we can give users more fine-grained control over Jira’s permissions. Each of the new permissions can have its own distinct role and that’s what we have done.

  1. “View Projects” is a project-level permission for viewing projects in Jira. It is the permission to view the projects directory page and the ability to select that project in various dropdowns such as in JQL.

  2. “View Issues” is issue-level permission for viewing the issues within a project.

Therefore, “View Issues” can be used to control who can view issues within a project and “View Projects” can be used to control who can view projects in the projects directory.

Since we have introduced these two new permissions that fulfill the same purpose as the “Browse Projects” permission, we are deprecating the “Browse Projects” permission. We will stop supporting it eventually.

What can you expect while using Jira?

Firstly, you will notice some changes to Jira’s permissions scheme page. These are as follows:

  • The “View Projects” permission will appear under the “Project permissions” category, with a “New” tag.

  • The “View Issues” permission will appear under the “Issue permissions” category, with a “New” tag.

  • If a grant is made to “View Issues” permission, the corresponding grant should be added to the“View Projects” permission as well. For eg: If you want the “administrators” group to have access to issues for a project, the grant has to be made to both “View Issues” and “View Projects” permission.

  • A “Deprecated” tag will be shown next to the “Browse Projects” permission. This means we strongly encourage you to avoid using the “Browse Projects” permission. Instead, use the “View Projects” permission and the “View Issues” permission.

  • If you were to use the “Browse Projects” permission, internally it would still translate to “View Projects” and “View Issues” permissions, but that support will go away after some time, so please don’t use it!

Getting information on permissions of a project will return information on “Browse Projects” as well as about “View Projects” and “View Issues” permissions. However, since support for “Browse Projects” permission will eventually be withdrawn, it is highly recommended to use “View Projects” and “View Issues”.

When it will reach me?

We will roll out this change to all of our customers in phases over the next few weeks. Since this change involves a deprecation, we strongly recommend and urge all customers to plan for and adopt the above changes. Meanwhile, we welcome feedback from you.

Show me the changes!

Here are some screenshots from the Permission Schemes page that indicates the changes mentioned above.

a93e6e13-5d69-4323-914c-1737b98d71a7.png

Image 1: Browse Projects has a “Deprecated” tag with it, and View Projects has a “New” tag with it
d6b39f3a-9374-4203-ae6d-5adfe60cad62.png
Image 2: View Issues lie under the “Issue Permissions” category, with a “New” tag with it

Thank you in advance for working through these changes and for your continued support. Please reach out to us in case of any concern by commenting on this post.

Best,

Varad Pingale

Jira PM

33 comments

Thanks for this, @Varad Pingale  - looks like a beneficial update. I wonder when the deprecation and change over will happen?

Also, on this point "If you were to use the “Browse Projects” permission, internally it would still translate to “View Projects” and “View Issues” permissions..." - does that mean that IF we do nothing and if we reach the deprecation date, all users/groups that currently have Browse Projects permission, will have “View Projects” and “View Issues” permissions automatically right?

Thank you for the Announcement!

Like # people like this
Dave Wuensch Community Leader Aug 16, 2022

Hi @Varad Pingale 
thanks for sharing the information.

Like Varad Pingale likes this
Rilwan Ahmed Community Leader Aug 16, 2022

Hi @Varad Pingale 

This is good update. 

Just wanted to know, if a user is granted "View project" permission and not "view issue", will the user be able to see the tickets in the JQL result ? 

  • If not, then I think the JQL purpose of the View project is invalid. i.e. What will the user gain in adding the project in the jql where he cannot view the issue.  
  • If user can see the tickets, then we should re-think on the View issue permission. 
Like # people like this

Thx @Varad Pingale   from what  Jira DC version will this be available? 

Like # people like this

Where are the associated API change docs?

Like # people like this

This change does not make any sense - why would you search for issues if you can't view them? What is the purpose of viewing a project when you can not interact with its content?

Why didn't you just clarify the wording of "Browse projects"?

Also, what are the implications for apps and integrations?

Why is there no advanced announcement in the developer community?

Like # people like this

Hey @Varad Pingale, thank you for the update. As @Yatish Madhav is correctly pointing out, what is gonna happen if we do not update the Permission Schema for the current 'Browse Project' one? Should we expect Jira to 'automatically' grant the brand new permissions to the definened roles/groups etc.?

Like # people like this

Thank you in advance for working through these changes

Well, it would have been nice to know in advance, but the changes seem to be rolling out to production right away

How is this going to work for migrations from DC, where the permission is not deprecated? I assume the migration will just convert Browse to the two new permissions?

Like # people like this

Why do you have a "View Projects" permission giving access to one project when it indicates multiple? Shouldn't that be "View Project" (especially if we are trying to reduce confusion)

Like # people like this
Pramodh M Community Leader Aug 16, 2022

Thanks for the update @Varad Pingale 

Phumi Atlassian Team Aug 17, 2022

Thanks team! 

Dave Mathijs Community Leader Aug 17, 2022

@Varad Pingale Please implement this for Data Center as well.

Like # people like this

@Varad Pingale thank you for sharing the upcoming updates around permissions. While on the topic of new permissions, could you let us know if your team is also considering adding the highly requested permission to manage releases?

JSWCLOUD-17608JRACLOUD-34015JRACLOUD-67414JRACLOUD-63780JRACLOUD-12891

Like # people like this

A few questions:

  1. Will the migration using JCMA support automatically the conversion from "Browse Project" to "View Project" and "View Issues"?
  2. Will the migration from Cloud to DC automatically merge these 2 permissions into "Browse Project" permission before exporting for DC?
  3. Will JQL allow the user to select the project but see no results if they only have the "View Project" permission?
  4. If a user has "View Project" permission and "Create Issue" permission, will they be able to create tickets in the project but not see them?
  5. How is JSM impacted by this change?
Like # people like this
Jimmy Seddon Community Leader Aug 17, 2022

Thank for for sharing @Varad Pingale!  Providing information is better than changes happening with zero communication about them.  However, much like a number of the of the others commenting on this post, I'm very confused bout how thing change is supposed to work.

I'm going to come at this from a different angle.  If I have "View Issues" but I DON'T have "View Projects" are you telling me that I can see issues within a project but a can't use the project as a value to search for issues in JQL?

I'm trying to understand the value added by the "View Projects" permission.  Any clarification you can provide with be extremely helpful.

Thanks!

Like # people like this

If a grant is made to “View Issues” permission, the corresponding grant should be added to the“View Projects” permission as well. For eg: If you want the “administrators” group to have access to issues for a project, the grant has to be made to both “View Issues” and “View Projects” permission.

I'm afraid in a couple years this will be another one of Jira's quirks that everyone will hate and provides zero value to anyone. View Project should definitely be automatic if View Issues is granted.

That aside, while you're changing the permission model, can you also split "Administer Project" to its components? Mostly the following individual permissions are needed:

  • Manage Components and Versions
  • Change Project Settings
  • Manage Project Members
Like # people like this

I am also curious about the impact if no changes are made in our Permission settings... i.e. will Browse Projects default to having both View Projects and View Issues?

Like # people like this
John Funk Community Leader Aug 22, 2022

Will this be implemented for all platforms? 

Hi @Yatish Madhav 

Thanks for the response.

The removal of support for Browse Projects is planned to start from Mar’23. We will keep all of you posted if there are any updates on it.

Meanwhile, we are working with our marketplace partners to test these changes, and to ensure all apps work smoothly.

To answer your question - Yes, if admins do nothing, and reach the deprecation date, all users/ groups that currently have Browse Projects permission will have “View projects” and “View Issues” permission automatically.

Like # people like this

Hi  @Alex Gay 

This change is currently planned only for Jira Cloud.

If there is a similar change planned for Jira DC, a separate announcement will be made in the DataCenter community group.

Hi @Boris Berenberg - Modus Create 

Thanks for the response.

We have released the developer community post for this, which contains basic details about the API changes. We are currently running an EAP program for our marketplace partners. Once we start rolling it out to everyone, we will update the associated API change docs as well.

Hi @John Soukup 

Thanks for the response.

I understand these are highly requested features in the permissions space, although it isn't something we are currently working on, and we might work on this in the longer term.

I can see a use case where I might want a user to be able to see a project in a drop-down menu but not allow them to browse the issues in that project. I can't think of a specific use-case for that off the top of my head but I think the flexibility is good. What I don't understand is why it is only being implemented in the cloud. The farther cloud and DC deviate the harder it is going to be for customers to migrate between the two.

In the future it would be super helpful for breaking changes like this if Atlassian would mention the timeline for removal of whatever is being deprecated and explain the impact to customers if they do not take the required actions prior to that removal. Stating that "support will go away after some time" is not very helpful as that gives me no idea whether I need to start checking every 2-3 days for the new permissions to appear in my instance so that I can update our permission schemes before the old permission is removed.

We shouldn't have to ask those questions in the comments and I am sure that there will be some customers who read this article but not scroll down to read all the comments to get that additional detail.

Like # people like this

Hi @Rick W 

 

Apologies for the delayed reply. Thanks for your patience.

 

We are still evaluating the impact of this change on our Atlassian Ecosystem applications and also reviewing the concerns raised in the comments before we roll out the change. Thus, this has not been rolled out to anyone till date. 

I will update this post by next week (16th Sept) when we have a decision on the final rollout plan, to include the exact timelines of the rollout. Please bear with us till then. 

 

About creating the gap between DC and Cloud products, we accept this as a valid concern. We have ensured that when migration to the cloud happens, it is completely backward compatible and nothing will break. 

 

To the point of announcing such changes in advance, I completely agree with that. I should have done a better job on this by giving advance notice, I will take care of it from this point onward.

 

Regarding the change: As an admin, if you don't take any action, nothing should break. The conversion of permissions will happen automatically, and everything will keep working as it was.

 

I will also update the post to clarify these items so that it does not cause confusion and create anxiety about the change.

 

Thanks & Regards,

Varad

 

Comment

Log in or Sign up to comment