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

Project Role Permissions not always having effect

Brendan Andrews

I've distilled this to quite a simple case, in an on-demand instance.

I'm using a slightly modified copy of the default Permission Scheme (I've added to it, not removed). The steps below are what I took after permissions didn't work as expected.

In my example the user Fred is a member of the developers, users and (a new custom) Team group.

In project roles, I started with no users or groups in the roles and then added the Team group to the developer and user role.

But this didn't give Fred any access to the project issues. He could see the project, but no issues.

Then I directly added Fred to those roles. No change.

Next, I added the developer group to the developer role, and the user group to the user role. Still nothing.

So I removed the Team group from the Project Roles - no change.

Then I removed Fred user from its direct inclusion in project roles - and bingo, it works.

This seems to indicate that granting access by either a user or custom group doesn't work and that there are issues with combinations.

Am I misinterpreting something or is there an issue to avoid?

Brendan

Accepted answers

All comments

Nic Brough -Adaptavist-

>But this didn't give Fred any access to the project issues. He could see the project, but no issues.

What you've described sounds like you've done everything right, but there's something else going on. Is there a "security scheme" on the project? I ask because if a user can see a *project* then they should be able to see the issues within it, except for ones being hidden by a security scheme.

There's also the very obvious question, which I assume you've checked already - are there actually any issues to see? The reason for asking that is not to suggest you haven't checked, but to lead you to another useful test - can you get Fred to Create and issue in the project? What message does he get after creating it? (Ideally, use the full-screen - right click on "create issue" and "open in a new window/tab)

Brendan Andrews

Thanks Nic,

Fred can see issues he creates, yes.

There is a security scheme yes - the typical external / internal split to allow outside parties to see issues set to other than the defaul internal security. But if I give Fred access to the security scheme, he can change the value as well as seeing the issues, can't he? And really I just want to grant the ability to view issues, not edit any part of them.

Nic Brough (Adaptavist)

Ok, still two lines of enquiry here...

So, Fred can see issues he creates, but no others? That implies the use of "current reporter browse" permissions somewhere. But still strongly indicates the other line of enquiry...

On the security scheme side - it sounds like this is the case. I'd say Fred is able to see his own issues because the security scheme is blocking access to the rest.

The security schemes are all about view, they don't determine edit rights. Although if they block read of an issue, then they also block edits. This is quite difficult to work through, but you've given us the permissions related to Fred - could you also detail the issue security scheme for us?

Nic Brough -Adaptavist-

Ok, still two lines of enquiry here...

So, Fred can see issues he creates, but no others? That implies the use of "current reporter browse" permissions somewhere. But still strongly indicates the other line of enquiry...

On the security scheme side - it sounds like this is the case. I'd say Fred is able to see his own issues because the security scheme is blocking access to the rest.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud