Item states (status)
(UXPROD-1321)
|
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Item states (status) |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Emma Boettcher | Assignee: | Thomas Trutt |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | itemstate | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Item states (status) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Marc Johnson | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | This would require changing representation of an item status.
It would also need decisions about how to refer to item statuses within the system, e.g. how does another module know that 12345 = checked out, and that this status exists for this tenant The estimate reflects that there are technical decisions to be made, as well as significant impact on modules across the system (e.g. circulation, maybe acquisitions, data import etc) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 93.3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Currently item status is restricted to a list of values as specified in the item JSON schema: In order to continue development on the item state feature, we need to create reference records for item status instead of using the hard-coded values in the schema. This is needed to support adding additional configuration values, support custom item statuses, and potentially to support translation workflows. While this jira is currently assigned to Prokopoych, the needed work spans multiple modules and multiple development teams, so the description here is meant to start drafting the needs in one place, and then it can start to be split apart into multiple features. Considerations A longer document outlining feature needs and scope is in the FOLIO wiki at |
| Comments |
| Comment by Jacquie Samples [ 23/Sep/20 ] |
|
Our current system does not use a string-model for Item status, many RA and MM workflow rely on these data being present and correct. Not using a reference model, could break those workflows and data flows, meaning a poor user experience for our patrons. Human error would make It that much more difficult to switch from a label-model to a reference-model in a future scenario. A reference model gives us more flexibility and the option of converting all labels from one to another. |
| Comment by Tim Auger [ 01/Nov/22 ] |
|
Erin Nettifee What is the business problem that this feature seeks to solve? Is this for offsite storage or extending item statuses (and then what are the problems seeking to solve) or other things? |
| Comment by Erin Nettifee [ 01/Nov/22 ] |
|
Hi Tim Auger - the latter - extending item statuses to support additional functionality and (eventually) a workflow engine. The use cases are things like
Item status has a long project history - the epic (
|
| Comment by Tim Auger [ 02/Nov/22 ] |
|
Erin Nettifee thanks for the detailed response. I'm going to read some of the references and get back in touch with follow ups. |
| Comment by Tim Auger [ 02/Nov/22 ] |
|
Erin Nettifee Just read the documentation. To confirm, just item status, not the status of other record types? Following are more specific questions...
I like the reference model. |
| Comment by Erin Nettifee [ 29/Nov/22 ] |
Yah, that's all this feature is meant to encompass. I haven't thought about requests, for example, and whether request types should also be moved in this direction.
There are not currently reference records for item status – this feature is about transitioning to that model. I can try to make that language clearer.
That's a good question. Right now, item status isn't supported in translation, so theoretically this feature could make that possible by allowing individual libraries to change the label. But it wouldn't be part of the internationalization system built into FOLIO, in part because if you were creating a new value for item status, FOLIO doesn't know what that value is ahead of time in order to be able to provide the translation, if that makes sense. |