Attendees (please add your name):
Magda Zacharska Donald Depoorter Jennifer Eustis leeda.adkins@duke.edu (OLD ACCOUNT) Erin Nettifee Christine Tobias Amanda Ros Jackie Magagnosc Monica Arnold Sara Colglazier Jenn Colt Kimie Kester Jeanette Kalchik Lloyd Chittenden Robert Scheier
Note taker:
Meeting Recording:
- Recording and chat: https://recordings.openlibraryfoundation.org/folio/bulk-edit-working-group
Discussion:
Topic | Notes |
---|---|
Housekeeping |
|
Expected behavior for clearing values from permanent and temporary location. Should this be allowed? |
Uh, the other question that I have, um, I'm sorry, I'm just, uh, I keep missing, uh, going away from our agenda. Let's just say, Rob has his hand up to, oh, go ahead. Sorry. Sorry to interrupt your flow. I just a quick question. Not that I'm not a big question, but about the UI behavior, if you, um, choose, uh, to change the permanent location, and then you went down to the next line. When you went to choose temporary location, you could still see permanent location. Is that something that could be updated when you choose a low, uh, something from the dropdown. The second line would not present that as an option in the temporary, in the left side. Uh, hold on. If we are here in replay independent location, we are selecting it to, um, we don't have luck with duke, so let's, uh, go to something else. And from what you're saying, we select it here. Uh, it's even close and let's get back at, let's remove this. So we are here and then when we add the next one, You don't want this to be permanent, you would like, because the only option would be the temporary location here. Right? I think the assumption Bob is making, which I think is probably true, but people should jump in if it's not. Is that when you're doing this kind of work, you would only make one change on each field. Well, unless it has multiple, you know, in certain cases, I guess. Yeah. I don't think I can think of a reason why you would have it twice. Right? I'm specifically talking about location. There may be because location is a pretty simplistic field. Um, you know, we're not talking about something that's storing an array of values or things like that. I mean, it's not a huge thing, but it just jumped out to me. And I saw that again, you know, we've already chosen it. You are absolutely right. Uh, I'll add to the story for this as well. Um, I'm taking notes. Um, would it make more sense or make it easier instead of having a dropdown box where you choose permanent item, location, and temporary type item location, they're just static. And then the action could be select action. And if dolphin is selected, then nothing has done. Can you repeat? Because, uh, I think I missed it. Can you, instead of having the options as dropdowns static options, so have permanent locate item, location, temporary location, but then have the auction dropdowns have a default to select action. And if, if it stays on select action, it just doesn't do anything. So you don't have to worry about disabling an option, whichever one they choose. It's just static cases across. Okay. I don't know other people should chime in, but I, the thing that I like about this is that the UI looks like other UI options in folio. So I don't know that we have another field. I mean like, think about like an electronic URL on an inventory record. Like, it looks like this, like you choose the value, you choose the thing, right? You just go drop down by dropdown. I do believe this is the reason that we went this route to make it consistent. The list will obviously grow as we are. So by the end of morning, glory for morning blood release, we will have permanent location, temporary location status, those three fields, and the list will grow, grow, grow. As we, as the application matures. Okay. Oh, sorry. I'll put my hand down. So, uh, let me, I have this control here and, uh, going down the agenda. So we covered the expected behavior from, uh, from, um, uh, wiping out permanent and temporary location. And you agree that this is, uh, supported and this is supported the functionality. The next question is we talk about that at some point about new bulk, edit a button, a button to add on the CSV, uh, approach. This was when we talk about the users records. And I have a question about visibility of this button and also how does shoot work in for the in, in approach? So when we are on this screen on the bulk edit, we start, uh, here we, we have the preview populated. I would like to have this, uh, starting a new, the new bug, edit button, still visible here, because this would simplify providing the list of the new, um, uh, in your file to enable this will reset the screen very easily. Do you have problem with this approach? I see heads moving. I don't care anything. We'll say it again. Like I guess I do walk through it again. Okay. So, um, in this, uh, mock-up that we discussed, this was discussed for the CSV approach for you completed the, um, the bulk edit and, uh, of one group of records. And now you want to do another, um, bulk edit. So to reset the form easily, to go back and start clean, you click the new bulk edit button and you go, you know, you, you, it reset. The record identifier, it resets the notification screens, it's resets errors and produce, et cetera. You just wipe, uh, the app. Um, clean. My question that I have is if this would be also expected behavior for the in-app approach. So you would, you would see this on the beginning of the, uh, like right now you selected the records you decided, okay, this is not the data set. I would like to work. You click the button in your bucket and you have an option to upload another. I think someone said, no, I heard something. No. I said, I think that is good. Um, I think what, making sure that you're starting from a clean slate is really exactly that you don't introduce any pre settings. So that's often in many of the other apps, even if you do reset all, some things are sticky. And so I think for bulk edit, it's really important that the slate is clean and you don't do some kind of edit that you didn't intend. Okay, great. Thank you. This is what I wanted to hear. I just wanted to make sure we're all on the same page. I have a question. Um, I just a question. Um, would it be people be more expecting this? Just go up to the actions and start over from there. No, no. Cause at least, well, at least on the RA side and session as its own button in various places. So I think we would expect a button like, like has been designed. Sounds good. Thank you. Um, the next part on our agenda is, uh, performance tests. Um, we conducted the performance tests for the users only at the, uh, the feature for bug edit performance. And let me make this bigger as well. Um, we'll include established performance for. Item locations and item, item, statuses. However, this is not implemented yet. That's why it's blocked. Um, uh, we, we will be working on this, um, slightly later, but I would like to walk you through the, uh, quickly through the, uh, results of the performance test and, uh, how we approach that. It's a lot of technical information and I added the link to agenda. If you want to spend some of your time looking at this, but it's rather a self exploratory, what we have done. So we, we run three, basically three tests, one, uh, we tested results of updating 10 records of users. So one user updates, 10 user records. And does. One, um, uh, per sec, one requests, a cent per second, and it's repeated 100 times. So, um, those times that are, uh, recorded here are in milliseconds. Um, uh, I was surprised to see that the logging took as much time almost, uh, as the, uh, getting the link to download the much records. So this keeping in mind, this is for the CSV approach. This is for the users records the next, uh, um, the next type of tests where we had again, one user updating 100 records of user data. And then it was done during one second and repeat it 100 times. And obviously the, the, the time, um, it's, um, growing up when we are, uh, more, but I think the performance is still pretty good. And the last one was that we tested the same, a one user updating a thousand records at once. And does it, uh, well, uh, one per second and does it 100 times. So, um, For this amount of data, we did not encounter any problems when we were submitting the list of identifiers, the problems where once we, uh, around the query, this was the, this is the, uh, sorry, this is what we want here. Let's see. And, um, so this is the query that was executed. Oh, this type of query was executed. And then, um, Uh, we, we got the air due to the performance of the query for now. We just don't do anything. Um, we will be addressing it. Uh, sometime later if you scroll down, I think there should be a link to the, there was a link I will pass the link in our chat to the examples, uh, of the query. And he a user identifiers that we use in our tests. Do you have any questions? Um, well they also provide some data on the overall system impact. That's what we see with data import. Like it may run quickly, but it uses a great deal of energy from the system. So I think with the users, the impact will not be that bad, but for the inventory. That the impact of the bulk edit will definitely be, um, affecting, uh, other permissions other areas. I will keep it in mind. Well, once we start, once we start working on the, once we start working on the performance for, for inventory, but I will ask the developers to double check the impact of the bulk of users on the system. Yeah. I would mainly check also a check-in check-out because the wires, the user data quite a bit. So I could see if it was a lot of records being updated, can still those to them. Micah also just, uh, with all this talk, I've just had another thought. So in our current system, when, um, Bulk editing is done in, let's say that's my primary experience. So, um, certain, um, so it could be that in our system, uh, kind of data import and bulk editing kind of happens within the same module. And, um, and that might be different in folio. And you could just say that and then I'll stop. Um, but if not because records are being impacted, right? Like it affected it simultaneously potentially. Um, So, so we're going with this, sorry, is that like, I can set up a big task that, uh, for many, many, many records, and then there are other jobs, um, that have higher priority and they can interrupt mostly you end up with a queue, but can, it may interrupt. They're allowed to interrupt ma to do their thing. And then once that is done, mine resumed. And so a, this again, could happen that there's a delay right. In starting something and finishing, but also overall system impact. Yeah. And that's what you're talking about here. We'll will we, will that be a possibility in folio two? And do we have to somehow allow already for that or account for that? So you are asking if we can queue, if we can cue the jobs. So for example, if you have, uh, we, if you are importing the data, uh, at a given moment, and then someone else does the bulk edit and both of them are taking a lot of resources. So you would like to the import complete first, before we start doing the bulk edit, right? This is for example, yes. Or it could be other types of things. Yes. Uh, what other type of things do you have in life? Well, because of it, because it's also impacting inventory. For example, you have pulse flips, um, that certainly run right to go and fetch things off the shelves, right there also querying this basically the same underlying data that they are, et cetera. Right. So those, I think come into, I think they can run sooner. And then, and then I'm mostly just thinking, because because of the five colleges, you know, I might start something UMass might start something, start something, and we're basically all. Utilizing the same resources. And this is also an example of something that we see, oh, APM H affects when you do the harvesting. You're getting the data from inventory from SRS and it takes a lot of resources. So it impacts all the system. And especially if you do the full harvest, you should be doing it outside the regular, um, uh, hours because of its impact. And I, I see that what you are getting, uh, here, um, Sarah, I will need to run it by the developers and by the architects, uh, how this is being handled, because obviously we don't want to clog the system, um, with the, uh, Yeah, let, let me talk to them and I will get back to you on our next meeting, how we are going to handle that. This is definitely a part of the performance, um, investigating and, uh, addressing performance issues. This was very good point. And also just going back to, uh, just now with locations, um, And then you, uh, brought up the harvest thing of the acronym that I can just never get straight when peeing, whatever it is. I don't know why. I cannot say that one, lucky that you don't need to learn it by heart. Um, so I know it wasn't in our current system that, uh, so our, our discover layer, um, and I might be using the wrong words here. Right? So we call it our tack, how it displays, where something is located in the, in the discover layer. And that also depending there can be like a slight delay there. So I'm also not quite sure what the, you know, what kind of resources are utilized there or the timing. W what the delay is or something again, you know, performance wise, something to, from what I know about archaic, Arctic has also a module on the, on the folio side, it's more Arctic or edge ARPAC I don't remember. And I also am not fully familiar what this acronym stands for. I only know that the R stands for real time. So it means that it is actually queering the database for the location. So it, your, uh, discover layer since requests to, um, sense some request to the, uh, Inventory for your inventory and gets the information, uh, from inventory about the location of the item. So once you do update the inventory, the, the location item, location, artwork, we'll get the updated information in real time. So if you request before the update happens, you will get the old location. And then after it will get the, the new one, we are running out of time. And I was hoping I will be able to do walk through of the, uh, um, user acceptance testing. We most likely won't have time for this. I will put this in the slack channel. Um, this relates to the, um, Um, to the usability and the user or user acceptance testing for CSV approach, the environment was totally reset from what we had discussed on the beginning. And unfortunately, the setting, the users that we set up in the fall, uh, with the, the passwords are probably not there anymore. I have created a user for, uh, for us to test and they will also provide a sample of the different IDs. So you don't need to, uh, look for the files. You are more than welcome to do them, but in case you don't want to spend time on selecting IDs, uh, you can use, uh, you will be able to use the files. Uh, as I mentioned, I will pass this in that slack channel. And if possible, if you can do the, um, uh, eh, user acceptance testing for user records for CSV approach, uh, this week, that would be awesome. And if something in my, uh, instruction will be unclear, please feel free to reach out to me for clarification. Thank you. Thank you all for your feedback and great conversation. And I'll see you in two weeks. Bye bye. |
Development updates | |
Expected behavior for in-app approach for the "New bulk edit" button | |
Performance tests - user records | |
UAT- walk through: |