You can see by the following examples how the expected permissions are reflected in the export of the permissions, but not reflected withing the web interface. Testing also indicates that the expected permissions are not being applied to the excluded Project Groups.
Thanks for getting in touch! That certainly doesn’t look right! Sorry about the confusion this issue has caused. Just to confirm, this user’s permissions are working as intended, as in it’s a bug only with the UI not surfacing these project group scopes?
I was able to reproduce this issue where project group scoping is displayed in the web portal in 2019.9.1 LTS in the same way you’ve described, though when testing in 2019.9.8 LTS it correctly displayed the relevant project groups. I can’t spot the specific issue/code change that explains this change in behavior, though are you able to upgrade and let me know if that resolves this bug for you?
I hope this helps, and I look forward to hearing back!
@Kenneth_Bates the expected user permissions are not working as intended, nor are they reflected in the UI. We updated last night to v2019.10.6 and the problem still seems to be present.
In the scenario list above, I have a Project Group called Release Only that is not included in the list of project groups that the Project Contributor can edit, however, the user can still edit projects that are stored inside the Release Only project group.
Thanks for following up, and I’m sorry to hear you’re still hitting this strange issue. That certainly doesn’t sound correct. Would you be willing to supply the actual user’s permission export? I’d like to attempt to reproduce this issue exactly as you have it. This might also help in figuring out what’s going on with your other thread where you’re hitting the issue exporting the permissions (and having to hit the API endpoint directly).
I look forward to hearing back and getting to the bottom of this one!
