2022-06-22 Product Owner Meetings
- Khalilah Gambrell
- Magda Zacharska
- Marc Johnson
Attendees: Khalilah Gambrell patty.wanninger julie.bickle Dennis Bridges twliu Cheryl Malmborg Charlotte Whitt Magda Zacharska Ann-Marie Breaux (Deactivated) Owen Stephens Stephanie Buck Brooks Travis
| Topics | Time | Presenter | Agenda/Notes |
|---|---|---|---|
| Announcements | 20 minutes | All |
|
| Defining delete instance record requirements- next steps discussion | 40 minutes[ | Khalilah, Charlotte Whitt | Slack raised on 5/4 - by Hi @kg - could we maybe put on the agenda for an upcoming PO meeting how best to plan for a coordinated release planning for a couple of topics, we need to solve with a cross app approach.
Not all POs need to stay on for this segment. Just those POs that need to support what we want to initially support for Nolana: #app-interaction-when-deleting-instances (public) #app-interaction-deleting-instances-dev (private) Next step:
Khalilah's notes, reviewed by Charlotte: Mark for Deletion requirements | Catalog to Patron discovery | Source = FOLIO 2. Edit instance record UI (Responsible team: Prokopovych) [Next step: Charlotte to confirm with MM SIG requirements] 3. Inventory search (Responsible teams: Prokopovych/Spitfire) 4. Find instance and Find items plug-ins (Responsible teams: BE: Spitfire; UI: Prokopovych) 5. Data export and OAI-PMH? [Next step: Magda to confirm once mark for deletion requirements are confirmed.] 6. Z39.50? [Next step: Charlotte will work with Mike Taylor, and figure out if there is any work needed her] 7. Determine impact edge-rtac/edge-patron. IOW - what do users expect when an instance record is marked for deletion? Should the mark for deletion record be returned in RTAC response? Should the record display under a patron's list of loans. Can the patron renew a loan? Can the patron place request? [Next step: Circ POs Stephanie Buck Brooks Travis and others to confirm requirements with RA-SIG] 8. OPAC/Discovery layers - what do we need to inform libraries in order to not show records marked for deletion? Or do we do nothing? A property flag is set in the record - UIIN-1504. [ Mark for Deletion requirements | Catalog to Patron discovery | Source = MARC - Next step: Khalilah will schedule a meeting for next week with Charlotte, Magda, Brooks, and Ann-Marie. Charlotte will lead discussion |
| Postponed to July |
Adding the meeting chat, since a lot of useful discussion about Instances and marking for deletion
(Only discussed Source = FOLIO Instances; Source = MARC Instances will be discussed in separate mtg)
From Erin Nettifee to Everyone 11:29 AM
Right - the edit / checkbox, and an action API, are incompatable
From Owen Stephens to Everyone 11:29 AM
Is it managed through an action API?
From Erin Nettifee to Everyone 11:34 AM
at least in terms of past FOLIO development approaches
Right - because item status has so much workflow attached to it
Has Kimie, or someone else on the UX end, spent time with these designs?
From Dennis Bridges to Everyone 11:34 AM
I think the permission is the key. If only some can control it you basically need to use the action menu
From Erin Nettifee to Everyone 11:35 AM
Right - or it needs to be in its own accordion
From Dennis Bridges to Everyone 11:35 AM
If it appears in the edit screen it will be available to all users with edit permission
From Me to Everyone 11:35 AM
And source = MARC has lots more bits and pieces to it
From Erin Nettifee to Everyone 11:35 AM
since we do have the ability to have some permission controls via accordion (Users is a good example of that)
From Brooks Travis to Everyone 11:35 AM
My other concern is that this is going to have bearing on other domains in FOLIO, in terms of UX design
From Erin Nettifee to Everyone 11:36 AM
+1 Brooks
From Owen Stephens to Everyone 11:36 AM
Dennis - it might depend on what that is actually doing right? You could make some parts of that form hidden or non-editable dependent on permissions
From Brooks Travis to Everyone 11:37 AM
Personally, I would set/unset "deleted" via an action and show a banner on the detail/edit view.
As a general UX design for FOLIO.
From Owen Stephens to Everyone 11:37 AM
Although it doesn't seem like a great idea, and it feels like it could be a misuse of permissions somehow…
From Dennis Bridges to Everyone 11:38 AM
I suppose but adding a single checkbox to an accordion doesn't seem like the most user friendly way to accomplish that.
From Brooks Travis to Everyone 11:38 AM
I mean, we really need to implement that for staff suppress, anyway.
From Ann-Marie Breaux to Everyone 11:38 AM
If it's an action menu, does it look for any dependencies before allowing it to be marked for deletion? (e.g. does it have items/holdings?)
From Brooks Travis to Everyone 11:39 AM
I would say no, since it doesn't actually do anything.
Those checks would be part of phase 2, the deleted record clean-up that actually removes them.
From Khalilah to Everyone 11:39 AM
I think the default search should not show these mark for deletion records because some libraries really want these records to be gone.
From Ann-Marie Breaux to Everyone 11:39 AM
At least 1 or 2 libraries are using tags for "I would have deleted this if I could", so that they can find them and clean them out eventually - this seems similar to me
From Erin Nettifee to Everyone 11:39 AM
We should ask Kimie to review the UX stuff here, if we haven't already
From Brooks Travis to Everyone 11:40 AM
I think a key aspect of implementing this, though, is getting the permissions for viewing staff-suppressed and deleted records actually implemented.
To get folks what they actually want, which to not see those records by default.
From Ann-Marie Breaux to Everyone 11:41 AM
I volunteer to take a copy of all these comments, which are really helpful and add to the PO Mtg notes
From Khalilah to Everyone 11:41 AM
Brooks, we can do this now by applying additional parameters to the default search query.
From Brooks Travis to Everyone 11:43 AM
totally, but we're not doing that by default
Which is why I loathe that staff suppressed filter
as currently implemented
From Ann-Marie Breaux to Everyone 11:43 AM
If mark/unmark for deletion is an action - would there be 2 permissions? Maybe more people can mark, and a smaller subset can unmark?
From Brooks Travis to Everyone 11:45 AM
Again, this has relevance outside MM
The decisions made here are going to have impacts on how "soft delete" is implemented in other modules/apps
"here" being in this use-case
From Owen Stephens to Everyone 11:45 AM
This isn't a soft delete though Brooks
From Ann-Marie Breaux to Everyone 11:46 AM
Yes - and the mark for deletes seems like it will be used liberally for professor's copies, ILL'd books not owned by the library, etc
It may hurt more things for source = MARC than for source = FOLIO
From Brooks Travis to Everyone 11:46 AM
I think it's the first step toward that, though
From Owen Stephens to Everyone 11:46 AM
It's much much weaker than that. It's the first step in a workflow that might eventually lead to a deletion (soft or hard)
From Brooks Travis to Everyone 11:47 AM
That really wasn't my read
From Ann-Marie Breaux to Everyone 11:47 AM
Yes, I agree about needing clarification
From Dennis Bridges to Everyone 11:47 AM
I was under the impression that these records would ultimately be deleted by an “automated" process. Is that not true?
From Brooks Travis to Everyone 11:47 AM
Same, Dennis
From Dennis Bridges to Everyone 11:48 AM
If so I would essentially equate this “Mark for deletion" with delete
From Ann-Marie Breaux to Everyone 11:48 AM
Which is also why I'm wondering if there's some sort of dependency check before an instance can be marked for deletion
From Brooks Travis to Everyone 11:48 AM
The dependency check would be done as part of the clean-up
And the record would hang around if there were dependencies
From Dennis Bridges to Everyone 11:49 AM
I suppose the dependency check could happen when the system actually tries the delete. But the person who marks it for delete is still responsible for it.
From Ann-Marie Breaux to Everyone 11:49 AM
I'm guessing we might not get to Source = MARC instances today, in which case it may be a cluster at MM SIG tomorrow
From Dennis Bridges to Everyone 11:50 AM
Something would need to indicate that it couldn't be deleted because… or it would sit as marked for deletion indefinitely.
From Brooks Travis to Everyone 11:50 AM
To me, I think of this in a "garbage collection”/"automatic reference counting" model. As long as there's a dependency, then the record isn't actually deleted.
From Ann-Marie Breaux to Everyone 11:51 AM
It just cycles through all the marked ones every x days to see if it can be deleted now - is that right, Brooks?
From Brooks Travis to Everyone 11:51 AM
And you'd be able to run "long-deleted" reports to see records that have long-running dependencies that maybe need to be addressed.
From Dennis Bridges to Everyone 11:51 AM
agreed Owen
From Ann-Marie Breaux to Everyone 11:52 AM
Yes - what Brooks just said - or something after each garbage collection attempt reports on all the ones that could not be deleted, and maybe why - so that someone could work on cleaning them up
From Brooks Travis to Everyone 11:53 AM
To me, I don't see a point in implementing it if it's not part of an automated workflow
eventually
From Ann-Marie Breaux to Everyone 11:53 AM
This is not just catalogers though - it's anyone who creates/maintains instances - which can include Circ/ILL folks
From Brooks Travis to Everyone 11:54 AM
Filtering out the "deleted" and staff-suppressed records by default in Inventory would be a huge win, I think, for UX.
From Owen Stephens to Everyone 11:55 AM
So my view would be that if this is simply a way of collecting a set of records for cataloguer action that you might want to do approach it in a way that allows for extension to other reasons than delete
From Brooks Travis to Everyone 11:55 AM
Shouldn't that only happen with discovery suppress?
From Owen Stephens to Everyone 11:56 AM
So rather than just a checkbox, some set of statuses that could be assigned/not assigned
From Dennis Bridges to Everyone 11:56 AM
I think we call those tags? lol
From Owen Stephens to Everyone 11:56 AM
🙂
From Brooks Travis to Everyone 11:56 AM
They could stay the same on the back-end, just not exposed as checkboxes in the UI.
From Dennis Bridges to Everyone 11:57 AM
We might benefit more from allowing users to delete tags than implementing this new checkbox.
From Owen Stephens to Everyone 11:57 AM
Unfortunately the Tag functionality seems to have adoption issues and lack of resource to realise the full vision for tags (e.g. tag management) means that they don't get used as much as perhaps they could
From Khalilah to Everyone 11:57 AM
I think we need a way to mark a record for deletion so it will kick off a process to actually delete these records.
From Ann-Marie Breaux to Everyone 11:58 AM
I love tags - anyone who wants to work on them, please come see me!! Orphan PO who just wants some help with Tags!!
From Owen Stephens to Everyone 11:59 AM
I think IF 'mark for deletion' actually does something functional then we need to have the deeper conversation - but that doesn't seem to be what Charlotte is proposing
From Ann-Marie Breaux to Everyone 12:00 PM
Tags have never been meant to trigger actions. That was an early decision. Tags are ways to gather groups of records for some reason
From Charlotte Whitt to Everyone 12:00 PM
+1
From Ann-Marie Breaux to Everyone 12:00 PM
The reason to add a field instead of using a tag, would be to make it consistent across FOLIO, instead of just being ad hoc and different for every tenant
From Khalilah to Everyone 12:00 PM
Agree with Dennis. This is step 1
From Ann-Marie Breaux to Everyone 12:00 PM
I should say "one" reason, not "the" reason
From Owen Stephens to Everyone 12:00 PM
I don't think that's what Charlotte is describing
From Brooks Travis to Everyone 12:01 PM
And the “deleted” record attribute could be optional
The default experience should be that it is, effectively, deleted from the UI perspective.
From Ann-Marie Breaux to Everyone 12:01 PM
So long as we are clear on what the setting (or non-setting) is for the existing instances
From Owen Stephens to Everyone 12:02 PM
I wonder if we need a terminology discussion here. I have a very clear idea of what I mean by ‘soft delete' in a system sense, but I'm not sure we have a shared understanding of it
From Steph Buck to Everyone 12:02 PM
Everyone and their dog 😂🐶
From Ann-Marie Breaux to Everyone 12:02 PM
😍
From Brooks Travis to Everyone 12:02 PM
For source=MARC records, the action menu item could call two APIs, one for the Instance and one for the SRS record. To mark them both.
From Ann-Marie Breaux to Everyone 12:03 PM
We have officially gone to the dogs
I'd have the devs decide, Brooks - maybe like that or maybe like the Suppress from discovery flag is handled
From Brooks Travis to Everyone 12:04 PM
My concern there is that it seems like we have a backwards dependency between the back-end modules…
From Owen Stephens to Everyone 12:05 PM
For me a soft delete is a deletion. The “soft" part is a technical level of what happens to the data in the database, but from the user perspective the data is gone
So if this is a ‘soft deletion' then we have to treat it as a deletion IMO
From Ann-Marie Breaux to Everyone 12:06 PM
No, I don't think so. Instance = source of truth for suppress from discovery, plus several other fields that SRS doesn't care about (cataloged date, status, stat codes, admin notes). SRS MARC is the source of truth for most of the rest of the Instance. SRS MARC doesn't care about any of those other Instance fields, but it needs to be synced with the Suppress from discovery value that is on the Instance due to the need to cull them from Discovery pulls from SRS
From Owen Stephens to Everyone 12:06 PM
But if this is a workflow ‘collect records for x purpose' thing, then I'm much more relaxed
From Dennis Bridges to Everyone 12:06 PM
I'm not saying we shouldn't use “Mark for deletion”. I think it is a reasonable approach. However, users should be under the impression that these records will be deleted. Potentially without any other user intervention.
From Brooks Travis to Everyone 12:06 PM
+1 Dennis
From Owen Stephens to Everyone 12:06 PM
Dennis - I think that just drives the issue up a level though?
From Dennis Bridges to Everyone 12:06 PM
Even if that part is not implemented until a future release
From Owen Stephens to Everyone 12:07 PM
It sounds like there is a requirement for a way of creating a set of records that you believe should be deleted but that you don't personally have permission to delete?
From Dennis Bridges to Everyone 12:07 PM
Yes Owen I agree but that sounds like what we actually need here. Users need to be able to actually delete these records at some point
From Brooks Travis to Everyone 12:08 PM
This affects INN-Reach, too
source=MARC
From Ann-Marie Breaux to Everyone 12:08 PM
We need to be really clear to MM SIG tomorrow that source = MARC requirements have not been sorted out yet
From Dennis Bridges to Everyone 12:11 PM
I think the purpose of soft delete would be allowing time for the system to check with other modules whether something can be deleted.
Rather than checking with other users. If just checking with other users you still have the problem of “Can we actually remove this?”. To answer that, any user will need help from the system
From Ann-Marie Breaux to Everyone 12:11 PM
Could you add the Inventory feature into the notes, Charlotte?
From Brooks Travis to Everyone 12:11 PM
INN-Reach just needs to consume the records
From Ann-Marie Breaux to Everyone 12:11 PM
That way we can link our dependent features to it
From Charlotte Whitt to Everyone 12:12 PM
Yes, will do