2021-06-10 Resource Access Meeting Notes

Jun 10, 2021

@Elizabeth Chenette

@julie.bickle

@(OLD ACCOUNT) Erin Nettifee

@Robert Scheier

@Marie Widigson

@Pamela Pfeiffer

@Monica Arnold

@Erin Weller

@Brooks Travis

@lisa perchermeier

@Cornelia Awenius

@Amelia Sutton

@Cheryl Malmborg

@Andrea Loigman

@Darcy Branchini

@Laurence Mini

@David Bottorff

@Karen White

@Martina Tumulla

@Rameka Barnes

@mey

@Lisa Sjögren (EBSCO)

@Kimie Kester

@Jana Freytag

Discussion Items

For the Ap Interaction SIG we want to have as many RA use cases described as possible, to make sure that all possible problems with data not getting synced are brought to the attention of the Ap Interaction SIG. Cases where data is not being kept in sync should be noted. One example would be a request for an item on order – this would require syncing of data between Requests and Users and between Requests and Inventory. Another example would syncing from lost & charged status and inventory. See  Ap Interactions. RA SIG members should add any more use cases they can think of..

David raised the point that where Fees/Fines are concerned, data syncing could be problematic. For example, if a fee is charged on an item when it was a reserve item, and the item is taken off reserve, the fee/fine should still reflect the fact that the fee was charged at the time when the item was on reserve – in this case the historical data should be preserved. SIG members could not think of any other area where syncing would cause difficulties.

Jana and Brooks will be attending the Aps Interaction SIG tomorrow. Jana will post a link to the recording.

Gap Analysis: See Jana's Gap Analysis. Some of the gaps between desired and available features have no UXPRODs/JIRAs and so have not been ranked. For example, there is no JIRA for automatic slip printing. Andrea offered to write user stories for the gaps with no JIRAs.

Thomas mentioned that it would be good to have a way to see what has and hasn't been printed. Jana agreed, and added that it would be good to have a way of re-sending to the printer those things that did not get correctly printed.

With regards with the issue of knowing on what printer something printed, Erin explained that this is very hard to do without having a desktop ap.

It was agreed that there would be a one-meeting subgroup (Darcy, Julie, Jana and Erin) to create user stories.

Hidden / Visible Permissions: Thomas described issues that can arise with having some permissions being hidden and others visible. Should there be an easier way to view hidden permissions? Currently viewing hidden permissions is linked to the session, and expires when the session is over. If someone has hidden permissions and then permissions are later edited without having the hidden permissions visible, this can cause the hidden permissions to be over-written.

Lisa joined the meeting to discuss the problem of Scheduled notices with NextRunTime in the past (see Slack discussion). This can result in a patron receiving a bunch of different notices at once, causing confusion to the patron and headaches to library staff.

Darcy explained that there are three different types of notices: recurrent notices, where sending a notice causes the scheduling of the next notice; notices which are sent as result of item state changes; and session notices that are sent at the end of a check-in/out session. Due date courtesy/reminder notices are scheduled and created when an item is checked-out, and then they lie in wait to be sent at the appropriate time.

The problem with loans migrated from another system, where some loans may have due dates in the past, has been documented by Texas A&M. The work-around is to turn off email notifications during the loan migration, and remove notices with a due date in the past before turning email notification on.

Question was raised as to whether there was ever a need to have a newly created notice have a runtime date in the past, and if blocking created notices from having a runtime date in the past could solve this issue.

Lisa described another situation that arose at Chalmers. A very overdue item was recall-requested. Recalls normally change the due date of an item, but Chalmers has selected the option to never have due dates extended into future times. Therefore, when the item was recalled, the due date was changed to the same due date it had been. This 'change' in due date triggered the sending of the recall notice, and also all the courtesy and overdue notices were re-sent, creating confusion for the patron.

Brooks suggested having the due-date-change fail in this situation (changing a due date to the same due date) as a possible solution.

Darcy said there has been discussion on how to handle the different types of notices for recalling an overdue item, vs. having a recalled item become overdue, etc.

Marie, Lisa, Cheryl and Darcy will meet to discuss this issue further.