2021-07-29 Resource Access Meeting Notes

For next meeting, Please look at this table and put in features you would like to discuss: Gap analysis / Review. What we’re looking for here is missing functionality that affects all institutions.

Circ log and patron notice errors - Darcy

Awhile back TAMU noticed a discrepancy between what notices FOLIO was saying was being sent and which ones actually were. Traced back to Circ log, which was erroneously indicating that some notices were going out. See UXPROD-2385 (which is the second-highest feature for notices after being able to print them) for more details.

Notices originate in MOD Circulation or MOD Fee/Fine. There are several other modules that are deep into this process, but these are the ones where the errors are occurring. Basically: notices are failing for legitimate reasons, but not being logged, since all that is logged is notices that are successfully sent out. Fixing this will involve quite a bit of refactoring.

What is happening: “Circ action” column in Circ log will have ability to sort by errors or no errors, and will be relabeled to match tense of rest of app and to be more descriptive.

Question: how much info should be included re: error messages in “Description” field? Consensus of SIG: the more info, the better! No worries if it looks “ugly”--this is the job of a log!

Title level requests - Stephanie

Question: what happens if different circ rules apply to items included in a title-level request? Consensus: requests should follow rules for item + patron combo, even if this yields non-uniform results.

Question: How do we turn an item-level request into a title-level request, and is this necessary if we’re using a single queue? Preference of SIG is for an action menu item. If we implement as a single data model for all requests, switching to/from should be a relatively trivial operation (associating/disassociating an item ID/barcode with/from a request). A migration script could populate necessary info on existing requests, since it’s retrievable. In this implementation, all request would be title-level requests in that they would include direct references to the instance record. If TLR is disabled in tenant, this implementation level would be hidden. Only after TLR is enabled would the instance-level info become relevant and the unified queue come into play. Scenario for changing an item-level request to a title-level request: requested item goes missing.

Question: Once we reach TLR complete, do we need to keep edge-patron TLR functionality in place as it exists now? Consensus of SIG = yes. Would be used if TLR is turned off.

Question: When an item is moved to a different instance in Inventory, how does this get updated in Requests? No solution right now for item-level requests other than when item is touched by circ system (e.g. check in). Consensus of SIG is that there likely isn’t any solution for TLR either. Larger issue = how to keep data in sync across modules. We do need to answer the question of what happens when this does occur, which will need to be dependent on whether the request was item- or title-level.

Sidebar: why would you need to move an item to a different instance? Could be in response to human error or an outgrowth of acquisitions process.

This is all the questions that Stephanie has for the SIG at this time. She will return when Vega starts asking her questions she doesn’t have answers to!

Topics for another day:

How do we force reevaluation of the queue if a request isn't being fulfilled because of incorrect circ rules or other reason (orphan request state)?
Moving requests from one instance to another