You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background: There may be situations where there was an easy way for an admin to update a members ribbon rack that didn't involve the DEV TEAM editing the record in the database directly. A limited number of admins can actually masquerade as a user...they can log in as themselves, search for the user, click an icon that most of you don't see and for all practical purposes, they are now logged in as that user. They see everything filtered through that users permissions, etc. The admin has no admin privs at all. All they can do is return to their original user. It's a higher level permission than ALL_PERMS. The only way that an admin can give the USER_MASQ permissions to someone is if THEY have it. There's one other permission like that as well, for doing CrUD operations on the config table in the database, and there is an easy mechanism for adding other permissions to the list of perms that you have to have to be able to give. So, in 95% of the cases, one of these very lucky admins could masquerade as the user and update their ribbon rack. However, there are a few awards that are not editable via the ribbon rack interface -- the SWP, MCAM and a few others.
So, here's what we need:
A new permission to allow someone to edit another members ribbon rack
On Aug 29, 2018, at 11:03 PM, rmatheny ***@***.***> wrote:
Initial spec has been written and uploaded to the TRMN Synology
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Uh oh!
There was an error while loading. Please reload this page.
Background: There may be situations where there was an easy way for an admin to update a members ribbon rack that didn't involve the DEV TEAM editing the record in the database directly. A limited number of admins can actually masquerade as a user...they can log in as themselves, search for the user, click an icon that most of you don't see and for all practical purposes, they are now logged in as that user. They see everything filtered through that users permissions, etc. The admin has no admin privs at all. All they can do is return to their original user. It's a higher level permission than ALL_PERMS. The only way that an admin can give the USER_MASQ permissions to someone is if THEY have it. There's one other permission like that as well, for doing CrUD operations on the config table in the database, and there is an easy mechanism for adding other permissions to the list of perms that you have to have to be able to give. So, in 95% of the cases, one of these very lucky admins could masquerade as the user and update their ribbon rack. However, there are a few awards that are not editable via the ribbon rack interface -- the SWP, MCAM and a few others.
So, here's what we need:
A new permission to allow someone to edit another members ribbon rack
An icon added to the member's service record if the logged in user has the permission defined in Switch to using Redis for sessions #1 (We will use the Font Awesome "bars" icon for Remove Bower and rely entirely on NPM #2)
When that icon is clicked, the logged in user will be able to edit every award, including the restricted ones
The logged in user will then be able to save the ribbon rack
This permission is giving edit permission to other user's ribbon racks as opposed to logging the super admin in as the user.
The text was updated successfully, but these errors were encountered: