Loans (UXPROD-788)

[UXPROD-3157] Check in - add permission control for backdating check ins Created: 01/Jul/21  Updated: 09/Oct/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Loans

Type: New Feature Priority: TBD
Reporter: Erin Nettifee Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: circ_po_small
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
is cloned by UXPROD-3656 Check in - add permission control for... Open
is cloned by UXPROD-3158 Users App and Loans - New/Expanded P... Draft
Defines
is defined by UICHKIN-173 Permissions: backdate check ins Open
Relates
relates to UXPROD-1985 Loans: Permissions (Action-based) Closed
Epic Link: Loans
Development Team: Vega
PO Rank: 0
Rank: Cornell (Full Sum 2021): R3
Rank: Duke (Full Sum 2021): R2
Rank: Mainz (Full TBD): R4
Rank: MTSU: R4

 Description   

Current situation or problem

FOLIO provides some loans permissions (view loans, renew loans, change due date, check out, overrides, etc.) based on existing endpoints. There are two needed permissions for loans / checkin that do not have associated endpoints:

  • Backdate check ins (as opposed to the current check in permission, which allows all users with that permission to backdate check ins)
  • check in claimed returned items (as opposed to the current check in permission, which allows all users with that permission to check in claimed returned items)

Early on, there was a project decision that we needed to define a project-wide approach to action based permissions. However, that did not happen, and a further decision was made that individual features should be prioritized and proceed based on their app's individual needs. See the conversation on https://folio-org.atlassian.net/browse/UXPROD-1828

This feature encompasses the first need - a permission control for backdating checkins.

In scope

  • Creation of a permission that controls the ability to click on the "Date returned" and "Time returned" fields in the check-in app
  • Creation of a permission that controls the ability to backdate a loan through an API call.

Out of scope{}

Use case(s)

  • A library closes on Friday nights, and opens on Saturday morning. They want staff who return books on Saturday morning to backdate the returns to Friday evening to avoid inadvertent fines, but they don't want staff who don't work the Saturday evening shift to be able to do so.

Proposed solution/stories

  • UI functionality in the Check in app: UICHKIN-173 Open
  • Back-end functionality: TBD

Links to additional info

  • There is no separate API for backdating functions. What happens is that check-in-by-barcode takes a required field of "checkInDate." If you backdate the check in, you simply pass in a check-in date in the past, which check-in-by-barcode will accept.

Questions

  • It's unclear what approach would work best for accommodating this permission in the back-end.
    • It's possible that you could say that check-in-by-barcode always records the current date/time as check-in, and then add an API call to adjust the check-in time, and only allow users with specific permissions to use that API. The issue will be scenarios where a FOLIO user has permission to back date a loan, and returns a loan, and in between the loan being returned and the loan being backdated, a fine is charged to the patron that should not have been charged.
    • Perhaps a second API is built that does check-in but only allows current date/time for check in (check-in-by-barcode-current-datetime) and that becomes the default API for the check in app. Everyone who has access to the check in app can use that API. Then, if you have the new permission that allows backdating, you can also use check-in-by-barcode, and the UI is smart enough to know that if you have that permission, and you edit the fields in the Check in app to select a date in the past, FOLIO knows to use a different API to check the item in...


 Comments   
Comment by Thomas Trutt [ 25/Jul/22 ]

Id would suggest adding a separate key for backdating on the check-in-by-barcode API. Re: is you could record the actual check-in date/time in the circ log and use the backdated entry for the circ record. This information was helpful in voyager when we had student employees abuse the backdate function, having both pieces of information available. 

Comment by Erin Weller [ 28/Sep/23 ]

At training, we are telling our students and staff not to back date while checking in. However, we are seeing this misused a lot (staff backdating to avoid late fees). While, we can retrain/discipline staff, it would be wonderful to just have a permission strictly for back dating. The select staff who need it can have it, and everyone else just won't have the option to backdate. Creating a UI solution would be just fine. 

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