Date
Attendees
- Emma Boettcher
- Kai Sprenger
- Susan Kimball
- Kimie Kester
- Sharon Wiles-Young
- Rachael Smith
- Tania Hewes
Alexander
Discussion Items
| Time | Item | Who | Description | Goals |
|---|---|---|---|---|
| 5min | Housekeeping |
| ||
| 20min | Renewals for 'fixed' loans | sthomas (Deactivated) | Decision: How to handle Fixed Due Date loans with renewals. While fixed loans are renewable, there is no notion now of a renewal length for a fixed loan. The option of 'alternate fixed due date for renewals' would only work for the first renewal. Affects renewal override effort as well. | |
| 20min | Fixed due date schedule maintenance and affect on fixed term loan policies | sthomas (Deactivated) | Discussion: How fixed due date schedules and policies for fixed loans are maintained in practice. Decision: What, if any, additional functionality is needed to accommodate fixed loans made at or near fixed-term-end dates? | |
| 10min | 1 - Does minimum guaranteed loan length apply independently of a recall and, if so, 2 - Does minimum guaranteed loan length override fixed due date limits for rolling loans? | sthomas (Deactivated) | Decision: Overriding factor in conflict between fixed due date limits on rolling loans and minimum guaranteed loan length (if min. guaranteed lenth is meant to apply independent of an existing recall). Currently, fixed due date limits may truncate the length of a rolling loan. If that happens, and the loan length would be less than the minimum guaranteed loan length, which setting should be applied to calculate a due date? | |
| 10min | Questions about In transit modal text | Cate Boerema (Deactivated) | The in transit modal text specified (and implemented) for in transit to home location is: Route <title of item> (Barcode: <barcode of item>) to <name of destination service point>. The in transit modal text specified (not yet implemented) for in transit for a request is: Route <title of item> (<material type of item>) (Barcode: <barcode of item>) to <name of destination service point> for a request. | 1. Do we need to have two different modals for transit to home location and transit for request? Is the distinction important at this point in the process? I'm asking because the impact of this could be that the UI (or other client) will need to understand both that the item is In transit and specifically why it is In transit. This would increase how much understanding the UI needs to have on the various processes which might result in an item being transited. 2. The request specific text also includes the name of the material type. To do this, we would likely need to add an additional step in the API for looking up the material type for the item (slowing down the check in operation) or the UI would need to fetch this information separately. Do we need this when the existing transit modal does not have it? |
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Reasoning | Link to Supporting Materials | Comments |
|---|---|---|---|---|---|---|
| e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| e.g. mock-up, JIRA issue | |
Notes
Fixed due dates and renewals (Sean):
Q: How to calculate the due date when the fixed due date is sooner than the minimum guaranteed loan due date? Options:
- Create an alternate due date that would apply in such circumstances. The alternate due date could be a rolling due date.
- Renewal date would be the next semester’s fixed due date
- Other?
It was decided to discuss this issue with reps from the U of Chicago, who had requested the alternate due date feature
Modals for In-Transit discharges (Cate):
When an item has a request on it and goes in transit to a pickup library, what information do we need on the modal? Currently, the modal does not indicate there is a request, but simply says to route to <library X>. Cate said that to include additional information would require considerably more programming. Is this piece of information necessary? The Five Colleges do need this because of their work flow (they also need the actual patron information); most other libraries felt that having a statement that the item had a request would be helpful, at minimum. Cate asked if it would be enough to have the requestor information print out on the routing slip? Five Colleges: no, since they don’t print the slips; William, no, because of privacy concerns in a public-facing workstation; Susan and Andrea, no, because they must have the information before the routing slip is printed; Cornell does not need patron information on the modal, or even the fact that there is a request, because all in-transit processing goes through the same channel; but it would not hurt to have it. Cate concluded that we may need an additional in-transit modal for items with holds – save for future discussion