Page Comparison

• Magda:  Let's start with the standard development status. This is the FOLIO snapshot. We did some progress on the in-app approach. I am logged as a user with both permissions for the CSV approach and for the in-app approach. The user behavior has not changed. So let's concentrate on the in-app approach and the changes we have made so far.

• Magda: The user selects in-app (by selecting the "Inventory - Items" radio button).

•  Magda: The dropdown menu is populated with the items-related values. So let's select the item barcodes.

• Magda: Choose the file to upload. And I will take item barcodes from my list of files.

• Magda: It populated the screen with the items that meet the search criteria.

• Magda: We can add or remove columns. And we can start to bulk edit.

• Magda: As I mentioned, because I have two permissions, both CSV and in-app, I see these two options.

• Magda: So I am starting bulk edit in-app.
• Magda: Here are on the screen where we choose the options., one option, is permanent location, we have two action options, replace with and clear field.

• Magda: If we select replace with, we are picking the location using the location lookup and then save and close.

• Magda: We can also add another option, which will be a temporary location, and we can clear the field. So whatever is in the temporary location will be cleared.

• Magda: We, do you have any questions so far comments?
• Erin: It would be nice if the location could also have the inventory type of ahead modal in addition to the drop-down modal. People may find that that is easier, especially if they have just a few locations, so they don't need to like go hunting and, or maybe they know exactly what the location is called and they can just type it.
• Sara: The only problem is, fo us at the five colleges that is not, you know, if we have a dropdown, then that dropped down becomes ...
• Erin: I'm not saying remove it. I'm saying have both options.
• Sara: Okay, good. That would be very helpful.
• Magda: I will write a story for this. I'm not sure we can deliver it for Morning Glory. I will need to talk to developers about how much work it would take.
• Magda: Um, I have another question related to this, but I want to go through the whole process and then we will return to this screen.
• Magda: Okay. So we are confirming the changes and we get the response that 2 records will be changed if you saved them. Before we do the save, we do the download preview.
  • Erin: So the previous says, there are no items. Is that a bug?
  • Magda: This is a bug. You will see a list here. Actually this story, the form "are you sure?" is still in progress, so it is not committed. So it's a work in progress.

• Magda: So when we look at the preview, this is the preview of the changes. This will show you how the records will look like after we make the changes, the changes are not committed yet.

• So as you see here, effective location and temporary location, this is before the changes are committed in the database. If you click cancel at this moment, you don't want to proceed, no changes will happen. But if you continue, you see that all the records will have main library and they will have no temporary location. And it will obviously affect the effective location. If I click keep editing, it will take me back to the screen and no changes were commuted.

• It shows that 2 records have been successfully changed. The error and reason for are displayed. I will need to investigate why we got this error, but at least we know we were not able to update this record. And also on the action menu, you can download the errors.

• Sara: I was just wondering would something not being able to be changed constitute an error? And how will that be counted? Because you have this interesting count thing going on. Let's say I have three records, in the meantime, somebody went in and manually already changed one to not temporary. And, so I'm asking all three to become temporary, to have everything be changed to their permanent location. But it can't actually affect the change on the one that was changed in the interim.
• Magda: It will overwrite the change. So let's say you have your list of identifiers, your scan the records and you are doing the bulk edit and you got distracted and do not proceed. In the meantime, someone goes and changes the records. Then you come back and you continue with your bulk edit. You're overwriting the change. Please note that this is the in-app approach. So it is not that you can upload the CSV file and you can start over. Those are the changes you are specifying in the UI.
• Sara: So I guess it still seemed though that I had this file that had three things.
• Magda: This is, this is just for your preview. In the in-app approach, you don't upload the file to trigger the update. The preview is only so you can see how the records will look before you commit the changes.
• Okay. Is it clear, Sara? If it's not clear, please ask more questions.
• Erin: What you will get from an error is you will get like what an API would return, which would be like what you would get if a pop-up showed up or something like that, as opposed to something where you might have over overwritten something or something like that, you're going to get an API message.
• Lloyd: Sarah's question made me wonder how is this is interacting with optimistic locking?
• Magda: Inventory obviously uses the optimistic locking. But what you have to keep in mind is you will be updating the latest version of the record. The bulk editor at this point, in the in-app application, does not have a snapshot of the data that was taken when you started the bulk edit process. So for this, I would like you to forget about the CSV approach. There is no CSV approach at this point for item records.
• Erin: So you pull the records, show me the preview, but you are not in any sort of edit function. It's just giving you the fields. And then when you do the actual bulk edit, it's gonna Repull the record and apply the changes?
• Thomas: In both app versions, couldn't you store the version number of the record that is supposed to be edited and check that before you do the bulk update? There's probably a locking magnetism with a version number. So the version of the number incremented by one, it would mean that there was a change in between.
• Magda: Let me walk again through the process and maybe this will clarify (At this point Magda had to restart FOLIO and then when she ran the file no records were updated due to errors. The main point here was that when there are errors reported from the app, no changes will happen to the records in FOLIO when the you save and close/commit).
• Magda: The question you had about storing versions and updating the version at this point in the in-app approach, you don't have a version of the, of the records. You don't know what you are changing. What we see this is the given moment. When you run the update. Why would you like to know what is version of the record you are updating? What would the use case for this.
• Thomas: I was thinking of a safety precaution. I understand that no changes have been staged yet. And until you hit that final screen where you have the option of downloading the Excel file, at that point, you have staged changes. They're not committed yet. They're staged. And the window between that, and when they're actually committed is very small. But there is still a chance someone else could go in and change a file between those steps, even though it was a very small time period. And my suggestion is that when you do start those that when you do that staging process if you store the version number of the current state and then when you commit the record, you could match them up to ensure that there were no changes in between those two steps. It is more like a safety net. I think it would be a good approach for both this, as well as the CVS approach, to catch changes to inventory between when you make that staging file and that commit file.
• Erin: And in all fairness, too, we have not uploaded 10,000 records, 15,000 records. So I do think. Until we know more about performance.
• Leesa: I was about to say the same thing, Erin, that window might not be small. You may decide what you're going to change. And like you said, it's 10,000 records. And depending upon how how fast that runs and what it might affect running and circulation or cataloging or somewhere you might choose to wait and run that overnight or later in the day.
• Magda: So I think when we are talking about items, and thousands of items, probably this will not be going into hours, but we'll see, we don't have the performance test for items conducted just yet only for users. But, tens of thousand shouldn't be that long, but if you go into hundreds of thousands, then we are adding time. I made a note for the version control. That definitely will be important once we start working on the CSV approach for item records. But, the CSV approach for item records will not be a part of Morning Glory, most likely. So I will come back with more questions.
• Erin: Jen is pointing out in the chat that data import doesn't have a safety mechanism right now. So it's not like bulk edit is not doing something that data import does.
• Magda: The difference is we are a new applications. So we we can be more agile and we can adjust accordingly.
• Sara: So again, so I get the in-app part. In my current system, I can do a query. It creates a file. It sits on my computer. I haven't downloaded anything. If it's an especially large one, I might not run it right at that moment, but on my schedule, I can prep it. Now I'm going to run it at 7:00 PM when I know things are slower or something. So, there's a window there of time where things can change. And so I guess my question before was more about going back to how it was nicely saying I've updated two records, there's an error. And so the third one wasn't updated. I was just trying to get a handle on what constitutes an error. What is and is not counted, so that the output can then be evaluated by me. So I was asking if it finds that in the interim, the change that I was trying to do on an item had already been handled, would it count that as an error? How does that counted? Because it's not affecting a change on that item because it's not finding anything to change.
• Magda: Sarah to make sure I understand your question. You run the bulk edit and then you encounter the error recorded in the errors part in the results. Then you correct the record so that the error will not occur anymore. And you are running again.
• Sara: No.
• Magda: I'm sorry. Let's say I do a query for everything that has a permanent location poetry room, and I do this at 11:00 AM. And so I get three things, let's say, for example. So I want to change it so that they're no longer a temporary location of poetry room, they should just go back to what they were. But some time lapses for whatever reason. And so I don't run it. And in the meantime, somebody has come in and and changed one item manually taking the temporary location off the record, which is fine. And so now two can be changed by the bulk edit. And the third one can't be changed because there's nothing to change.
• Bob: You can. It will just wipe out what's there, which is nothing.
• Sara: It will wipe out nothing with nothing?
• Madga/Bob: Yes.
• Sara: Okay.
• Sara: So I was just trying to ask whether nothing with nothing is an error?
• Magda: No.
• Bob: It doesn't have any way of knowing what the state was before.
• Erin: It would only ever be an error if a field was required and you tried to erase it. That would return an API error and you would see that message.
• Bob: I think if we had what Thomas was suggesting, then it would know that there had been a change and there would be an error. But, since it is not recording the state that it was in, it's just at the moment you click run, making the changes that you have asked for, regardless of what state was before or not. It's not keeping track, right. Magna?
• Magda: Yes, that's correct.
• Magda: So did I answer all questions? I have a couple of questions regarding locations because as you saw on the bulk edit screen, I can set the action for permanent location and temporary location to clear the field. Nothing prevents me from doing it. Is this desired behavior, or would you like to have some limitations on this?

• Thomas: This is only changing the locations on the item record. So the holding records would still have a permanent and temporary location?
• Magda: if it was populated before. But if you, for example, remove all the locations being stored on the item level item, and you don't have anything in the holdings...
• Erin: Holding will always have a permanent location that is a required field.
• Magda: Okay, then. Perfect. Thank you.
• Thomas: Then, if that is the case, I don't have an issue with clearing the permanent and temporary location off the item field since the holding record will always have a permanent location, there will always be an effective location.
• Erin: I think there are , there are definite definitely use cases for being able to clear both.
• Magda: Awesome. Okay, great. Thank you. Because this was my concern that we , uh, we may be a little bit too aggressive in this.

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.

• Bob: Sorry to interrupt your flow. I just have a quick question

• about the UI behavior. If you choose to change the permanent location,

• 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

• something from the dropdown

• the second line would not present that as an option

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.

• .
• Erin: 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.

• Bob: I don't think I can think of a reason why you would have it twice. Right?
• Erin: I'm specifically talking about location. There may be because location is a pretty simplistic field.

• You know

• we're not talking about something that's storing an array of values or things like that.
• Bob: 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.
• Magda: You are absolutely right. Uh, I'll add to the story for this as well.

• Thomas: 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

• selected action. And if

• nothing is selected, then nothing has done.
• Magda: Can you repeat?

• Because

• I think I missed it.
• Thomas: Can you, instead of having the options as dropdowns static options,

• have permanent locate item, location, temporary location, but then have the

• action dropdowns have a default to select action. And

• 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.

• Erin: I think that might be a little bit more confusing. I don't know, other people should chime in, but I

• think that what I like about this is that the UI looks like other UI options in

• FOLIO. Think about for example 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

• drop-down.
• Magda: 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

• the Morning Gory release, we will have permanent location, temporary location, and status, those three fields

• . And the list will

• grow

• as the application matures.

• Magda: The next question is, we talk about that at some point, about new bulk

• button, a button to add on the CSV

• approach.

• This was when we talk about the users records. And I have a question about visibility of this button and also how

• it should work in

• the in

• -app approach?
• Magda: So when we are on this screen on the bulk edit, we start

• and we have the preview populated. I would like to have

• the new

• bulk edit button

• still visible here

• .

Image Added

• Magda: This would simplify providing the

• select a new file and reset the screen very easily.

• Do you have a problem with this approach?

Image Added

• Erin: Can you walk through it again.
• Magda: Okay. So,

• in this

• mock-up that we discussed, this was discussed for the CSV approach

• , you completed the

• bulk edit

• for one group of records. And now you want to do another

• bulk edit.

• So to reset the form easily, to go back and start clean, you click the new bulk edit button and you

• reset the record identifiers, reset the notification screens,

• reset the errors, etc. You just wipe

• the app

• clean.

• The question

• I have is if this would be also expected behavior for the in-app approach

• ? So you would

• see this

• at the beginning

• . Right now you selected the records and now you

• decide, okay, this is not the data set

• I would like to work on. You click the new bulk edit button

• and you have an option to upload another file.

Image Added

• Sara: I think

• that is good.

• Making sure that you're starting from a clean slate

• to be sure 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.
• Magda: Okay, great. Thank you. This is what I wanted to hear. I just wanted to make sure we're all on the same page.
• Bob: I have a question.

• Would people be more expecting

• to just go up to the actions and start over from there

• ?
• Erin: No. Because at least on the RA side

• end session as its own button in various places. So I think we would expect a button like

• this.

Image Removed