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.
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.