| | Item Statuses | | Update and proposed plan of attack for requirements Assumptions - Item status cannot be manually changed; item status is always derived through something else so it doesn't mean you cannot affect the item status (i.e., manually check in item or marking an item lost, etc.)
- Item status will not be a repeatable field, but instead might be a compounded field (i.e., checked out - recalled)
- Discussion around a few questions
- A single item status or multiple item statuses?
- Indicates/affects availability only? Andrea wondered about do they also affect display, workflows and condition issues, some systems handle these through item status. David suggested flags (or other fields) might serve this purpose. Availability need to be set manually?
- Custom item status? Example provided - withdrawn because of a specific agreement (shared print repository) Cate captured several more examples provided by David, Cheryl and Mark. Probably need these to solve workflows that might be unique to a specific institution.
- Seems simplistic. It might work, but only if there is another way to add complexity. Claim return - affects availability but it also is tightly related to staff workflow.
- How does this fit into NCIP?
- Status - what does it mean? what are we referring to?
- Andrea is concerned that we are going forward with a lot of functions/feature by simplifying the requirements and building it with assumptions, and then planning to circle back later. She thinks instead we should be taking into consideration all use cases, including edge cases, etc. Cate is suggesting that this gets build incrementally because this is an area that has a big impact on requirements. Cheryl suggested that perhaps more talking across SIGs as well.
- Tania suggested a language change. Instead of using the language "cannot manually change" using the language "cannot be directly edited."
- Wendy wondered if automatic/system generated statuses versus manual generated statuses - is this the right way to differentiate.
|