[UIU-1055] Create quick way to add all permissions to user or permission set Created: 03/May/19 Updated: 09/Aug/19 Resolved: 30/Jul/19 |
|
| Status: | Closed |
| Project: | ui-users |
| Components: | None |
| Affects versions: | None |
| Fix versions: | 2.24.1 |
| Type: | Story | Priority: | P3 |
| Reporter: | Ann-Marie Breaux (Inactive) | Assignee: | Zak Burke |
| Resolution: | Done | Votes: | 0 |
| Labels: | cfdemo69 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
| Sprint: | Core: F - Sprint 64, Core: F - Sprint 65, Core: F - Sprint 66, Core: F - Sprint 68, Core: F - Sprint 67, Core: F - Sprint 69 |
| Development Team: | Prokopovych |
| Description |
|
Purpose: To have a quick way to give a user other than diku_admin all permissions. This is useful for testing what non-super users would see. As a FOLIO tester Scenarios
See attached screenshot |
| Comments |
| Comment by Ann-Marie Breaux (Inactive) [ 03/May/19 ] |
|
Cate Boerema I'm not sure what to do with this story or task - where to assign it. It would be super helpful when testing. I just spent 10 minutes creating a new permission set so that I could crete a new user with all permissions, so that I could test a bug fix. What do you think? |
| Comment by Cate Boerema (Inactive) [ 03/May/19 ] |
|
Yes, this would be useful. I think bootstrap data issues go to Core Platform. Is that right, Jakub Skoczen? |
| Comment by Cate Boerema (Inactive) [ 03/May/19 ] |
|
Actually, Marc Johnson says this might be doable on the front end, in which case we could do it on Core: Functional. Tagging Michal Kuklis for his thoughts on whether this could be done. I was actually thinking it might make sense to have this be a set available for all tenants and all environments. We could call it "super user" or something and have all new permissions added to this set when created. I think this would be useful to many and could be ignored by tenants that don't want to make use of it. Thoughts, Ann-Marie Breaux? |
| Comment by Ann-Marie Breaux (Inactive) [ 03/May/19 ] |
|
Fine by me Cate Boerema - so long as I have it for the testing environments, I'm fine if you give it to everyone else too |
| Comment by Ann-Marie Breaux (Inactive) [ 22/May/19 ] |
|
Cate Boerema Marc Johnson Any chance this could get into a sprint sooner rather than later? |
| Comment by Cate Boerema (Inactive) [ 22/May/19 ] |
|
Ann-Marie Breaux Marc and I discussed this and he thought it might actually be quite involved. But he said we should ask the frontend guys what they thought. I'll do that in an upcoming grooming. |
| Comment by Marc Johnson [ 22/May/19 ] |
|
The more I think about this, the more challenging I think this is to do in a nice way. RequirementsCate Boerema Ann-Marie Breaux I'd like to check my understanding. In order to be able to easily create an administrative user, it would be useful to have a single permission set which includes the permissions for all of the modules active for that tenant Does the above reflect what you want? Is this primarily for testing, or is it something that operations folks might want in production? DesignThe all permission set will vary depending upon the enabled/activated modules for a tenant. I think that means there isn't a sensible place to define this set in the UI or backend modules, as they don't have this information. OptionsCreate the set as part of creating an environmentInstead of assigning all of the regular permission sets directly to diku_admin. Generate an all permission set whilst the environment is being built, based upon the included modules Considerations
Create the set with mod-permissionsI believe there is a hook that creates permissions / permission sets within mod-permissions when a module is activated/enabled for a tenant. Mod-permissions could be changed to also add these new permissions automatically to a pre-defined all set, which could be granted to any user, including diku_admin Is there also a hook for deactivation of a module? Is this even viable? Considerations
ThoughtsAdam Dickmeiss Kurt Nordstrom Zak Burke Michal Kuklis Jakub Skoczen Wayne Schneider John Malconian Ian Hardy Thoughts? Other options? |
| Comment by Cate Boerema (Inactive) [ 22/May/19 ] |
|
Oh wow - this is sucking up more time than I had expected it to. Ann-Marie Breaux, we have another feature in the backlog that would make it much easier to assign permissions (directly to users and also to permission sets) and it has an option to select all. Maybe we should just forget about this bootstrap permission set (which seems quite complicated) and wait for that feature:
Mockup: https://drive.google.com/file/d/1-indHc4g4zqXOUG9vIqjgiEHylzfKQHK/view?usp=sharing |
| Comment by Zak Burke [ 22/May/19 ] |
|
Implemented by adding an "Add all permissions" button to the UI in the users > details > edit > add permissions and settings > users > permissions set pages. This makes it really easy to directly add all permissions to a user, or to create a permission set with all permissions. |
| Comment by Marc Johnson [ 23/May/19 ] |
|
Zak Burke Thank you for coming up with an easy alternative. Trying it out, it appears that operation adds the visible (and not mutable?) permissions / sets to the set or user. Have I understood that correctly? Those sets may not include all of the permissions in the system, or be equivalent to what is granted to diku_admin. I don't know if that is important for this purpose. |
| Comment by Zak Burke [ 23/May/19 ] |
|
Marc Johnson, yes, you have understood correctly. The ticket description notes that creating a high-power user means "I either have to create a permission set on-the-fly encompassing all permissions, or I have to assign every permission one-by-one to a new user." I took this to mean that we wanted an easy way to add all visible permissions to a user or permission set because the current manual process is cumbersome. This is what the "Add all permissions" button does. Ann-Marie Breaux, please let me know if I have misunderstood the request. |
| Comment by Marc Johnson [ 23/May/19 ] |
|
Zak Burke good question, thank you for clarifying. I interpreted all permissions as every permission for that tenant, or equivalent to diku_admin. That is indeed different to create a permission set on-the-fly encompassing all permissions, or I have to assign every permission one-by-one to a new user |
| Comment by Cate Boerema (Inactive) [ 24/May/19 ] |
|
Hi Zak Burke I see this is In review. Did you mark it In review because you implemented the "Add all permissions" button we discussed via Slack as an easy way to solve this problem? Just want to make sure I know what I am testing here (and I should probably adjust the story description to reflect what we did). BTW, I did test the "add all permissions" button and it's SUCH a time-saver. However, it does seem to miss a few permissions. |
| Comment by Zak Burke [ 24/May/19 ] |
|
Yes, I put it in review after adding the "Add all permissions" button. I will investigate why it is missing some things. That's ... odd. The button's action is to get the list of available permissions – the same one that is presented when you click the "Add permissions" menu – and add them one-by-one. That's an obvious bug so if you want to move it back to "In progress" that's fine. |
| Comment by Marc Johnson [ 24/May/19 ] |
|
When you say However, it does seem to miss a few permissions do you mean that not all of the permissions listed in the UI are added? In the sense that it isn't equivalent to adding them one by one. Or that when they are all added, the user doesn't have all of the permissions needed to perform activities? |
| Comment by Cate Boerema (Inactive) [ 27/May/19 ] |
|
Marc Johnson the former, Take a look at the screenshot above. When you click "add all permissions" it adds a ton of permissions, but if you scroll to the bottom of the list of permissions and click the "Add permission" button, you'll see there are still 4 permissions left in the menu which means they weren't added. In addition to not adding some of the permissions that are availble to be added manually, it is adding some other permissions that aren't available to add manually (see
|
| Comment by Ann-Marie Breaux (Inactive) [ 29/May/19 ] |
|
Hi all - sorry not to have been able to weigh in sooner. Thank you very much for working on this. I was originally thinking the same as diku_admin, but it's also to have a feel for what "all visible permissions" does when they are added, so that's totally fine too. Anything to keep from clicking hundreds of permissions one by one when I just want to create a new user and get going. Thank you Marc Johnson Zak Burke and Cate Boerema for moving this forward. One question - since it's an "add all permission" button, that means that if 3 new permissions are added to FOLIO today by a new app, they would be collected and added to a user when I create a new user and click the button, but those 3 would not be added to an existing user that I created yesterday unless I went back and updated that user. Is that correct? |
| Comment by Zak Burke [ 29/May/19 ] |
|
Ann-Marie Breaux, this was implemented as "add all currently available permissions" so you are correct that if you use the button, then install a new app with new permissions, they would not be automatically applied to that user. It is possible to use permission sets as roles to mitigate this problem slightly, i.e.. to assign permissions only to roles not to users, and then to assign roles to users. For example, create a permission set/role "All The Things!" that contains all currently-available permissions, add "All The Things!" to a user, install a new module with new permissions, add those permissions to "All The Things!" and they will be assigned to any users who have "All The Things!". |
| Comment by Zak Burke [ 29/May/19 ] |
|
Cate Boerema said,
I can't duplicate this; all permissions are always added for me and clicking the "Add permission" button shows an empty menu. Not sure how to proceed :/ |
| Comment by Cate Boerema (Inactive) [ 29/May/19 ] |
|
Oh, I guess you have to save the set and then edit it to see the permissions leftover. So, the steps are:
Expected: There should be no permissions in the menu, as they come out of the menu when added Actual: There are a bunch of permissions in the menu |
| Comment by Zak Burke [ 30/May/19 ] |
|
@cate, You're right; I see that behavior after a save too. |
| Comment by Cate Boerema (Inactive) [ 01/Jul/19 ] |
|
I'm not sure why this is blocked. I just unblocked it |
| Comment by Zak Burke [ 15/Jul/19 ] |
|
I made some quick progress on this, but haven't been able to get it to work as intended: permission sets consistently do not include all the expected permissions, and those which are added are inconsistent. I'm not sure of the best approach here. It's almost tempting to close this as "Done" and file a new bug, but that feels really icky. I could revert the change entirely, but I think that even this buggy implementation is a net-timesaver. But dragging this in-progress ticket along from sprint to sprint while I get sidetracked by higher-priority issues also feels wrong. Cate Boerema, do you have a preferred course of action? |
| Comment by Zak Burke [ 26/Jul/19 ] |
|
|
| Comment by Ann-Marie Breaux (Inactive) [ 30/Jul/19 ] |
|
Zak Burke Marc Johnson Michal Kuklis Lovely - and soooo helpful! Thanks very much for putting this in. And it's also wayyy faster to add all permissions and then x out the ones that you DON'T want to give the user than to select a bunch of permissions one by one... THANK YOU!! |
| Comment by Ann-Marie Breaux (Inactive) [ 30/Jul/19 ] |
|
Zak Burke Marc Johnson Michal Kuklis Lovely - and soooo helpful! Thanks very much for putting this in. And it's also wayyy faster to add all permissions and then x out the ones that you DON'T want to give the user than to select a bunch of permissions one by one... THANK YOU!! |