2026-06-22 Resource Access Meeting Notes

Date: Jun 22, 2026 

Recordings

NOTE: RESOURCE ACCESS SIG USES EITHER ZOOM’S AI NOTES FUNCTIONALITY OR MICROSOFT COPILOT TO PROCESS THE TRANSCRIPT. If you would prefer that we do not use AI any session you attend, we are happy to! Please alert the convener at the start of the meeting.

Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/  (pw: folio-lsp)

Zoom

https://zoom.us/j/337279319  (pw: folio-lsp)

Attendees:

@Katie Rahman

@Thomas Trutt

@Amelia Sutton

@Cornelia Awenius

@Erin Weller

@Jacob Dudley

@Martina Tumulla

@Olga Kalachinskaya

@Robert Heaton

@Scott Peterson

@Tim Auger

@David Bottorff

Discussion Items:

Meeting Notes

AI-Generated minutes (pardon any errors)

Discussion Points

• Administrative Announcements and Meeting Schedule (Time Range: 00:08:58 - 00:11:47)

  • Status of the Ticket Review: Katie Rahman announced that the committee's ongoing review of outstanding tickets would resume during their next scheduled session on Thursday, June 25th. She shared that the team is in an excellent position with only about 8 tickets left to evaluate, which means they are highly likely to conclude the entire formal review process during that Thursday meeting.

  • Calendar Calming Cancellations: Katie announced that the following week would be designated for "calendar calming". Due to this scheduling adjustment, the regular committee meetings originally set for Monday, June 29th and Thursday, July 2nd are officially canceled, giving members a brief break from sessions.

• Review of JIRA:circ-2578 and Implementation of Loan Period Limits (Time Range: 00:11:47 - 00:29:40)

  • Core Technical Failure of the Ticket: The core topic of the meeting centered around JIRA:circ-2578, which Thomas Trutt shared via a direct link in the chat log. Katie Rahman explained that this ticket addresses a functional failure within closed library due date management, specifically when the loan policy is configured to "move to the end of current service point hours". The feature works correctly if the calculated due date falls squarely within open service point hours, but if it falls outside those hours (such as on a day the library is closed), the system throws an error message instead of shifting the date. As an example, if a patron checks out an item on Thursday or Friday and the library is closed over the weekend (Saturday and Sunday), the system fails to move the due date back to Friday and instead presents an error message to the user.

  • Backend Logic and Calendar Scoping: Thomas Trutt clarified that JIRA:circ-2578 was originally submitted as a bug, and explained that its root cause lies in how elapsed hours are calculated and how calendar data is retrieved from the backend database. For a standard 48-hour hourly loan checked out on a Friday, the system logic assumes the loan will only advance a day or two and consequently fails to pull the calendar far enough in advance. It only retrieves calendar data for Thursday, Friday, and Saturday; when it evaluates Sunday and finds no active hours, it errors out under the assumption that no calendar covers that period. Tom noted that while expanding the calendar-pulling window is an easy fix, it opened a larger architectural dilemma regarding how hourly and minutely loans are fundamentally handled in FOLIO.

  • Historical Design Intent vs. Modern Institutional Use Cases: Tom revealed that the original product owners and developers designed hourly loan periods under the strict assumption that they would be short-term, intra-day loans that would not span multiple days. Historically, the spec dictated that any loan lasting multiple days should utilize a "daily" loan designation. However, modern institutions frequently configure multi-day periods as hourly loans (such as 48 hours, 72 hours, or 168 hours for a full week) because hourly loans ensure an item is due back at the exact time of checkout (e.g., checked out at 5:00 PM, due back in two days at 5:00 PM). Standard daily loans in FOLIO automatically default the due date time to the end of the day (11:59 PM), which does not satisfy strict institutional needs for hourly fines. Because FOLIO currently places no upper limits or guardrails on what values can be entered into the hourly field, a user could theoretically set a 4,800-hour loan (roughly 200 days), which breaks the calendar logic entirely. Tom suggested introducing hard input limits so developers know precisely how much of the calendar must be pulled for backend calculations.

  • Gathering of Library Configuration Data: Tom opened the floor to gather institutional use cases to establish a safe upper limit for hourly loan configurations:

    • Olga stated that her library currently uses a 3-day loan period (configured as 96 hours) for academic reserves and a 1-week loan period (configured in hours) for equipment. They strictly require hourly loans because they charge a $1.00 per hour overdue fine, and they want the exact same fine structure applied uniformly to short-term equipment and 1-week equipment. For closures, they work around errors by moving the due date to the next open day, though they originally preferred restricting it to the same day.

    • Erin Weller echoed Olga's statements, confirming that her library utilizes lengthier hourly loan designations for course reserves (3-day and 7-day hourly loans) specifically to enforce their $1.00 per hour overdue fine policies. She noted that their workflows require the hourly field to support at least a one-week duration.

    • Katie Rahman added that her library employs hourly loan policies for equipment with a maximum duration of 72 hours to enforce hourly fine accruals, and they move most of these loans to the beginning of the next open day. She supported capping the field at one week but noted that two weeks might be safer to accommodate unexpected future requests.

  • Consensus on Upper Limits and Backend Discrepancies: Based on feedback, Tom proposed establishing a two-week upper limit for the hourly policy field to provide a safe buffer for institutions. Tim Auger asked if these hourly increments represent library operating hours or standard elapsed chronological time, and Tom confirmed it is strictly elapsed time. Tom explained that daily loan logic and hourly/minutely loan logic represent completely separate code paths on the backend; daily loans jump full calendar days to 11:59 PM, whereas hourly/minutely policies add exact units to the checkout timestamp and then run logic to check if a day is open or closed. Tim Auger pointed out that this means identical loan durations can result in different due dates depending on the policy path chosen, agreeing that encoding explicit limits is a highly logical solution. Tom noted that the original spec intended minutely loans to be under 60 minutes and hourly loans under 24 hours, but those restrictions were never coded.

  • Overdue Fine Calculations on Closed Days: Jacob Dudley raised a question about fine accrual during closures, asking if an hourly loan continues to accumulate fines during overnight hours when the library is closed. Tom answered that this behavior is completely optional and is controlled via a toggle switch in the fee/fine overdue policy settings, allowing libraries to choose whether or not to count closed hours. Tom shared a personal anecdote, mentioning he had attempted to enable closed-hour fine accumulation at his own institution, but the administration rejected it as unfair to patrons since items cannot be physically returned while the building is shut down.

• Branch Loan Due Date Issue at UChicago (Time Range: 00:29:40 - 00:34:15)

  • Description of the 14-Day Loan Error: David Bottorff from the University of Chicago joined the meeting late, and after Katie Rahman jokingly welcomed him right as they were about to conclude, David asked if fixed calendars had been discussed yet. Tom caught him up on the JIRA:circ-2578 hourly loan conversation. David then introduced a separate issue taking place at a small branch library at UChicago: when executing a standard 14-day loan policy, the system automatically shortens the loan duration to 12 days, forcing the item to be due on the 18th instead of the 20th. David explained that because it only affects a single small branch, they have not dedicated significant resources to troubleshooting it.

  • Potential Correlation to the Calendar Bug: Tom evaluated David's description and suggested that this branch error might be directly linked to the same underlying backend calendar-pulling calculation bug affecting JIRA:circ-2578. Tom noted that because UChicago's issue involves an automatically generated due date, the proposed two-week cap wouldn't directly fix it if their base policy is already under two weeks, but the underlying fixed calendar calculation may be linked to the same backend logic. Tom offered to add UChicago's branch details to the active developer investigation for JIRA:circ-2578 so engineers can verify if it shares the same root cause. If developers discover it is a distinct issue, Tom noted they will spin off a brand-new JIRA ticket specifically for David's branch library. David agreed to send the technical details to Tom via Slack.

✅ Decisions Made

• Establishment of a Two-Week Upper Limit Cap for Hourly Loan Policies: A formal decision was made by the committee to implement a hard two-week upper limit (cap) on the hourly loan policy field in the user interface. This decision was spearheaded by Thomas Trutt with unanimous agreement from Katie Rahman, Olga, and Erin Weller. The rationale behind this cap is to provide backend developers with a predictable calendar-pulling window for their due date calculations, thereby permanently fixing the calendar retrieval errors caused by open-ended hour inputs while still fully accommodating libraries that use 3-day or 7-day hourly policies to enforce hourly fines.

• Creation of a Matching Two-Week Upper Limit Ticket for Minutely Loan Policies: Thomas Trutt decided that he will write up a separate JIRA ticket to enforce a matching two-week upper limit on minutely loan policies. The rationale is to maintain total consistency across all time-based loan configurations, as developers have previously confirmed that minutely and hourly loan policies rely on the exact same underlying calendar-pulling backend logic.

• Consolidation of UChicago's Branch Library Issue into JIRA:circ-2578 Review: It was decided that the unique 14-day loan policy defect occurring at a small branch of the University of Chicago will be appended to the current investigation for JIRA:circ-2578. This decision was made by Thomas Trutt and accepted by David Bottorff, with the rationale that the branch's unexpected due date truncation likely stems from the same core calendar retrieval and calculation bug on the backend.

📄 Action Items and Follow-up

This section highlights the tasks assigned, responsible individuals, deadlines, and scheduled checkpoints, organized around the meeting's major discussion points and their respective time ranges:

• Review of JIRA:circ-2578 and Implementation of Loan Period Limits (Time Range: 00:11:47 - 00:29:40)

  • Action Item — Document Agreed Limits and Write Minutely Loan Ticket: Thomas Trutt is responsible for updating the description of JIRA:Circ-2578 to formally request the implementation of a two-week front-end limit on hourly loan policies. Additionally, he will draft a separate, brand-new JIRA ticket to request an identical two-week limit for minutely loan policies to ensure frontend and backend consistency. Tom will also consult with developers to determine if these limits should be strictly confined to the front-end interface or extended to the backend APIs.

    • Responsible Individual: Thomas Trutt

    • Deadline: Ongoing, to be completed during the current ticket review cycle

  • Action Item — Fine Accrual Review: Institutional reps should evaluate their own configurations regarding whether overdue fines count or exclude library closure hours based on their individual institutional policy preferences.

    • Responsible Individual: All Committee Members

    • Deadline: Internal institutional review

• Branch Loan Due Date Issue at UChicago (Time Range: 00:29:40 - 00:34:15)

  • Action Item — Submit Branch Technical Specifics via Slack: David Bottorff must compile the specific technical configurations, policy parameters, and calendar rules for the small UChicago branch library experiencing the 14-day loan truncation bug (where the system incorrectly sets a 12-day due date) and send this data directly to Tom via Slack.

    • Responsible Individual: David Bottorff (UChicago)

    • Deadline: As soon as possible following the conclusion of the meeting

  • Action Item — Append Branch Data to Developer Review: Upon receiving the technical specifics from David, Thomas Trutt is tasked with adding these details to the investigation notes for JIRA:circ-2578. He will instruct the development team to check if it shares a root cause with the calendar bug, and if they determine it is a separate issue, Tom will spin off a new dedicated ticket for UChicago.

    • Responsible Individual: Thomas Trutt

    • Deadline: Upon receipt of information from David Bottorff