Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

































 

Attendees:  Khalilah Gambrell Patty Wanninger Julie Bickle Dennis Bridges Tiewei Liu Cheryl Malmborg Charlotte Whitt Magda Zacharska Ann-Marie Breaux Owen Stephens Stephanie Buck  Brooks Travis 

 TopicsTimePresenterAgenda/Notes
Announcements 20 minutes


All 

  • Lotus HF #1 released
  • Lotus HF #2 - No date yet or dashboard 
  • Morning Glory 
    • Please start adding your Morning Glory Release Notes - Morning Glory (R2 2022) Release Notes
    • Please clean up your Morning Glory FOLIO features statuses
    • Bugfix period - use it to fix bugs/tests/prep for Nolana etc. Do not use for new Morning Glory development or to address a P3 bug that cannot be tested at all during bugfest (i.e. a P3 bug that will take more than half a sprint to complete). 
      • Priority: Address P1/P2, Wrap up Morning Glory development asap, Test Morning Glory development, Prepare for Bugfest do not wait... do now. 
  • Will discuss MODINVSTOR-925 tomorrow 
  • WolfCon Asia-Pacific - July 15th - there will be English translation. Please register for the program! 
Defining delete instance record requirements- next steps discussion 40 minutes[Khalilah, Charlotte Whitt 

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:

Complete list of use cases for Deletion of instances

Deletion of instances - dependency check

Slack channels:

#app-interaction-when-deleting-instances (public)

#app-interaction-deleting-instances-dev (private)

Next step: 

  1. UXPROD-3621 Mark instance for deletion. Implement action menu in top navigation bar. Enable the user to mark an instance for deletion  (Nolana, fingers  crossed)
    1. list of corresponding feature for related work on dependent apps:
      1. UXPROD-3092 Corresponding Data Import & SRS MARC Bib work required for Instance "Mark for deletion" 
  2. UXPROD-1624 Deletion. Implement action menu in top navigation bar. Enable the user to delete an Instance (Orchid)
    1. list of all corresponding features for related work on dependent apps: 
      1. ...
      2. ...
      3. ...
      4. ...

Khalilah's notes, reviewed by Charlotte:

Mark for Deletion requirements | Catalog to Patron discovery | Source = FOLIO
1. Action: Mark for deletion (Responsible team: Prokopovych) - UXPROD-3621-- When user selects Mark for deletion what should happen to that record? (Next step: Charlotte to confirm requirements with MM SIG and post a link to requirements to wiki page dedicated to this feature, and POs tied to this requirement will  write their requirements. These requirements should include if any dependency checks (e.g. has a holdings records attach , item record attach , open loan, open requests etc.) are needed to mark a record for deletion.
-- Dedicated Inventory permission (Responsible team: Prokopovych) [Next step: Charlotte to confirm with MM SIG requirements] - UIIN-1979

2. Edit instance record UI (Responsible team: Prokopovych)  [Next step: Charlotte to confirm with MM SIG requirements]

3. Inventory search (Responsible teams: Prokopovych/Spitfire)
- Search > New filter - Mark for deletion - UIIN-1094  (Responsible teams: Prokopovych/Spitfire)[Next step: Charlotte to confirm with MM SIG requirements]
- Default search query change (Responsible teams: Prokopovych/Spitfire) [Next step: Charlotte to confirm with MM SIG requirements]
- Verify if mod-search needs update/create new permission - MSEARCH-321 (Responsible teams: Spitfire) [Next step: Khalilah will verify]

4. Find instance and Find items plug-ins (Responsible teams: BE: Spitfire; UI: Prokopovych)
- Search > New filter - Mark for deletion (Responsible teams: Prokopovych/Spitfire) [Next step: Charlotte to confirm with MM SIG requirements]
- Default search query change (Responsible teams: Prokopovych/Spitfire) [Next step: Charlotte to confirm with MM SIG requirements]
- Verify if mod-search needs update/create new permission (Responsible teams: Spitfire) [Next step: Khalilah will verify]

5. Data export? [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. [Next step: Charlotte to confirm with MM SIG requirements]

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

Baseline Definition of Done (revisions) 40 minutesPostponed 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