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

[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.

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?

[Brendan Andrews]

Yes you're correct. Once Fred is granted the Set Issue Security permission he can see all issues - and not edit them - which is good. That may have been the item I hadn't considered.

On Set Issue Security there is Internal (default), External and none (I'd prefer not to have none but it seems it's mandatory?)

External people are given only rights to External, while the 'group' of internalpeople get both. In my initial example I had not assigned the group which gives these rights to Fred. (I still feel like my initial example wasn't working as expected, but happy to move on.)

If I could ask your advice: I am using the internal 'group' (which grants Issue Security) to projects in the (default) users role. But that means everyone internally can see every project. Can you recommend how to be more selective about who sees what projects when using issue security?

[Nic Brough -Adaptavist-]

Sorry, I missed the email before.

You can't "grant Fred Set Issue Security permission" directly - you have to go through a permissions rule of some form to get there. That rule is very important to understand before I can work out what is going on here (even if the rule is "grant individual user Fred". Which it isn't because that wouldn't change the behaviour in the way you've seen it).

Can you explain exactly what is on the "set issue security" line in the permission scheme?

Secondly, the issue security scheme is related, but separate to the permission scheme - it has the same sort of rules, but what are the rules for Internal and External?

[Brendan Andrews]

OK - here's what we have:

Issue Security is one of Internal/External/None

Set Issue Security is granted to the project roles:

developer

external

Security Level permissions are:

External

- Project Role External

- Group: Internal

Internal

- Group: Internal

This internal group is used in Confluence too to restrict spaces to only the company's people. So how best to show some and hide other projects from internal users? I suspect I need to change the use of groups and roles.

[Nic Brough -Adaptavist-]

Yes, that makes sense now. Your setup basically allows "internal" to see everything, no matter what the settings are (they're named in External and Internal security levels, and, of course, are implied by "none"). To hide things from internal, you'll need to set up schemes that do not include them