2024-03-25 Resource Access Meeting Notes - Reminder Fees Update + Override non-requester checkout

He first wraps up shortly the features which were publshed with Poppy release, which were presented in RA SIG in November last year (2023-11-13 Resource Access Meeting Notes).

With Quesnelia the printing of reminders will be developed as well as some fine tuning on the alreadys exitsting basic functionalities. First we have a look at the new module mod-batch-print, already approved by tecgnical and product council, which is responsible to gather the print reminders which are created during the reminder run in the night and makes them available in a file for staff to print out in the morning. This files can be accessed in the users app, where a separate action (View patron notice print jobs) can be found in the action menu. This action opens a list of files separated and ordered by date which contain the print reminders, so these files can be downloaded, printed out and deleted (in case the needed permissions are in use). Libraries, which would not want to use that functionality at all, just skip those permissions (Users: View and remove patron notice print jobs, Users: View patron notice print jobs) and the action will not be visible.

Closed days: in the hebis legacy systems the reminder run is a process which runs at night and checks every loan if it meets the criteria to send/charge a reminder, like a due date in the past. Now we have a different logic: the reminder date is already calculated at checkout making the reminder due according to the reminder fee policy in place.

There is the default option to not send any reminders at all on closed days. The option „create on closed days“ in the reminder fee policy has an impact in special cases, such as short term loans or loans (with a loan period of hours. Generally the impact depends on the loan policy setting 'due date management on closed days'. If the due date could be a closed day , then this option will be relevant if the reminder should be due immediately the next open day (set to yes). If it’s set to „no“ this would give an extra day and the reminder would be sent out two days after due date (because it would not be created on that closed day but the first open day).

This could also be used for closed days on short notice, to prevent reminders e.g. when there were issues with the discovery layer and patrons were not able to renew items.

The option to block renewals of items with reminders was developed as well. The FOLIO default is to allow renewal of all checked out items. In hebis this is regulated differently among the libaries, some allow renewal, some block renewals of items with reminders. If this option is set to „no“, an error message is shown up at the attempt to renew.

Because pf the difference in the scheduling of reminders mentioned above, the rescheduling of an reminder because of a due date change was needed to take into account as well. This may happen because of a renewal, a recall or a manual due date change. Then the reminder needs to be rescheduled as well.

Florian then shows the access to the print jobs via users app in the development environment. Unfortunately there isn't much to show of the other new functionalities, because of the mainly overnight processes in place.

Q: Where are the templates for the reminders? A: These are the in the same place as for the regular patron notice templates. A template set up there can be used in the reminder fee policy. Florian also shows a template, where the option „print only“ can be selected for print jobs. This makes the subject dissapear, because thats not needed for a letter.

Q: Are the reminder notices used in the reminder fee policy connected to t notice policy A: No, the reminder notices are independent from the notice policy. The trigger always is the creation of a reminder, regardless if email or print.

Laurence asks an example about the closed days and about closed days in between/due date, if they count – they don’t. As already mentioned, this is an option for special circumstances, but can be used for libraries to schedule their reminders, even if they are open 24/7 or have a permanent option to return items.

Q: The print option is seen in the overdue policy and in the notice template – does it match? A: In the reminder fee policy all templates are offered regardless of chosen notice method. So it needs to be taken care, that here the method and the templates are matching.

Q: Are notices required? A: So far, yes.

Q: The block templates are greyed out. Are they developed now? A: No, unfortunately there wasn't enough time to develop that and since there are workarounds for us with the automated patron blocks, we downgraded this in terms of priority. All features and requirements left or possible future enhancements are collected in this Jira: UXPROD-4003 - Getting issue details... STATUS . This has been in discussion for requrement before the development started. Now it might need new discussions with RA SIG to outline requirements for a further development.

Q: Is it possible to charge a reminder fee of 0€. A: Yes, thats possible.

Lisa notes that UB Leipzig will need the option to charge reminder fees without sending out notices and to block patrons on a certain reminder level. Unfortunately these features could not be included in the hebis development due to lack of time. But they are not blocked in any way and can be added in future.

Q: If an item with reminder is renewed, will the reminder fee remain? A: Yes, the fee will still be there and in case the item would be overdue again, the reminder levels restart and the fee will be added to the already existing fee.

Second topic is override non-requester checkout. This is about overriding, in case an item has a request by another person. This requires for example new user permissions which authorizes the override, and the extension of the override window by adding a button „view request details“ and a button „override“. Users which are authorized, can then view the request details. An override would lead to checkout the item to a patron not the original requestor. This should bump back the request status then, a page would become a hold and the cancelled request should be the first instance in the request qeue.

This functionality is planned for Sunflower Release.

Q: Could there be another button for „Override & Cancel“? For example when a request needs to be cancelled completely, because this item is for course reservers (like when course reserves are checked out items).

David says, that it needs to be kept in mind, what that cancelling/override of requests does to the statistics.

Concerning TLR, here when an request in item level was cancelled, it needs to be returned to be a TLR again.

Cancelling all requests for an item is out of scope of this developement. This is just about overriding (maybe cancelling) the outstanding request which blocks checkout at this time.

The default of this override functionality could be for all kinds of requests, but there might be institutions that would like to setup rules (e.g. excluding recalls).

Related to this: how can notices to the patron be handeled? Should it be automated or manual sent by staff? There are many different scenarios and use cases regarding the notices, but David mentiones that the patron who requested in first place might already have received a pick-up notice, which would cause confusion at pick-up when the item is borrowed to another patron instead. Communication would be difficult here.

Olga asks about items already on hold shelf. Depending on the circumstances, there also might be requests overridden/cancelled when the item already is on hold shelf, but also here are many different use cases to be considered.

This functionality should be selectable by choice, not all institutions would might want to use it.