Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


...

TimeItemWhoDescriptionGoals/Info/notes
5minAdministrivia


Note taker: 

Laurence Mini 


meeting_saved_chat.txt

meeting_saved_closed_caption.txt

35 MinRefund processHolly Mistlebauer 

Widget Connector
urlhttps://docs.google.com/presentation/d/1LgbcXIMkn-RZkdxf9ACNpXXvUMofWIs6/edit?usp=sharing&ouid=109009310759711366749&rtpof=true&sd=true


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.
/+/ Customers get more control on what they can add to the template.
/+/ "Only" one big development cycle.
/-/ This is similar to writing code: the template editor will become much more complex. Are you ready for that?
https://handlebarsjs.com/guide/builtin-helpers.html#if
https://docs.celigo.com/hc/en-us/articles/360045564992-Handlebar-expressions-for-date-and-time-format-codes
/-/ Is there a solution that can cover all our use cases? à Are there more cases of “computation” needed?


Work around = For every case, created a new token, e.g. "either FirstName or PreferredName", where the branching is hard-coded.
/+/ Writing templates doesn't get more complicated.
/-/ Each token needs to go through the whole development cycle.
/-/ The list of tokens could get very long... and the documentation must be meticulously maintained. à Would it really get that long?

One important question = how long does it take to develop? Could e.g. "Prefered name" be made available sooner, but still have the new template engine later? → Yes! If we can agree on the hard-code, developing a single token sooner would be faster. These are not either/or options.


...

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 a Jana will form a subgroup to decide on that will recommend how best to proceed. See also 

Provide option to cancel a fee/fine at the time a manual refund is enteredUse fee/fine refund to pay other fees/fines, Notify Bursar (and other transfer accounts) of refunded fees/finesAllow "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. 

...

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.