2022-03-16 Meeting notes
- Maura Byrne
- Laurence Mini
- (OLD ACCOUNT) Erin Nettifee
Date
Attendees
- Uschi Klute
- patty.wanninger
- Brooks Travis
- Erin Weller
- Christine Tobias
- Laurence Mini
- mey
- Amelia Sutton
- Karen White
- Matthew Harrington
- Jakub Skoczen
- Magda Zacharska
- Cammie Wyckoff
- Khalilah Gambrell
Goals
- Reminder: UM-SIG is now meeting on the first and third Wednesdays of each month.
- Testing in bugfest uncovered a change in the way permissions could be assigned. See MODPERMS-157 - Getting issue details... STATUS
- Patty will talk about Bugfest, which is currently running.
- At the App-Interaction SIG meeting, a new function was demonstrated - URLs can be automatically be made clickable. The same may be done for email addresses. Does the SIG have an opinion on that fact?
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 5 min | Note-taker | Laurence M. | |
| 25 min | Bulk Edit | Magda Z. | Magda presented on current progress and future plans for the Bulk Edit feature for Users. See Slides Currently users can identify records for bulk editing via identifiers or simple queries. Fields in the User record can be changed, but not linked records such as permissions or fees/fines. To Bulk Edit the procedure is to: 1) select identifier; 2) pick file; 3) the screen shows preview of matching records and records with errors (like an identifier that doesn’t match anything); 4) Download the matching records; 5) Make desired changes; 6) Start Bulk Edit and choose file changed in step 5; 7) notification that file was uploaded correctly; 8) get notification the database will be changed; 9) preview of changes and errors. Can download the changed records and the errors. Feedback has been received that users would like the process to be made easier via an in-app editor, so you don’t have to be working in a CSV file. Editing CSV file is acceptable as a short-term stopgap solution Magda showed a mockup of an in-app way to select fields you want to change. CSV and in-app approach should be ready for Morning Glory |
| 35 min | Permissions Assignment | Jakub S. | Related tickets include: BF-223, MODPERMS-157, MODPERMS-160, UIU-2541, UIU-2542, UIU-2549. See also UXPROD-3614 - Getting issue details... STATUS created by Erin Nettifee after the meeting. Jakub presented on proposals to make the assigning of permissions more secure and granular. Permissions assignment in older FOLIO releases was an all-or-nothing affair – if you could assign permissions then you could assign any permissions, including ones you didn’t have. It was realized this created serious security problem because users could give themselves or others Copy permissions which allow installing or stopping modules and allow a user to take over the system. The fix initially used for Lotus bugfest caused problems however. It was too restrictive in preventing the assignment of permissions (only allowing admin users to assign permissions), so this was changed to allow bugfest testers to do their work. The ability to assign Copy permissions has been fixed, but more granular control over permissions assignment may be desirable for future FOLIO releases (Morning Glory and later). Permissions control is complicated because there are 2 different modules involved in assigning of permissions, MOD-Permissions and UI-Users. The latter controls visible permissions. The security fix did not take UI-Users into account. Proposed change is that you will need explicit permissions to be able to assign permissions of different kinds -- system-level permissions; immutable permissions (ones fixed by the modules); mutable permissions (permissions that users can define); permissions that the user doesn’t have themselves. For Lotus, proposed change is to improve the migration to include UI-Users. This will make permissions assignment in Lotus look similar to Kiwi, rolling back some of the security features (although still preventing assignment of the system-level permissions) but solving issues of users not being able to do what they need. For later releases, we may want to have more granular control of what permissions can be assigned. Erin N. asked if there are use cases where you might want someone to be able to assign permissions, but only certain permission sets (like permissions for student workers, etc.) or is it OK that if someone can assign permissions then they can assign any permissions? Proposed is to have 4 layers of permissions assignment: Copy (or system-level) permissions; Immutable permissions; Mutable permissions; or (Default) can only assign permissions that the user already has. It was discussed that we would like to change the names ‘mutable’ and immutable’. Jakub is fine with that, as long as the tickets are updated to reflect terminology so as to keep things from confusement. Erin will consult with Patty, prepare slides and consult with the RA and MM SIGs. |