Announcement: Introducing two new permissions to replace Browse Projects permission

[Paul Campbell]

"As an admin, if you don't take any action, nothing should break."

Our permissions have been broken due to this change.  We use a custom field to grant internal users permissions to view an Issue and for a department to @ them in the comments of the ticket.

We are disallowed from using the same "User custom field value" in "View Projects" now. We can no longer @ mention our teammates in the comments of a ticket but they can view the Issue.
(I already have a support ticket open on the matter)
See image attached:

[Andrew Laden]

I'm sensing a pattern here. First the OpsGenie change that that presented and then postponed due to user complaints https://community.atlassian.com/t5/Opsgenie-articles/Update-We-are-re-evaluating-escalation-limits-in-Opsgenie/ba-p/2128161 and now this.

I think atlassian needs to take a long hard look at how they develop new "features" and how they present them to the customers. Maybe concentrate on fixing the bugs that users want fixed first.

[Paula Hidalgo]

@Varad Pingale - Please help clarify what will happen for the various use cases below.  Make corrections to the table where my assumptions are wrong.  I need to understand how these permissions interact with issue-level security.  Can issue-level security override "View Issues" permission (i.e. user does not have "View Issues" permission is permitted access to a specific issue via the issue-level security scheme) ?

Example Project XYZ

• has project key of XYZ
• issue XYZ-1 Summary is "Plan team work" and no issue-level security
• issue XYZ-2 Summary is "Plan top secret team work" and has issue-level security = Top Secret
• No other issues on the cloud have the word "team" (or variant) in the Summary field

	View Project = Yes View Issues = Yes	View Project = Yes View Issues = No	View Project = No View Issues = Yes	View Project = No View Issues = No
Project is listed in Project Directory	Yes	Yes	No	No
Able to select project in dropdowns?	Yes	Yes	No	No
JQL: project = XYZ	Issues in XYZ returned	No issues returned	The value 'XYZ' does not exist for the field 'project'	The value 'XYZ' does not exist for the field 'project'
JQL: issue = XYZ-1	Issue XYZ-1 returned	Issue does not exist or you do not have permission to see it.	Issue XYZ-1 returned	Issue does not exist or you do not have permission to see it.
JQL: issue = XYZ-2 User does not have "Top Secret" permission	Issue does not exist or you do not have permission to see it.	Issue does not exist or you do not have permission to see it.	Issue does not exist or you do not have permission to see it.	Issue does not exist or you do not have permission to see it.
JQL: issue = XYZ-2 User DOES have "Top Secret" permission	Issue XYZ-2 returned	Issue XYZ-2 returned	Issue XYZ-2 returned	Issue XYZ-2 returned
JQL: summary ~ team User does not have "Top Secret" permission	Issue XYZ-1 returned	No issues returned	Issue XYZ-1 returned	No issues returned
JQL: summary ~ team User DOES have "Top Secret" permission	Issue XYZ-1 and XYZ-2 returned	Issue XYZ-2 returned	Issue XYZ-1 and XYZ-2 returned	Issue XYZ-2 returned

cc: @Jessica Ray 

[Curt Holley]

@Varad Pingale 

Is the View Projects permission actually plural, or singular? 

As in, if not applied in project A, but applied in project B, does that mean they can not find project A in the Project directory/JQL etc. but can find project B and any other projects they happen to have the view projects permission for?

If by change, a User ends up not having the View Projects permission in any projects, does that mean they cannot see any projects at all in Jira?

Sorry, but I'll admit, I'm somewhat confused about a  "Viewing Projects" permission that is configured at the project level....unless it is only about that project.

[Andre Schmidt]

Great news!

[Eglė Kaziulionytė]

One more place for admins to troubleshoot access problems... Security levels, "View issue" permission, what else will come?... :/ 

[serge calderara]

This view Project and Browse project separation permission is absolutly of  non sens and not logic at all.

This is absolutly stupid to have a Brwose Project permission set just to list project in jQL while you will not be able to see the return isssue of that project if you do not have the View issue pernission set as you describe.

I am sorry to say again but I wonder where and how sometime you team gets such basic reflexion which bring no added value at all.

A single permission of View project would have been more than enough.

I would be interresting to know the use case where you have only the View Project permission and only the Vie Issue perimission

That will be a big mess if you have project with issue security restriction.

@Varad Pingale think twice before implementing new feature and have more open mind. Better concentrate on bug fixing that people are waiting to be solve instead of implementing such uselesss feature at this point with so few reflexion

[Patrick Vijgeboom]

Question: We still have the Server edition of Jira. Will these new permissions also be available for Server?

[S Fong]

I don't see this change in my Jira Cloud instance.  When will it roll out?

Thanks,

Sylvia

[Leo Diaz _ DEISER]

Hi @Varad Pingale 

Are there any updates?

Cheers,

Leo

[Varad Pingale]

Hey @Leo Diaz _ DEISER @S Fong 

Thank you for the follow-up, and apologies for the delay in reply.

Our team is still evaluating the comments on this post, ensuring we are addressing them before rolling out the change.

Thus, the rollout is paused at the moment, and you might not see the change in your instances.

I will post an update on the release of this change by 6th Oct'22.

Kindly bear with me till then. Thanks for your patience.

[Varad Pingale]

Update on the above announcement:

On Aug 16, 2022, we announced “Introducing two new permissions to replace Browse Projects permission“. It was planned to be released by end of September 2022.

We’ve since received feedback from many of you on this being a fundamental change in how permissions behave, and requirement of more notice period to comprehend the change. As a result, we have decided to NOT rollout this change on Jira Cloud for next 6 months, till 31st March’23.

This means, Browse projects permission will continue to work as it is, and the two new permissions won’t be introduced.

Meanwhile, our team will evaluate the different cases mentioned in the comments to ensure all of them are addressed properly. We will inform you well in advance about the revised timeline of the rollout.

Thank you for your feedback and apologies for any confusion caused by the earlier announcement.

If you have any questions, please drop them in the comments section. We will keep you posted.

I will also update the article to reflect this change.

Thank You

[Lars Fessler]

Hi @Varad Pingale

we would dy to have these two distinctive permissions in Data Center. It would really help us to juggle sensitive projects - even their names are sensitive - and the ability to assign some tasks of these projects to people who are otherwise not participating in the project.

As it is now to do this you have to change project permissions to let these people browse the project instead of simply assigning the issue after having properly configured issue security once.

We would really appreciate if you would consider porting this change to Data Center.

Best Regards,

Lars

[Varad Pingale]

Sure @Lars Fessler 
I will convey this requirement to the Jira Data Center team.

Thanks

[Paula Hidalgo]

@Varad Pingale - Will REST API be updated to include the two new permission parameters as well?

The built in Jira permissions listed in the Get all permission schemes will need to include both the new permissions, for example VIEW_PROJECTS and VIEW_ISSUES.  More importantly permission schemes can set the 2 new permissions via the Update permission scheme

@Jessica Ray 

[Lars Fessler]

Hi @Varad Pingale

thank you! :-)

[Varad Pingale]

Hi @Paula Hidalgo 

Thank you for the questions.

I will get back to you on the various cases you mentioned around the new permissions.

Regarding the REST API - Yes, they will be updated to include the two new permission parameters.

[Rick Westbrock]

Is this still slated to start rolling out on March 31 (one month from now)?

[Thomas Berger]

I'm also curious if the March 31 2023 as golive date still stands? @Varad Pingale 

[Varad Pingale]

Hi @Rick Westbrock , @Thomas Berger 

We are in process of fixing the cases mentioned in earlier comments.

Given the change's complexity, we expect some more delay in the rollout.

Thus, the timeline can be extended beyond 31st March 2023. We will share the update about that by next week.

[Ben Romberg - codefortynine]

@Varad Pingale "next week" has passed and it would be good to get an update since March 31st is only 1 week away. Please also update your post on the developer community, thanks!

[Varad Pingale]

Update on above announcement:

We had earlier announced that “Introduction of two new permissions to replace Browse Project permission” was planned for release on 31st March ’23. Since then, our customers and partners have raised a few questions regarding the rollout, which we are still in the process of addressing. As a result, we have decided to NOT rollout this change on 31st March ’23 for Jira Cloud.

This means, Browse projects permission will continue to work as it is, and the two new permissions won’t be introduced until further notice.

Meanwhile, this work is still a priority for us, and our team is evaluating all the questions and concerns mentioned in the comments. This process of evaluation will take a few more weeks. Following the evaluation, we will inform you about the revised timeline for rollout, well in advance.

Thank you for your feedback. If you have any questions, please drop them in the comments section. As mentioned earlier, please expect more communication on this in upcoming few weeks.

Thank you

[Yatish Madhav]

OK great - thanks @Varad Pingale 

[John Funk]

Hi @Varad Pingale  - Thank you for the update.

What if you held a 30 minute Q&A session at Team '23 so people could question and interact?

[Jacques]

Hey @Varad Pingale you might be looking into this much requested permission: Separate Project permissions for Version Management... It's been there for ages and it's reaching 800 votes already.