Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

"visible: false" permissions are inadvertently removed on edit

Description

Overview: Saving changes to a user who has permissions with visible: false removes those permissions
Steps to Reproduce:

  1. Make an API request to /perms/users/{id}/permissions?query=indexField=userId to retrieve perms for diku_admin

  2. Log into the UI as diku_admin

  3. Edit the user. Open the "User permissions" accordion and click "Add permissions". Do not actually add any permissions, but click "Save & close" in the modal, then "Save & close" on the user-edit panel.

  4. Make an API request to retrieve perms for diku_admin and compare to the original list

Expected Results: permissions lists should match
Actual Results: visible: false permissions are missing after the user has been edited

Interested parties:

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Checklist

hide

TestRail: Results

Activity

Show:

Zak Burke December 13, 2021 at 3:04 PM

Note also that I'm working on which will alert UI users that editing the permissions of a user with visible: false permissions will be a destructive action. It won't resolve this issue, of course, but it is (hopefully) a helpful step in that folks will at least be notified about the bug they are about to invoke. 

Wayne Schneider December 9, 2021 at 3:22 PM

you'll only encounter this bug if you're doing things in a way that you arguably shouldn't

This does have an effect on "API" or "System" users. Since there is only one way to provision users, and they appear in the Users UI, they can be accidentally broken if this is not resolved.

Zak Burke May 5, 2021 at 9:21 PM

, I think it's low priority as users should not have visible: false permissions assigned to them as part of ordinary operations. That said, diku_admin is a user with many such permissions, and making any edit via the UI will trigger this bug.

In other words, you'll only encounter this bug if you're doing things in a way that you arguably shouldn't. But if you are, and you trigger this bug, it's impossible to restore the "lost" permissions via the UI, and the repercussions can be grave.

Holly Mistlebauer May 5, 2021 at 8:52 PM

:  What is the priority of this bug?  Should we fix it for Juniper?  Thanks...

Zak Burke March 18, 2021 at 4:41 PM
Edited

, , I don't think so. ui-users takes the simple approach of issuing a PUT request to /perms/users/{id} with body's permissions attribute containing the array of permissions that were selected in the UI. This allows the user's permissions to be completely overwritten with a single request, but since we're not collecting the visible: false permissions first, they are omitted from the body, hence this bug. There is a POST endpoint, /perms/users/{id}/permissions, that allows you to add permissions to a user, but then we'd also have to diff the incoming permissions against the original set and issue a series of DELETE requests. That could be kinda messy, and is potentially much slower if there are many DELETE requests. 

IMHO, The Right Thing is to actually to avoid granting permissions with visible: true to users in first place. 

But short of that, we can do one of the following:

  1. If a user has any visible: true permissions, disallow editing of permissions in the UI. probably not toooooo hard, but I don't honestly know. 

  2. In the updatePermissions() function, query for existing visible: true permissions assigned to the user and add them to the request. 

Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Prokopovych

Fix versions

Release

Lotus (R1 2022) Bug Fix

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created March 16, 2021 at 4:01 AM
Updated March 4, 2022 at 4:36 AM
Resolved March 4, 2022 at 4:32 AM
TestRail: Cases
TestRail: Runs