[FOLIO-1100] Move Due Date Logic from UICHKOUT-25 and UICHKOUT-66 to the Server Created: 02/Mar/18  Updated: 12/Nov/18  Resolved: 09/Jul/18

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Cate Boerema (Inactive) Assignee: Marc Johnson
Resolution: Done Votes: 0
Labels: core, sprint33, sprint34, sprint35, sprint36, sprint37, sprint38, sprint39, sprint40, sprint41, sprint42
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UICHKOUT-407 Truncate Loan Period According to Fix... Closed
is blocked by CIRC-74 Create a loan using item and patron b... Closed
Cloners
is cloned by FOLIO-1101 Move Renewal Due Date Logic to the Se... Closed
Relates
relates to UICHKOUT-407 Truncate Loan Period According to Fix... Closed
relates to CIRC-110 What time should a daily, weekly or m... Closed
relates to UICIRC-55 Loan Policy: Remove "Indefinite" Loan... Closed
relates to UICHKOUT-428 Multi-Reason Checkout Error Popup for... Draft
relates to UICHKOUT-25 Get Rolling Loan Period from Loan Policy Closed
relates to UICHKOUT-66 Get Fixed Loan Period from Loan Policy Closed
relates to UXPROD-273 Loan Policy: Impact on loans part 1 (... Closed
Sprint:
Tester Assignee: Adam Shire

 Description   

As I understand it, we have implemented the logic for calculating due date based on loan policy in the UI. We need to move that to the back end so that the logic can be used in other systems such as self check machines which will integrate with FOLIO via API.

See UICHKOUT-25 Closed and UICHKOUT-66 Closed for details on the logic.



 Comments   
Comment by Cate Boerema (Inactive) [ 02/Mar/18 ]

Jakub Skoczen, I created this based on our conversation but I didn't know which project it should go in. I think it's a pretty high priority.

Comment by Michal Kuklis [ 05/Mar/18 ]

Hey everyone here are the current API calls we use in order to perform a checkout:

No. Name API endpoint Description
1. fetchItemByBarcode GET inventory/items?query=(barcode==BARCODE) fetch item by barcode
2. checkForLoan GET circulation/loans?query=(itemId==ITEM_ID and status.name<>"Closed") check if loan already exists for the given item id
3. fetchLoanPolicyId GET circulation/loan-rules/apply fetch loan policy id by: shelving_location_id, item_type_id, loan_type_id, patron_type_id
4. fetchLoanPolicy GET loan-policy-storage/loan-policies?query=(id==LOAN_POLICY_ID) fetch loan policy by loan policy id
5. fetchFixedDueDateSchedules GET fixed-due-date-schedule-storage/fixed-due-date-schedules?query=(id==FIXED_DUE_DATE_SCHEDULE_ID) fetch fixed due date schedule for given schedule id
6. validateFixedDueSchedule No call Validate fixedDueDateSchedule on the client
7. postLoan POST circulation/loans creates new loan
Comment by Marc Johnson [ 29/Mar/18 ]

I've tried to consolidate the list of validation checks that we want the backend to perform upon checkout, to try to reflect my current understanding of the scope for CIRC-74 Closed .

Check Exists in Front End Exists in Backend Notes
Item exists No Yes  
Holding exists No Yes otherwise it is not possible to lookup loan rules
Item is not already checked out No Yes  
No other checked out loan Yes No  
Proxy relationship needs to be valid Yes Yes only if proxy is involved
User must be requesting user No Yes if there is an outstanding fulfillable request for item
Loan must have a status of Open or Closed No Yes  
User needs to be active and not expired No No  
Proxy needs to be active and not expired No No only if proxy is involved

The only logic that I think we are moving is the due date calculation for check-out (and renewal, in FOLIO-1101 Closed ), is that correct?

And this is either based upon the fixed due date schedule ( UICHKOUT-66 Closed ) or the loan period ( UICHKOUT-25 Closed )?

Does that cover all of the existing checks that we want to consolidate, as part of CIRC-74 Closed ?

Comment by Marc Johnson [ 11/Apr/18 ]

Cate Boerema Jakub Skoczen

At the moment the UI applies defaults if the loans policy cannot be fully understood (see below for the defaults).

If the loan policy is not either rolling or fixed, the due date will be 14 days in the future.

If there is no duration for a rolling period, the duration is set to 10 (for any interval).

Michal Kuklis This is how I'm interpreting https://github.com/folio-org/ui-checkout/blob/master/loanUtil.js please let me know if this does not match your understanding.

Comment by Cate Boerema (Inactive) [ 11/Apr/18 ]

If the loan policy is not either rolling or fixed, the due date will be 14 days in the future.

We have decided to remove the "indefinite" loan profile for now (see FOLIO-1178 Closed ). I will write up a user story for that so we no longer have to worry about this scenario.

If there is no duration for a rolling period, the duration is set to 10 (for any interval).

According to UIS-13 and the loan policy metadata spreadsheet, loan duration is required for rolling loans. Can someone file a bug to get that fixed?

Comment by Marc Johnson [ 11/Apr/18 ]

Cate Boerema Thanks for the quick answer. Apologies, I may have caused some confusion.

I wasn't suggesting there was a bug with loan policies (and I'm not aware of one, I think the code in UI Check out is just being defensive).

Based upon your answers, the expected behaviour (and these scenarios should not occur, due to validation), that if a loans policy cannot be properly understood (e.g. not rolling or fixed, or a rolling period with no interval or unknown duration) then an error should be reported?

Would situations like a duration of zero also cause an error?

Comment by Michal Kuklis [ 11/Apr/18 ]

Marc Johnson that 14 day rule is old (before we had policies in place). Iif we can get rid of the Indefinite loan profile in https://folio-org.atlassian.net/browse/FOLIO-1178 then I think we can assume that loan profile will be always set to either Fixed or Rolling.

Comment by Cate Boerema (Inactive) [ 12/Apr/18 ]

Filed a story to get rid of Indefinite: UICIRC-55 Closed

Comment by Cate Boerema (Inactive) [ 12/Apr/18 ]

Would situations like a duration of zero also cause an error?

Not sure why users would ever want to set up a policy with a loan period of zero, so I think it's a real edge case. I seem to recall there was a technical reason why it was implemented the way it was (where there is a number populated by default instead of a blank field with required validation). Anyway, I don't think this would cause an error, necessarily... Michal Kuklis, what do you think?

Comment by Marc Johnson [ 27/Jun/18 ]

Cate Boerema Jakub Skoczen Can this be closed now, as we have the check out API in place and the UI is using it? And any new policies we want to apply can be represented in separate issues?

Comment by Marc Johnson [ 09/Jul/18 ]

Closing as I believe all of the work needed is complete

Generated at Thu Feb 08 23:10:50 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.