"refunds.collection.get" permission is required when trying to view fees/fines for a user through the user UI
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
relates to
Checklist
hideTestRail: Results
Activity
Holly Mistlebauer April 23, 2021 at 4:16 PM
This permission problem will be fixed as part of https://folio-org.atlassian.net/browse/UXPROD-2046#icft=UXPROD-2046.
Holly Mistlebauer April 23, 2021 at 4:14 PM
@Darcy Branchini: Settings (Users): Can create, edit and remove refunds is one of the permissions I am getting rid of. All settings for fees/fines are to have a shared permission. I thought this one was created, but not in use. I am going to be verifying every fee/fine permission and how it is used. I have a real mess to clean up. Yes, I agree with your recommendation.
Darcy Branchini April 20, 2021 at 4:51 PMEdited
@Holly Mistlebauer, first the permission name is deceiving, the permission titled, "Settings (Users): Can create, edit and remove refunds" refers to fee/fine refund reasons, not to the refund action on a fee/fine. When a user's fees/fines (aka f/f history page) are viewed, the information for processing a refund (and/or other actions), including refund reasons, is collected when that page is loaded (as opposed to when the refund modal is loaded). This requires the ability to view the refund reasons. As a result, the permission titled, "Settings (Users): Can create, edit and remove refunds," which includes the ability to view a refund reason, is required to view refund reasons and load that page. There isn't a separate permission to simply view. It's my suggestion that users are given this permission as a temporary fix for Iris since https://folio-org.atlassian.net/browse/UXPROD-2046#icft=UXPROD-2046 (cleanup of fee/fine permissions) is slated for R2.
If you agree, let's close this issue as Won't Do.
Kyle Felker April 19, 2021 at 12:49 PM
@Alexander Kurash
The issue here as I understand it, is that you seem to need the permission noted above just to view user records through the user UI, which is calling the refunds endpoint when you load user data. I'm assuming it's doing so as part of the machinery that requests account data to be displayed under the user "fees/fines" accordion. So either the UI is erroneously calling that endpoint, or it actually does need that data when displaying a user record, in which case get permissions on refunds data are necessary to view patron records, and need to be part of the view patron record permission set.
Alexander Kurash April 19, 2021 at 8:55 AM
@Kyle Felker There is a specific user permission for refunds functionality: "Settings (Users): Can create, edit and remove refunds"
Please see https://folio-org.atlassian.net/browse/CIRC-1117 for more info.
Following TCs was executed to indicate a problem:
Precondition:
Logged in as user with all permissions
Steps:
1. Go to Settings > Users > Permission sets
2. Click New to add a new permission set.
Expected Result: You are sent to the Create permission set view
3. Fill in the fields Title ("Circulation") and Description
4. Add permissions that will let the user
Access the following apps:
Check in
Check out
Users
Requests
Inventory
Perform the following actions:
Check in: all actions
Check out: all actions
Users: search, filter and view; create and edit users;
but NOT add/edit/remove the following to/from users: Permissions, Proxies, Service points
Requests: all actions
Inventory: search, filter and view records
Administer the following settings
None
5. Click Create permission set
Expected Result: A new permission set is created. You are sent back to the three pane Settings view. The new permission set is listed among existing permission sets.
6. Go to Users and create a new user, and assign it permission set Circulation.
Assign a Service point and Service point preference to this user, to enable circulation activities.
7. Log in as the user to which you assigned the permission set Circulation
Expected Result: You are logged into FOLIO. Looking at the app menu, you see the following apps, and no others:
Check in
Check out
Users
Requests
Inventory
8.
9. (Failed) Perform various tasks (see test cases for apps [...]) to verify that the user is able to
Access the following apps:
Check in
Check out
Users
Requests
Inventory
Perform the following actions:
Check in: all actions
Check out: all actions
Users: search, filter and view; create and edit users; but NOT add/edit/remove the following to/from users: Permissions, Proxies, Service points
Requests: all actions
Inventory: search, filter and view records
Administer the following settings
None
Expected Result
The user is able to
Access the following apps:
Check in
Check out
Users
Requests
Inventory
Perform the following actions:
Check in: all actions
Check out: all actions
Users: search, filter and view; create and edit users;
but NOT add/edit/remove the following to/from users: Permissions, Proxies, Service points
Requests: all actions
Inventory: search, filter and view records
Administer the following settings
None
Actual Result
1. This portion passed. User is able to see and access all the apps listed.
2.a. Several portions of the add user crashed but uncertain if this is a user app bug or permission issue (think user app bug?) Crashed when selecting: Eissorten, Zweigstelle fields,
Display note as a pop-up and Major. Set a Block and received ERROR: Access requires permission: manual-block-templates.collection.get
2.b. Looking at a User account with Fine/Fee, click on the link and ERROR (Access requires permissions: refund.collection.get
Then windows opens and I see Open fees/fines for that user. I can then click on Closed, All and Export with no issues. And I can create a new fine/fee. When I click away to Check In app I get a message that Something went wrong with a button to Return to Check in landing page and end up at Welcome screen. Back in User screen looking at Fines/Fees, click on any of the links and I get the access error for each of them. Click on OK, Error window closes and the screen opens and I can work in there.
2.c Check out works fine.
2.d. Check in works fine unless there is a fine/fee then the ERROR: Access requires permission: lost-items-fees-policies.collection.get. Click on OK in error window and I can
proceed without issue. Item returned and in transit to shelving location.
2.e. Requests work fine.
10. (Failed) For reproducibility and future reference, add a comment to the test result specifying which permissions you included in the permission set.
Actual Result
Check in: All permissions
Check out: All permissions
Inventory: View instance records being suppressed for staff
Inventory: View instances, holdings, and items
Requests: All permissions
Users: Can create new user
Users: Can create, edit and remove fees/fines
Users: Can create, edit and remove patron blocks
Users: Can edit user profile
Users: Can view permissions assigned to users
Users: Can view proxies assigned to users
Users: Can view service points assigned to users
Users: Can view user profile
Users: Create/reset password
Users: User loans anonymize
Users: User loans change due date
Users: User loans claim returned
Users: User loans declare lost
Users: User loans mark claimed returned missing
Users: User loans renew
Users: User loans renew through override
Users: User loans view
Users: User loans view, edit, renew (all)
Users: View requests
For full circulation functionality may need to add fine/fee permissions as well.
An investigation was carried out by @Kyle Felker:
When trying to view fees/fines for a user through the user UI, a modal indicating a permission "refunds.collection.get" is needed. As with 2, I am not sure this issue is even located in mod-circulation-the url that's producing it (https://core-functional-okapi.ci.folio.org/refunds) does not look like any endpoint defined in it's descriptor. Refunds are not implemented by mod-circulation, rather by mod-feesfines . If this endpoint is requested directly from the front-end it is likely that a front-end module is missing that permission
Please note that these problems are only seen when you try to perform the action with a user with the specific permissions set in the description. If you test with the admin user, you won’t see the error, likely because the permission is included in some other permission set the admin user has