Details
-
Bug
-
Status: Closed (View Workflow)
-
P2
-
Resolution: Done
-
None
-
-
Prokopovych - Sprint 117, Prokopovych - Sprint 118
-
3
-
Prokopovych
-
R1 2021 Hot Fix #3
-
Yes
-
Need to create Test Rail test case to cover this.
-
Cornell, MO State
Description
Update: Approved as R1 2021 Hot Fix #2 at Capacity Planning Team meeting on May 17, 2021. Need to create Test Rail test case to cover this.
Overview:
When retrieving a patron's account including full details of fines/fees (i.e., /patron/account?includeCharges=true), the accrualDate property of each fine reflects the date and time that the retrieval was done, not the actual date the fine was charged.
Steps to Reproduce:
- Log into folio-snapshot as diku_admin (or another user with sufficient permissions to assign fees/fines)
- Go to the Users app and choose any active user
- In the Actions menu, choose 'Create fee/fine'
- Enter any fee/fine owner, type, and amount.
- Add an item barcode to link the fee to an item (to avoid the bug in
EDGPATRON-42) - Click Charge only to create the new fine.
- Using Postman, curl, or your REST client of choice, attempt to retrieve the patron record with includeCharges set – i.e., GET /patron/account/<user ID>?includeCharges=true.
Expected Results: The response body includes a charges object with an array of fees/fines. Each fine has an accrualDate property containing the date and time the fee was charged to the user.
Actual Results: The accrualDate of each item shows the date and time the request was made and is the same for each item in charges.
Interested parties: Cornell
TestRail: Results
Attachments
Issue Links
- clones
-
MODPATRON-59 Account lookup fails if patron has fees/fines without item info
-
- Closed
-
- relates to
-
MODPATRON-59 Account lookup fails if patron has fees/fines without item info
-
- Closed
-
-
MODPATRON-65 Release mod-patron 4.4.1
-
- Closed
-
- mentioned in
-
Page Loading...