| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Item Status Name | Status 12/16/2022 | Inventory Deletion OK / OK With Warning / Not Allowed | Data Import/Bulk Edit (not yet implemented) | Holly's Fee/Fine Comments | Charlotte's Jira comments | OLD - Comments from Antje and Jana | Comments from Erin | ||||||||||||||||||||
2 | Aged to lost | Pending feature: handle view loan when item deleted (CW) | Not Allowed | Not Allowed | UIIN-2136 √ (Nolana) Action item: Add UIIN ticket tweaking the wording of the confirmation modal. Stop text after: "... can not be deleted." | |||||||||||||||||||||||
3 | Available | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks - overdue fines) | Allowed (assuming dependency checks - overdue fines) | If overdue fines are still owed by previous patron(s), do not allow deletion of inventory item. | Allowed - and implemented √ Write up additional tickets adding dependency checks for: 1) Over due fines for current patron 2) Over due fines for previous patron | "Allowed" just refers to the item.status. As soon as one of the following additional dependency checks becomes true, the deletion should be rejected by the system. - open or closed fees/fines are connected to the item - open requests (maybe available items with open requests could exist. And items with status "in transit" can be associated with open requests) - closed loans connected to the item (Easy Way for closed loans: Deletion allowed and remove item from closed loans list since there is no gain from them without title information) - ACQ: order/POL-connections (should be discussed with acq SMEs) The item.status also informs us about (some/all?) acquisions-connections and is even triggered by Acq-Apps (On Order, In process, Order closed). -> Should we ask ACQ SMEs, if an item deletion with status On order or In Process or Order closed will cause inconsistency or a lack of information? | After some discussion it seems that the concern about item deletion for closed loans is when the loan is still on the user's record (e.g., the loan has not been anonymized.) If the item is deleted and the loan still appears on the open or closed tabs, than the UI looks broken. This could be thought of as: * allow deletion if an item has closed loans but they are anonymized (e.g., there is no userId field on the loan) * allow a library to decide if an item should be retained until any loans are anonymized (e.g., configurable deletion options) For fee/fines the concern is similar, the issue is that fee/fine anonymization is not implemented (https://issues.folio.org/browse/UXPROD-1853) so you could not make the deletion decision based on a similar logic. Could they leverage the UI settings in Settings > Circulation > Loan anonymization? Add some additional configs in Settings > Circ? * Allow item to be deleted if all loans: closed, closed and anonymized.... And then for paid loans, there needs to be work (or analysis to confirm how it behaves) * If a loan is closed, and the fine is paid, and then the item is deleted, what shows up on the fine screen? Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | ||||||||||||||||||||
4 | Awaiting delivery | Pending feature: handle view loan when item deleted (CW) | Not Allowed | Not Allowed | UIIN-2187 (Orchid hopefully) | |||||||||||||||||||||||
5 | Awaiting pickup | Pending feature: handle view loan when item deleted (CW) | Not Allowed | Not Allowed | UIIN-2086 √ (Nolana) | |||||||||||||||||||||||
6 | Checked out | No work needed | Not Allowed | Not Allowed | Not allowed - and this i implemented √ | |||||||||||||||||||||||
7 | Claimed returned | Pending Orchid work (CW) | Not Allowed | Not Allowed | UIIN-2137 (Orchid hopefully) | |||||||||||||||||||||||
8 | Declared lost | Pending Orchid work (CW) | Not Allowed (fine question?) | Not Allowed (fine question?) | Shouldn't be allowed. What does "fine question?" mean? | UIIN-2138 (Orchid hopefully) | As Holly we do not know what "fine question" means. Perhaps just the standard dependency checks. See Field 3F | Declared lost implies an open fine so deletion would need to be prevented. | ||||||||||||||||||||
9 | In process | Pending feature: handle view loan when item deleted (CW) Pending Acquisitions SME conversation (TBD) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ New requirement - implement dependency check for fees/fines and requests. Also needs to be confirmed with Acquisitions SIG. | Ask ACQ SMEs? | ||||||||||||||||||||||
10 | In process (not requestable) | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ New requirement - implement dependency check for fees/fines and requests. | See above Field 3F | ||||||||||||||||||||||
11 | Intellectual item | No work needed | Allowed (assuming dependency checks) - CDL? | Allowed (assuming dependency checks) - CDL? | Allowed - and implemented √ Not sure what dependency check is intended? The modal should display information about linking to possible CDL connections? Please provide examples. | Intellectual item can't circulate, so it's not related to CDL workflows. | ||||||||||||||||||||||
12 | In transit | No work needed | Not Allowed (could we implement permission controls?) | Allowed (assuming dependency checks) | If overdue fines are owed by previous patron, do not allow deletion of inventory item. | Not Allowed - and this is implemented √ | Triggered by Check in app. At the moment deletion of items with status "in transit" is not allowed in inventory UI, if there is an associated open request. If no open request is associated (e.g. when the item is checked in at the wrong counter), the deletion of items with status "in transit" is allowed. Is a diffenence between column B and C necessary? | After some discussion it seems that the concern about item deletion for closed loans is when the loan is still on the user's record (e.g., the loan has not been anonymized.) If the item is deleted and the loan still appears on the open or closed tabs, than the UI looks broken. This could be thought of as: * allow deletion if an item has closed loans but they are anonymized (e.g., there is no userId field on the loan) * allow a library to decide if an item should be retained until any loans are anonymized (e.g., configurable deletion options) For fee/fines the concern is similar, the issue is that fee/fine anonymization is not implemented (https://issues.folio.org/browse/UXPROD-1853) so you could not make the deletion decision based on a similar logic. Could they leverage the UI settings in Settings > Circulation > Loan anonymization? Add some additional configs in Settings > Circ? * Allow item to be deleted if all loans: closed, closed and anonymized.... And then for paid loans, there needs to be work (or analysis to confirm how it behaves) * If a loan is closed, and the fine is paid, and then the item is deleted, what shows up on the fine screen? Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | ||||||||||||||||||||
13 | Long missing | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | After some discussion it seems that the concern about item deletion for closed loans is when the loan is still on the user's record (e.g., the loan has not been anonymized.) If the item is deleted and the loan still appears on the open or closed tabs, than the UI looks broken. This could be thought of as: * allow deletion if an item has closed loans but they are anonymized (e.g., there is no userId field on the loan) * allow a library to decide if an item should be retained until any loans are anonymized (e.g., configurable deletion options) For fee/fines the concern is similar, the issue is that fee/fine anonymization is not implemented (https://issues.folio.org/browse/UXPROD-1853) so you could not make the deletion decision based on a similar logic. Could they leverage the UI settings in Settings > Circulation > Loan anonymization? Add some additional configs in Settings > Circ? * Allow item to be deleted if all loans: closed, closed and anonymized.... And then for paid loans, there needs to be work (or analysis to confirm how it behaves) * If a loan is closed, and the fine is paid, and then the item is deleted, what shows up on the fine screen? Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | |||||||||||||||||||||
14 | Lost and paid | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | ||||||||||||||||||||||
15 | Missing | Pending feature: handle view loan when item deleted (CW) | Allowed (check for dependencies - TLR open question) | Allowed (check for dependencies - TLR open question) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | ||||||||||||||||||||||
16 | On order | No work needed | Allowed (assuming RM OK with this, and assuming dependency checks) | Allowed (assuming RM OK and assuming dependency checks) | Not allowed. | Ask ACQ SMEs? | ||||||||||||||||||||||
17 | Order closed | No work needed | Allowed (assuming dependency checks) | Allowed (assuming RM OK and assuming dependency checks) | Allowed - and implemented √ Inventory tells you that it has no dependencies and the item can be deleted. | Ask ACQ SMEs? | You would never have a loan record associated with an item that has an Order closed status, so this would not be affected by issues viewing the loan in the user interface. | |||||||||||||||||||||
18 | Paged | No work needed | Not Allowed because this means there is an associated open request) | Allowed (assuming dependency checks) | Not Allowed - and this is implemented √ | Is a diffenence between column B and C necessary? The connection to the patron should first be disconnected. Already implemented | The check for requests takes care of other questions - you don't need the fine check because the request check stops the deletion. | |||||||||||||||||||||
19 | Unavailable | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | |||||||||||||||||||||
20 | Unknown | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | |||||||||||||||||||||
21 | Restricted | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | |||||||||||||||||||||
22 | Withdrawn | Pending feature: handle view loan when item deleted (CW) | Allowed (assuming dependency checks) | Allowed (assuming dependency checks) | Allowed - and implemented √ Not sure what dependency check is intended? Please provide examples. | See above Field 3F | Possible user stories * Given an item with no open loans, and one or more closed loans, * If the FOLIO staff member deletes the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. * Given an item with at least one open loan, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the loan. * Given an item with at least one associated unpaid fine, * If the FOLIO staff member tried to delete the associated item, * Then FOLIO denies the deletion in order to preserve the data integrity of the fine. * Given an item with at least one associated paid fine, and no associated unpaid fines, * If the FOLIO staff member tries to delete the associated item, * Then FOLIO allows deletion and retains XYZ fields on the loan record to assist with reporting. UXPROD-3664 - open jira to add loan type and patron group to the account record. We have code in Nolana that handles if item isn't found - shows barcode and text to indicate item wasn't found. ACTION: Can this be a similar approach for loans? UIU-1553 ACTION: With UXPROD-3664 implementing, do we think that older accounts need to have that data backported, or could they simply not have that information? | |||||||||||||||||||||
23 | ||||||||||||||||||||||||||||
24 | ||||||||||||||||||||||||||||
25 | ||||||||||||||||||||||||||||
26 | ||||||||||||||||||||||||||||
27 | ||||||||||||||||||||||||||||
28 | ||||||||||||||||||||||||||||
29 | ||||||||||||||||||||||||||||
30 | ||||||||||||||||||||||||||||
31 | ||||||||||||||||||||||||||||
32 | ||||||||||||||||||||||||||||
33 | ||||||||||||||||||||||||||||
34 | ||||||||||||||||||||||||||||
35 | ||||||||||||||||||||||||||||
36 | ||||||||||||||||||||||||||||
37 | ||||||||||||||||||||||||||||
38 | ||||||||||||||||||||||||||||
39 | ||||||||||||||||||||||||||||
40 | ||||||||||||||||||||||||||||
41 | ||||||||||||||||||||||||||||
42 | ||||||||||||||||||||||||||||
43 | ||||||||||||||||||||||||||||
44 | ||||||||||||||||||||||||||||
45 | ||||||||||||||||||||||||||||
46 | ||||||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||||
48 | ||||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||||
100 |