Check in - add permission control for backdating check ins

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://issues.folio.org/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
• 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...