Date
...
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 | |
| Loans | Discuss with Rameka (TAMU) to make sure fees/fines will accommodate manual billing without affecting automated billing, and bring back to the group | |||||
| Item state | Emma Boettcher | Display counts by shelving location to accommodate reserves Most important piece of history is "Where is it?" - the rest can be a click away |
Notes
- Automated fees discussion
- Staff can manually mark an item as lost (e.g., as self-reported by patron)
- What happens if automated fees/fines are not set up to be applied when an item is declared lost
- How many institutions do not use automated fees?
- TAMU-mixture-automated lost item processing fee, and then manually apply replacement cost-tracked by a report
- The question is whether there has to be a different workflow for manually marking something as lost or if it can simply invoke the same process as the automated process
- if there is no automated fee fine, how do we know when the matter is settled and the loan can be closed?
- Is the loan processing fee charged by TAMU sufficient for the proposed manual approach or is something more needed?
- Emma will work with Holly and Rameka to arrive at a solution for TAMU and bring it back to the group
- Holly will bring back the fee/fine policies discussion to the group as a reminder
- What can one see in item circulation history
- current item state and when the state changed
- # CKOs, #IHU since acquistion
- Dates for last loan, last IHU
- Are these the only stats that are needed?
- It needs to be able to distinguish between locations (was the item on reserve or not for the count of loans, IHU, etc.), likely no more then 3-4 locations over their lifetime
- last date that it was loaned tied to count, last in house use date to that count
- who/when/where when item was last touched - how extensive?
- current and previous borrower
- the most recent touch (who/when/where) and ability to quickly get to a more extensive history of all touches
- difference between states, item state as opposed to processing state
- ability to distinguish between item state update and a check-in that does not update the item state
- okay to get to the broader history by clicking off the item record screen to another screen
- should an inactive user be able to create a request?
- consensus is no
- pop up would tell you that the person is not allowed because requestor is inactive
- this also needs to be released via API to the discovery layer for inactive users
- Is there any need to be able to override this block and allow the inactive user to place the request? Or can we fix the inactive state and then do the request? We agree on the latter
- Also we need the default view in all user lookups to be showing both inactive and active users, current default is active users only