Skip to end of banner
Go to start of banner

2022-7-12 Bulk Edit Working Group Meeting Notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »


Attendees (please add your name):

Magda Zacharska Kimie Kester (OLD ACCOUNT) Erin Nettifee Amanda Ros Jennifer Eustis leeda.adkins@duke.edu Jenn Colt Donald Depoorter Christine Tobias Sara Colglazier Timothy Dannay Lloyd Chittenden Erin Weller Scott Perry Timothy Dannay gongd@msu.edu Robert Scheier 

Note Taker:

Robert Scheier  

Meeting Recording:

Discussion:

TopicNotes (Currently in the process of editing the transcription file.--Bob)
Housekeeping
  • Magda: 7:57: As always I would like to ask those that are present in the meeting to add their names to the attendees list. I see there are approximately 17 People in the meeting. We don't have 17 names under the attendees. So please do if you have a chance. Bob, I hope you will continue to be our brave note-taker. Is this so?
  • Bob: Yes.
  • Magda: Okay, thank you.
  • Magda: 8:50: There will be no meeting on July 26th which is our next meeting, I will be traveling and I will I may not have access to a decent internet connection on that day. So, I thought it will be wiser to cancel the meeting. If we need to discuss we will probably use Slack for this. Is there any other housekeeping information from anyone else? Erin has indicated NO, so let's move to the next item on our agenda, the development status.

Development updates

  • Magda: 9:42: This is the current sprint. We are still finishing addressing bugs that we find found in Bulk Edit. Some of them you found in the UAT tests. So hopefully we will be able to address most of them before BugFest starts. If not, I will keep you posted about new deployments. The one thing that I would like to show you is that we have three stories in our backlog that we'll be working on in this sprint that will run performance on larger data sets. I bring it up because the is the feedback I got in the user acceptance testing. There is concern about the performance when using larger data sets. And I am concerned as well. So for the item statuses, for example, we will be testing changing the status from available missing and withdrawal. This is just a subset for testing purposes that will be run on 100 records and then the number will ramp up to 1000, 10,000, and 100,000 records. And the bulk edit will be triggered by submitting files with item barcodes, Item UUIDs, holdings UUIDs, item HRIDs, item former IDs, and accession numbers. There were comments about some problems with some files in UAT. So hopefully we will be able to catch those issues as well.
  • Magda: 12:12: Any comments? A question about that?

  • Erin: 12:22: So this is specifically for item records?
  • Magda: Yes. For item records. We already completed Bulk Edit User MODBULKED-21 - Getting issue details... STATUS
  • Erin: Yeah. That makes sense to me.
  • Magda: development status scrum board, I think we covered that.

Nolana scope update

Features planned for Nolana:

  • UXPROD-3705 - Bulk Edit - User data - in app approach
  • UXPROD-3712 - Bulk Edit - in app approach - loan types
  • UXPROD-3704 - Bulk Edit - in app approach - holdings locations
  • Possibly also:  UXPROD-3713 - Bulk Edit - in app approach - item notes

Other features planned but delayed:

Bulk edit will need to address existing dependencies and that will require additional work.

The feature that was deprioritized by MM SIG:

  • UXPROD-3707 - Bulk edit - inventory items - csv approach
  • Magda: 13:29: Nolana scope updates--when we met last time I provide a few slightly different list. So, what is left from what I was showing is bulk edit user data. In-app approach, we will be trying to add in-app approach for users, so they are in the same pot as item records.
  • Magda: 14:07: For Bulk Edit items, we will add support for loan types. We will also support holdings location similarly to the item location as we implemented in Morning Glory. The other features that are planned but delayed is are the Bulk Delete inventory item records and delete user records.
  • Madga: 14:40: After meeting with developers, they are extremely uncomfortable with the fact that not all the dependencies are being handled. First in inventory all of them are only handled on the UI. So, we need to recreate them. We also are not confident that all the dependencies are actually identified. You can live with this if only deleting one or two records manuall. But once we started deleting hundreds of records, then this issue will be more visible and prominent. So, the development team proposes a separate approach, not soft delete, which means the record is marked as deleted, but still retained in the database, not hard delete, where the record is removed. The option proposed which is now on the table, is called hybrid delete, which means the record is removed from the main table from the users or items, but it still stays in the temporary table stays there, as long as the user are well defined. So adding this temporary table and having the maintenance of this temporary table is adding to the scope of deletion. We will have a better understanding of how much more work it will entail probably by the end of this week once I meet with the development team and architects.
  • Erin: Is there a wiki page?
  • Magda: 16:58: It's not the wiki page just yet. There is a Google Doc. I will put this into the chat when I find it. I probably will not find it right now. I will find it. And I will post this into our Slack channel.
  • Erin: 17:13: I guess I'm not sure why creating a brand new table structure is better than doing a soft delete?
  • Erin: 17:35: I understand the reluctance about these features in general, like that makes total sense to me.
  • Magda: 17:43: I think inventory is especially difficult. Because all the dependencies right now for manually deleting one item are in the UI. So first of all, we have to implement those on the backend. And then not all of them are implemented. So that is something that we would need to investigate as well.
  • Erin: 18:16: Why is the assumption that Firebird would need to do that work versus Prokopovych? is it just like Prokopovych just doesn't have the capacity so Firebird needs to do it?
  • Magda: I think no one has the capacity.
  • Erin: 18:31: Well sure. But I just ...
  • Magda: 18:37: I see Jen's comment. It is the client's responsibility. When you say client Jen, do you mean the software?
  • Jenn: Yeah. Client Yeah.
  • Magda: 18:50: So that this the system that is subscribing to the data. I disagree with this approach to be honest. I fully disagree or partially disagree actually. But we can talk about this maybe during our next meeting, I would like to move on.
  • Unknown Speaker  19:09  

The

Unknown Speaker  19:12  
the last sentence about the deleting item records, there is a parallel initiative that

Unknown Speaker  19:23  
is related to marking inventory instances for deletion that depending on how it will be implemented.


Unknown Speaker  19:32  
We will need to adjust accordingly on our site as well. So more on deletion later, I put the document in the slack chat after the meeting. This is still working progress. More about this probably during our next meeting.

Unknown Speaker  19:54  
The other thing that was on our list, but MMC the prey

Unknown Speaker  20:00  
notice it when we talk about that. Now, last time, I suggested, we will do the CSV approach for items. So it means it means that user would be able to download the CSV file with the item records make the changes locally uploaded to the CSV, something similar to what we do for users.

Unknown Speaker  20:28  
Memcache felt that they would rather

Unknown Speaker  20:36  
invest time in app approach, because this seems to be more desired behavior than for buy, and I'm sick. But go ahead, you have your hand up.

Unknown Speaker  20:53  
You're muted.

Unknown Speaker  20:57  
Go ahead and finish this, then I just have a question to go back to the Delete for a second. Okay. Okay. So I added the comment to the to the future. If anyone is interested, I know some of you

Unknown Speaker  21:13  
think sir, was really interested in this, we are not going to do it in the law. Probably we will do it later, in a few releases.

Unknown Speaker  21:26  
But at this point is not the planet not planned.

Unknown Speaker  21:30  
There is one thing, one other feature that I hope we'll be able to squeeze as well. In Atlanta, which is the item notes. This was dropped during our meeting that once the location changes and the alarm type changes, you would like to have an option of for the item notes to change a meeting with SIG

Unknown Speaker  21:56  
MMC this Thursday, to get a little bit more feedback about the requirements. And we'll see what

Unknown Speaker  22:07  
what we can squeeze. Go ahead. Well, what was your question?

Unknown Speaker  22:13  
I just was wondering what Gen CT was meant by the client. It's the client responsibility.

Unknown Speaker  22:21  
Sorry, I just meant so I'll I'll put the issue in that we failed, we accidentally deleted some items over the API that had loans. When we complained that the API hadn't returned us errors, we were told that it was because the API is meant to let you do whatever you want. And it's your responsibility. When you write your script or your bulk edit program, check the dependencies

Unknown Speaker  22:44  
definitely disagree with this approach. And this is not the business logic should not be in the

Unknown Speaker  22:53  
UI, the business logic should not be in the

Unknown Speaker  22:57  
scripts, the client scripts, the business logic should be handled consistently through failure. So it does it should matter if you're using your or if you're using API, the behavior should be the same.

Unknown Speaker  23:12  
Thanks that clarifies. Thanks.

Unknown Speaker  23:15  
So what I just said about my opinion, this is my opinion. And this is how we will be implementing or tried to implement it in in bulk edit. I'm not saying that everybody else I'm agreeing with with this approach, sir, go ahead.

Unknown Speaker  23:34  
So this is more back to the deprioritize by mmm, six things. So we want to finish this first. Go ahead. And then no, do you go? No.

Unknown Speaker  23:47  
So just just to be double? Sure. So or just, you know, be sure I've understood correctly, it's not that it's off the table is just deeper, it just pushed off, but not with any kind of definite

Unknown Speaker  24:03  
future flour release in mind. So it's an kind of an indefinite push off of bulk inventory of inventory items via CSV approach is that that's correct. The future is in the backlog. It's just not prioritized at this point. So definitely not for Alana, depending on the

Unknown Speaker  24:25  
interest we will get from this group

Unknown Speaker  24:29  
and you're

Unknown Speaker  24:32  
pushing for this

Unknown Speaker  24:34  
and functional

Unknown Speaker  24:37  
Yeah, I mean, I think down the road I think we're it could be especially helpful is if you want to

Unknown Speaker  24:48  
Well, I have to say I'm sorry, like I feel like I've really been nicked I've totally not I just feel I know I have been neglecting book edit here at this group because of

Unknown Speaker  25:00  
Going Live and my brain is really an acquisitions right now. And financing fiscal year roll and all these things right. So I'm a little distracted.

Unknown Speaker  25:11  
I guess the

Unknown Speaker  25:13  
I do think that like pathwise. And complexity wise, there can be real benefit to being able to do this in a CSV file quantity and complexity of changes, like multiple changes, right, where you have a set of items that have to be there loan type has to change, and they're temporary status. And that just to me seems like a much better thing to handle via the CSV file. So I think I do still advocate for that in the longer term I think having, but I totally understand that in app should come first. So I'm fine with that. I just don't want this to be one of those.

Unknown Speaker  25:56  
What were we calling them for a while they got some name, things that just then go to the backlog and die slowly in their corner and are never heard again. And then you do some kind of lookup, and you discover that it says 2019 on them or something.

Unknown Speaker  26:13  
So I agree with you,

Unknown Speaker  26:16  
Sarah, on this,

Unknown Speaker  26:19  
because we I saw similar things happening with the decks, that we had stories that were posted later, and we never had a chance to get back to them. Hopefully, we will

Unknown Speaker  26:32  
have a chance to get to them. But they aren't prioritized. I also agree with you that

Unknown Speaker  26:40  
CSV is a powerful tool and can help in special cases, too.

Unknown Speaker  26:51  
To simplify the updates for larger data set or some specific data set, but this is not a tool for everyone, you have to be comfortable with the data set, and be aware of the impact of the changes you are making. So it's definitely more people that would be more comfortable with in app approach. So let's do the inept approach we will not be able to

Unknown Speaker  27:15  
support all fields in in approach, we will do the most commonly requested

Unknown Speaker  27:25  
and then CSV approach will be the way to handle the case when you would like to work with other fields. But this is something on our roadmap, not for an alumna and most likely not for

Unknown Speaker  27:43  
luck, okay, what I would like us to do, which is on our on my list to do we need once we do some work on the inventory, we will start working on some records from circulation and from acquisition then, so we so that we can start the building across Aquarius, but this is something that is starting

Unknown Speaker  28:11  
that we will be starting to talk in market release or later.

Unknown Speaker  28:18  
And the question about the dilemma plans

Unknown Speaker  28:27  
then I will move to the to the feedback that I have received or we have received for from user

Unknown Speaker  28:38  
accidentally user acceptance testing. But before we do this, I have couple of questions for for those who participated and those who did not participate.

Unknown Speaker  28:50  
We got only four responses, which is definitely less that I will I was hoping for I understand that the libraries were going live. There was a holiday people were on vacation and on top of it was also the

Unknown Speaker  29:10  
American Library Association Conference. I think to

Unknown Speaker  29:17  
to respond to the survey was probably half an hour work and I hope for our next

Unknown Speaker  29:29  
you, ATS I will get better

Unknown Speaker  29:34  
feedback. Like more responses. The feedback I got was awesome. People that responded provided a lot of very helpful information. So thank you very much for this. But I have a question to those that reached out to me for the login. I saw they were trying to do the login into the bulk edit. They never responded to survey

Housekeeping

  • Please add your name to the attendees list
  • No meeting July 26th


Development updates

Features planned for Nolana:

  • UXPROD-3705 - Bulk Edit - User data - in app approach
  • UXPROD-3712 - Bulk Edit - in app approach - loan types
  • UXPROD-3704 - Bulk Edit - in app approach - holdings locations
  • Possibly also:  UXPROD-3713 - Bulk Edit - in app approach - item notes

Other features planned but delayed:

Bulk edit will need to address existing dependencies and that will require additional work.

The feature that was deprioritized by MM SIG:

  • UXPROD-3707 - Bulk edit - inventory items - csv approach
UAT feedback reviewFeedback details: https://docs.google.com/document/d/1bH0ZMG2RZte_5Anl8t2-ApcDEUX1AzxzYXn0uUVBq60/edit?usp=sharing


  • No labels