2020-11-11 Meeting Notes
Date
Attendees
- Maura Byrne
- Björn Muschall
- Uschi Klute
- Catherine Smith
- Amelia Sutton
- Monica Arnold
- patty.wanninger
- Philip Robinson
- Michelle Suranofsky
- Brooks Travis
Goals
- Discuss dependencies for User deletion
- UXPROD-1811 - Password/PIN fields
- Product Council governance document
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
Discuss dependencies for User deletion | Which JIRA ticket should be addressed first? UXPROD-2728 (Delete users through the API) or UXPROD-2388 (Delete users through the UI)? We decided we wanted the API deletion first. Our initial list of patron blocks that would have to be absent or resolved was the following: Unexpired proxy borrower/sponsor relationship; Loans; Fines; Requests. There was some discussion of the Proxy/Sponsor relationship. Do we need to worry about it while deleting users? Yes, because it's a dependency. That relationship should be expired. If we delete the proxy, do we delete the sponsor as well? Probably not. If we delete the Sponsor, should we silently end/expire the relationship with the proxy? The user stories for both tickets are essentially the same, the only difference being the method we use for deletion. Should the API deletion return a report of the number of users deleted? Can we have it return UUID and barcode for each user deleted? Can we add the name of the deleted user as well? In the UI, a "delete user" button should only show up in the full user record. If there are dependencies, there should be a pop-up message saying that the user couldn't be deleted, and list the dependencies that have to be dealt with. Any user deletion, whether through the UI or the API, should check for dependencies before doing the deletion. | ||
Discuss report after User deletion is run | What format should the report of deleted users be in? Should we use JSON, or .CSV format? Should it be visible as an in-app report in the UI? The API can only output JSON. The UI can translate that to CSV. | ||
Password/PIN fields | Leipzig might be able to take on this ticket, because it's a high-priority ticket for them. Björn and Patty will discuss, and invite Andrea Loigman, Cate Boerema and Annika for next week's meeting. | ||
An impromptu Patron Blocks | There is some confusion regarding Patron Blocks. Some refer to Blocks as things that require an action before a transaction can proceed. Others refer to Blocks as anything attached to the patron or user record ("informational blocks"). We agreed that a Block stops the transaction, while a "Note" will just give a pop-up with user information. The "Note" should use the same architecture as Blocks, but that doesn't stop the transaction. |