[UXPROD-4344] Need new permission(s) to view all Users settings in UI Created: 27/Jan/23  Updated: 30/Nov/23  Resolved: 10/Aug/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Poppy (R2 2023)

Type: New Feature Priority: P3
Reporter: Samuel Lemon Assignee: Amelia Sutton
Resolution: Done Votes: 0
Labels: permissions, support, ui-only, usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: File bandicam 2023-06-05 03-15-20-544.mp4     PNG File image-2023-05-17-12-23-18-089.png     GIF File image-2023-05-24-09-01-22-377.png     PNG File image-2023-05-26-14-41-21-481.png     PNG File image-2023-05-26-14-41-42-480.png     PNG File image-2023-05-26-14-48-30-083.png     PNG File screenshot-1.png     PNG File screenshot-2.png    
Issue links:
Defines
is defined by STSMACOM-766 User Settings Permission sets: Disabl... Closed
is defined by UIU-2902 User settings > General section: Disa... Closed
is defined by UIU-2903 User settings > Manual Charges: Disab... Closed
is defined by UIU-2904 User settings > Fee/fine section: Dis... Closed
is defined by UIU-2905 User settings > Comment required: Dis... Closed
is defined by UIU-2906 Cleanup User Settings permissions – P... Closed
is defined by UIU-2907 Cleanup User Settings permissions – P... Closed
is defined by UIU-2908 Wrong displaying name for Settings (U... Closed
is defined by UIU-2910 User settings > Transfer Accounts: Di... Closed
is defined by UIU-2911 User settings > Conditions: Disable e... Closed
is defined by UIU-2912 User settings > Limits: Disable editi... Closed
is defined by UIU-2913 User settings > Templates: Disable ed... Closed
is defined by UIU-2919 Clean up setting.transfertypes permis... Closed
Relates
relates to UIU-2892 Roll back UIU-2784 Closed
relates to UIPBEX-46 Create view version of "ui-plugin-bu... Closed
relates to UIU-2884 Include Transfer criteria in default ... Closed
Release: Poppy (R2 2023)
Front End Estimate: XL < 15 days
Front End Estimator: Priyanka Terala
Back End Estimate: Out of scope
Development Team: Volaris
PO Rank: 0

 Description   

Current situation or problem:

With the existing permissions, we are unable to make it so a user can view/export data but not edit the Users settings. New permissions are needed to let an user just view Users ant settings and not be able to edit. 

In scope:

  • Need a new “Setting (Users): View all settings” permission to be able to view all the Users settings and not be able to edit the settings
  • Rework configuration forms associated with User settings and disable all UI controls if the new setting is applied.
  • Include Transfer criteria (Bursar configuration) in the default set of permissions to view all Users settings (this need to be re-checked with the PO of Bursar functionality before implementation)

Interested Parties: Sobha Duvvuri  Anya Tim Auger Irina Pokhylets    

Proposed changes (added 06-27-2023 by Erin Nettifee)

Rename and make invisible

  • Rename “Settings (Users): Can view feefines” to “Settings (Users): Can view manual charges” and make invisible
  • Rename “Settings (Users): Can view comments” to “Settings (Users): Can view if comment required” and make invisible
  • Rename “Settings (Users): Can view waives” to “Settings (Users): Can view waive reasons” and make invisible
  • Rename “Settings (Users): Can view payments” to “Settings (Users): Can view payment methods” and make invisible
  • Rename “Settings (Users): Can view refunds” to “Settings (Users): Can view refund reasons” and make invisible
  • Rename “Settings (Users): View departments” to “Settings (Users): Can view departments” and make invisible

Rename

  • Rename “Settings (Users): Can create, edit and remove feefines” to “Settings (Users): Can create, edit and remove manual charges”
  • Rename "Settings (Users): Can create, edit and remove comments" to "Settings (Users): Can edit if comment required”
  • Rename “Settings (Users): Can create, edit and remove waives” to “Settings (Users): Can create, edit and remove waive reasons”
  • Rename "Settings (Users): Can create, edit and remove payments" to "Settings (Users): Can create, edit and remove payment methods”
  • Rename "Settings (Users): Can create, edit and remove feefines” to "Settings (Users): Can create, edit and remove manual charges”
  • Rename "Settings (Users): Can create, edit and remove refunds” to "Settings (Users): Can create, edit and remove refund reasons”
  • Rename “Settings (Users): Create, edit, and view departments” to Settings (Users): Can create, edit, and view departments
  • Rename “Settings (Users): Create, edit, view, and delete departments” to “Settings (Users): Can create, edit, view, and delete departments”

Make invisible

  • Make “Settings (Users): Can view owners” invisible
  • Make “Settings (Users): Can view transfer accounts” invisible
  • Make “Settings (Users): Can view transfer criteria” invisible
  • Make “Settings (Users): Can view patron blocks conditions” invisible
  • Make “Settings (Users): Can view patron blocks limits” invisible
  • Make “Settings (Users): Can view patron blocks templates” invisible

Create new permission(s)

  • Create new permission “Settings (Users): Can view all patron blocks entries” with subpermissions
    • “Settings (Users): Can view patron blocks conditions”
    • “Settings (Users): Can view patron blocks limits”
    • “Settings (Users): Can view patron blocks templates”
  • Create new permission “Settings (Users): Can view general entries” with subpermissions
    • Settings (Users): Can view address types
    • Settings (Users): Can view custom fields
    • Settings (Users): Can view patron groups
    • Settings (Users): Can view permission sets
    • Settings (Users): Can view departments

Keep existing permission

  • Keep existing permission “Settings (Users): Can view feefines-related entries” with subpermissions
    • “Settings (Users): Can view owners”
    • “Settings (Users): Can view manual charges”
    • “Settings (Users): Can view waive reasons”
    • “Settings (Users): Can view if comment required”
    • “Settings (Users): Can view payment methods”
    • “Settings (Users): Can view refund reasons”
    • “Settings (Users): Can view transfer accounts”
    • “Settings (Users): Can view transfer criteria”


 Comments   
Comment by Priyanka Terala [ 17/May/23 ]

Hi Tim Auger Irina Pokhylets 
I see something that needs to be refactored within the scope of this ticket.

Below is my proposal. Could you please confirm if this is fine with you?

 

Left Blue bordered Box - Fee/fine section from Settings > Users

Right grey background box -Permission name and Display Name associated with each setting page.

Summary

Permission name and display name in blue font is that of "Manual charges" setting page. My proposal is to rename them as below -

"ui-users.settings.manual-charges" "Settings (Users): Can create, edit and remove manual charges"

Why?

  1. In order to align with the nomenclature of other settings in this section and maintain consistency.
  2. I see there is another permission set that pertains to the entire fee/fine section and its details are as below -
"ui-users.settings.feefines.all" "Settings (Users): Can create, edit and remove all feefines-related entries"

This will help maintain clean naming conventions too.

This doesn't call for any BE changes. Purely FE. 

cc Gurleen Kaur1 Arghya Mitra Steve Ellis 

 

Comment by Tim Auger [ 18/May/23 ]

Yes, Priyanka Terala and Irina Pokhylets I agree with this approach.

cc: Gurleen Kaur1 Arghya Mitra Steve Ellis 

Comment by Priyanka Terala [ 22/May/23 ]

Thank you for the approval Tim Auger 

Comment by Priyanka Terala [ 24/May/23 ]

 

Nika Mindadze Changes are available on snapshot. Please verify.

Comment by Irina Pokhylets [ 26/May/23 ]

Tim Auger
While working on the ticket, we’ve found one permission for which we would like to ask about the necessity of having it in read-only mode. It’s “Bursar admin” permission and it’s responsible for the “Transfer criteria“ user setting page.

Currently, for administrating the Bursar export configuration the “ui-plugin-bursar-export.bursur-export.all” permission should be assigned to a user and the permission for Bursar configuration view only does not exist.

The questions:

  1. Do we need to implement a new configuration for view only of the Bursar export configuration ("Transfer criteria" page)?
  2. If yes, do we need to include the 'Bursar export configuration view only' in the default set of “Setting (Users): View all settings” permission?

Also, we found that “settings.transfertypes” permission is useless from the code perspective. If this permission is assigned, it doesn’t reflect any changes on UI. For displaying the "Transfer criteria" page is responsible “Bursar admin” permission. So we would like to clean up the code related to it. Do you have objections? 

CC: Priyanka Terala 

Comment by Tim Auger [ 26/May/23 ]

Hi Priyanka Terala . Zero objections. Your points make sense.

  1. Do we need to implement a new configuration for view only of the Bursar export configuration ("Transfer criteria" page)?

>>TA: I would prefer to have it, yes.

  1. If yes, do we need to include the 'Bursar export configuration view only' in the default set of “Setting (Users): View all settings” permission?

>>TA: I think so. Do you have concerns about it? 

Comment by Priyanka Terala [ 29/May/23 ]

Tim Auger 
Thank you for the answers.

Irina Pokhylets 
Now that we have clarifications from Tim, could you please drive them through the tickets?

Thank you

 

cc Gurleen Kaur1 

Comment by Irina Pokhylets [ 01/Jun/23 ]

The stories UIU-2884 Closed and UIPBEX-46 Closed have been created for creating/including Transfer criteria (Bursar configurations) read-only permission in the default set of “Setting (Users): View all settings” permission.

Comment by Nika Mindadze [ 04/Jun/23 ]

Priyanka Terala issues were identified during testing, While trying to edit different settings, we get errors on save buttons, we are unable to edit the settings, however it would be more neat to disable edit buttons and not get errors.  I also attached recording  

Comment by Priyanka Terala [ 05/Jun/23 ]

Hi Nika Mindadze ,
Thank you for your observations. These issues were expected and also discussed with Irina Pokhylets and Gurleen Kaur1 around mid May.
The idea was to create another ticket(s) to address these behaviors as they are actually beyond the scope of this ticket and also need expectations on every form.

Comment by Irina Pokhylets [ 07/Jun/23 ]

The newly added “Setting (Users): View all settings” permission does not allow users to save changes in User settings configuration. But users still can edit configuration forms, and some other controls are available such as delete, add new, etc. If a user changes the configuration and clicks Save, then various errors appear.
For fixing the errors, changes need to be done on each configuration form. User settings contain 16 forms.

Because the work is not complete it can’t be released. Was made a decision to roll back the “Setting (Users): View all settings” permission and return to it when the feature will be prioritized. The preliminary front-end estimation for the feature is XL.

CC: Tim Auger,Gurleen Kaur1, Priyanka Terala, Nika Mindadze

Comment by Erin Nettifee [ 20/Jun/23 ]

Hi all - has this been discussed with the RA SIG? It looks like between Orchid and today 16 new permissions were added, but many of them are just functionally not needed. Like, a library that is managing fines would not grant view permissions to settings one by one - generally someone would have view access to everything, or edit access to everything. The users permissions list is already VERY long and this has just made it longer.

I fully recognize that users permissions need cleanup, but in my opinion this should be rolled back and the work should be approached through a SIG conversation to better understand what is actually needed. The body of this ticket doesn't have enough information to describe what the actual business need is from the library that reported the problem.

Amelia Sutton

Comment by Amelia Sutton [ 21/Jun/23 ]

Irina Pokhylets I agree with Erin Nettifee that adding individual permissions for viewing each section of Users settings is excessive and, in my reading, is out of scope for this feature. From what I understood in our meeting this morning it might require more time than we have remaining for the Poppy release to roll this back. Since we cannot move to release with this feature incomplete, would it be possible to include only the "Settings (Users): View all settings" permission and not the individual "Settings (Users): Can view [some category] settings"? Alternatively could those more granular permissions be made invisible?

I can still create the stories for which controls would need to be disabled to resolve the errors that are currently occurring in each section, but I don't want to create this many new permissions without bringing this issue to the RA and UM SIGs

Comment by Erin Nettifee [ 21/Jun/23 ]

Hi Amelia Sutton - I'm going to look at this and suggest consolidating the permissions that were created as a first step. There's a lot of history here from work that Holly Mistlebauer did that I need to piece through....

Comment by Erin Nettifee [ 22/Jun/23 ]

I have asked the RA SIG for input and Amelia has passed that over to UM SIG for input. I also have a draft proposal for how to fix some of the issues here by condensing permissions. I don't think we will need to do any work that would require significant code rollbacks, but there is a lot of cleanup to do with permission naming and organization.

Comment by Erin Nettifee [ 27/Jun/23 ]

Hi Irina Pokhylets Amelia Sutton et al - the circ POs have reviewed a proposal to clean this up that involves some significant renaming and grouping to create new permissions, but does not involved changing any of the forms / code work that was done, so my hope is that not as arduous to put these changes in place.

I've added the proposed changes to the body of the jira — they are listed by the display name since I pulled the list from the UI, but I can pull the individual permission actual names if you need them.

Comment by Irina Pokhylets [ 12/Jul/23 ]

Hi,
Amelia Sutton 
Could you please answer, should Transfer criteria (Bursar configuration) be included in the default set of view-only Users settings permissions?

Comment by Erin Nettifee [ 12/Jul/23 ]

Irina Pokhylets I want to make sure your team is aware of the work that Bama is doing on the transfer criteria page - https://folio-org.atlassian.net/browse/UXPROD-3903 - I don't know if it's going to make Poppy or not, but it involves some fairly significant changes to the form interface, and I don't want you all to spend a ton of time tweaking the form that's live right now to make it behave for a "view-only" permission.

Comment by Irina Pokhylets [ 12/Jul/23 ]

Erin Nettifee, thanks for your comment. We knew about dependency on one PR ( UIPBEX-46 Closed ) and that Bama team plan to merge those changes for Poppy. But we didn't know about UI reworking.
We had doubts should Bursar configuration be included in the default set of "view-only" permissions and wanted to confirm it, because initially it was implemented as a plugin.
Now I would like to reverse my question , can we exclude the Transfer criteria page from this feature (with the assumption that changes will be covered by Bama team implementation)?
Erin Nettifee,Amelia Sutton

Comment by Erin Nettifee [ 12/Jul/23 ]

Irina Pokhylets a question to help me answer your question I can see from the comments on UIPBEX-46 Closed that Bama has plans to implement a view only permission for the transfer criteria plugin, but I have thought plugins were, like, pop-ups like the modal to search for users. Functionality that's in a setting's third pane could also be a plug-in?

For some additional context, this is a screenshot of Bama's rancher of their WIP on the bursar requirements, so you see what I mean about implementing significant UI changes:

Comment by Amelia Sutton [ 10/Aug/23 ]

I have confirmed both the functionality of the new "Settings (Users): View all settings" permission as well as the changes to visibility and naming for other permissions. Note that I changed a couple of things under Keep existing permissions section. I removed the word 'all' from the permission name as that did not align with the existing permission and was likely a typo. I also struck the “Settings (Users): Can view transfer criteria” permission from the list of included permissions as the creation of that permission was closed as "won't do".

Beyond these two changes that were not related to the functionality I have confirmed this feature in snapshot so I am closing the ticket.

Generated at Fri Feb 09 00:39:11 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.