2022-05-16 Resource Access Meeting Notes
Date
Recordings
Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/
Zoom
https://zoom.us/j/337279319 (pw: folio-lsp)
Attendees
Discussion Items:
| Time | Item | Who | Description | Goals/Info/notes |
|---|---|---|---|---|
| 5min | Administrivia | Note taker: | ||
| 35 Min | Refund process | Holly Mistlebauer | ||
| 20 Min | The pros and cons of logic branching and advanced conditioning in notice and slip tempates | julie.bickle |
I want to present a fews options with their pros and cons: These requests are essentially logic branching.
|
Meeting Notes
Holly gave an explanation on how refunding of fees/fines currently works. See slideshow (note old specification included starting at slide 16). SIG members found the current system under-developed and potentially confusing, especially to student workers staffing the circulation desk. Issues with the current system include: credit amount not showing as negative amount; no way to tell if a fee/fine has been transferred to the bursar or not; no way to cancel a fee/fine as an error if there has been any activity on the fee/fine; two-step process involved in first refunding and then waiving a fee/fine in order to close it. Holly agreed that the current implementation is under-developed; it was a thin-thread solution intended to be temporary but a lack of expressed urgency from institutions has delayed development. Various SIG members pointed to the way OLE and Aleph handle fees/fines refunding as a model for FOLIO to look to. It was agreed that Jana will form a subgroup that will recommend how best to proceed. See also
Provide option to cancel a fee/fine at the time a manual refund is entered, Use fee/fine refund to pay other fees/fines, Notify Bursar (and other transfer accounts) of refunded fees/fines, Allow "No fees/fines shall be refunded if a lost item is returned more than" to be determined by a fixed date.
Holly created placeholder UXPROD-3668 for everything we want to see improved. Please add any ideas in the comments.
Julie discussed enhancement options for patron notices and staff slips. Three types of fields where "computing" could be helpful would be: use preferred name when exists, otherwise use first name (UICIRC-462); Anonymous ID tokens for patron requesters (UXPROD-2435); Having a token for current date, and being able to do current date + e.g. 7 days when printing hold slip (UXPROD-3224). Julie has consulted with the dev team. Two (not mutually exclusive) options are: i) Allowing logic branching in template design, such as exists in Handlebar; ii) Creating hard-coded tokens as needed such as e.g. a "preferred name or first name" token which would insert the preferred name if it had a value, otherwise first name would be inserted.
The advantages of allowing logic branching / calculated values in the template creation UI include greater control, and better capacity to handle future needs. Disadvantage is that creating the template becomes more complex – will the the library staff creating the templates have a harder time? Also this solution would require considerable time to implement.
Advantages of the hard-coded token approach include simpler template creation, and shorter development time (to do an individual token). Disadvantages include risk of a 'token explosion' that becomes unwieldy to use, and less adaptability to solve future needs.
Other useful 'calculated tokens' mentioned were: Total of all fees/fines (if fee/fine notices are developed to allow multiple fee/fines per notice); and having contact information on fee/fine notices based on the location of the lost (or overdue, etc.) item.
Julie asked that we think about best approach, and let her know our thoughts. Julie suggested that a combination of some hard-coded tokens such as the "preferred name or first name" token to solve current issues with logic-branching enhancement to template creation added at a later date could be a pragmatic solution.