2022-3-8 Bulk Edit Working Group Meeting Notes

• Magda: At our last meeting, which was almost a month ago, I told you we will be doing a workshop today. We are not going to do the workshop today because the environment is not update updated. The engineers tried to do this in bulk edit, they were not able to do it for today.
• Erin: You are talking about the rancher environment?
• Magda: Yes, the bulk edit rancher environment. It is the older version, so you can see some things improved, but you cannot compete with the whole process. The majority of bugs that were on the list are addressed including the titles and the renaming of the files. I can show you quickly in the snapshot environment. I would say it works as expected.
• Magda: The development scrum board, I think it is updated to the new sprint. We are starting to work on Morning Glory. In the works, you will see bulk edit permissions. Those are the bugs that we will be working on in morning glory as well.
• Magda: The Pilot project status. We are not going to include a bulk edit in bugfest. The reason for this is we did not have enough time to test it. And as Jen mentioned in the early stages of our meeting, we all agreed, we don't want an application that is not fully tested.
• Erin: So, that means there is no there's no bulk edit app and Lotus?
• Magda: Yes, that's correct. We will update bulk edit in rancher with the latest code, and this is the environment we will use to complete our user acceptance testing. Then when we have this feedback we will include this in the Morning Glory release.
• Magda: For Morning Glory there are three features that we will be working on.
  • One that I listed here is Bulk Edit - in-app approach - item locations, temporary and permanent
  • Bulk Edit - in-app approach - item statuses, in inventory
  • Bulk Edit performance testing including bugs uncovered.
• Magda: I would like to do a quick walk-through of the functionality that we have done that is visible in snapshot. I would like to show you that the issues that you brought up during our last meeting have been addressed. So, I'll do a quick demo.
• Magda: The first one that was brought up the naming convention of the files. It was using the UUID and now it is the file is human readable, i.e., "matched recrods."
• Magda: (after Magda edited the Patron Group field in the matched records Excel sheet she was able to edit the file name to distinguish it from the original downloaded match file). This was also something that was not available the last time I demoed this.

Magda: (after Magda uploaded the edited match file, the response message now says the file has been uploaded to be more clear what is happening at this stage). This was also a change that was proposed to makes it a little bit more visible that we are just uploading the file here.

• Magda: And this is the warning that we are about to change the records if the Commit Changes button is clicked. Also, the type has been fixed.

• Magda: And then confirmation that the records have been updated. The typo has been fixed as well. And we can see a preview of the changes. 

• Magda: So this is a quick review of what we delivered. It's obviously more than this, there is error handling.

• Magda: I would like us to go to other elements on the agenda for today because I need your feedback on a couple of things before we started doing Morning Glory.
• Magda: First, the developers have changed the order of the elements on the landing page. And I would like to hear what you think about this. The developers proposed we move the drag and drop area below the apps because this will be a more natural flow. You select the apps with the capabilities and then you have the drag and drop area below that.

• Erin: What is the layout in Data Import? Data import and export have the drag and drop at the top the way it is now in bulk edit.

• Erin: A lot of people are going to be in those three apps together. And so having a similar use pattern would be good. I don't know if others have thoughts on this.

• Leeda: Yeah, I agree that it would be better to have the dragon drop at the top for the same reason that Aaron says. I mean, that's going to be the layout that people are used to from data important data export. So why confuse them?

• Kimmie: Magda is it possibly the reason why they suggested this is because depending on which apps you might select what's going to be available in the dropdown of the record Identifiers is different.

• Magda: That's correct. I think they felt that the flow would be easier. You are starting from broad and then narrowing down. You go from the user to identifier to the files drop. But I also think that when you are working on the bulk edit you will most likely stay in one area for a while. So you will not be jumping from users to inventory all the time. So you may be dragging several files from the same area and it may be better to have the drag and drop higher on the list at the top.

• Is it true that those apps are going to be radio buttons?

• Magda: They will be radio buttons in the morning glory. Until we start working on cross-app searches. Thus will be possible once we start working on circulation because circulation will give us the tables that will allow us to link between users and inventory for example.

• Erin: To be clear, there is no circulation app, and there is no acquisitions app.

• Magda: Yeah. When I say circulation, I mean requests, I mean check-in and check-out.

• Erin: Sure. It's just labeled right now as apps with bulk edit capabilities.

• Magda: But if you look at the mock-ups, when we do inventory, inventory will become inventory items. So this is like a placeholder for now.

• Erin: As long as we can revisit that label at some point.

• Magda: If you think it's confusing, we can hide those for now.

• Erin: I'm not confused about having the list of things there. I'm confused with labeling that accordion as apps because there's no circulation app and there's no inventory item app. So maybe it needs to be the type of record or something like that. We don't have to solve that problem today.

• Bob: What happens if you choose the wrong app? You upload a file with user fields trying to match item records.

• Magda: So let's say you selected item barcodes and you submitted a file that has user barcodes. Then those barcodes will not be found. You will have the list of the records that were not found.
• Sara: I wanted to clarify something. So one thing that looks really different to me between the bulk edit screen and the import-export data app is the fact that there's the lozenge at the top which is not present in the other cases. So how does that interact with what we're doing and the placement of the drag and drop versus the other things that need to be set or not set, because that is different than the other two? So when we say we want the drag and drop thing at the top, does that mean above that or below that? And then that's different too.
• Erin: It would be below based on the general UI pattern. What do people think?
• Erin: It feels pretty natural to me to have that placement just cause I do go into inventory a lot and inventory has the lozenges. So that feels pretty normal to me. It's definitely not exactly like data important export, but it's in orders, agreements, and inventory, all the major ones.
• Magda: I would like to table this conversation for now. We can reorder the pane pretty easily in the future if needed. For now, we are agreeing to no changes.
• Magda: I would like us to start talking about the behavior of the action menus because the developers are almost ready to start work on it.
• Magda: So in Lotus, we have Introduced three permissions: edit, view, and delete. The delete doesn't do anything because we have not worked on delete, but edit and view permissions are working. When you open the landing page, you have all permissions: edit and view. You will see under the action menu, one option, which is to start bulk edit because you may have a CSV file already created from prior work.

• Magda: Then once the preview is populated you get additional options, which is to download matched records with CSV.

• Magda: And once all the changes are done, meaning you uploaded the modified file, the upload completed, and you are at the last reporting form showing what records have been modified? You see the option to download records and also download errors if applicable. If there are no errors, that option just won't appear in the menu. This is how it is implemented right now.

• Magda: And I refer to this functionality CSV because we are using the CSV files
• Magda: What we are going to do in Morning Glory is we will have two sets of bulk edit permissions because we would like to separate those behaviors into different streams. In morning glory, we will be implementing the UI-driven or in-app bulk edit. So whatever was delivered in Lotus will be we'll have the extension CSV and every new functionality will carry on us as bulk edit, edit permission, bulk edit view permission, and the delete permission.

• Erin: So, first off, we're not releasing in Lotus, right?
• Magda: What I am saying is the functionality we built so far or the pilot project. So yeah, so, so in morning glory, we would have six permissions
• Erin: So in Morning Glory we would have 6 permissions?
• Magda: Yes because the behavior will be different.
• Erin: Maybe it's the way this is going on the slide, but I'm finding myself really confused by having six permissions that look really similar.
• Magda: So, when we are done with Morning Glory, you will be able to edit some fields in inventory using the in-app approach. And you will be able to edit all user records using the CSV approach. Most likely you will not have an option to edit all fields in item records and you will not have an in-app equivalent for...
• Erin: So if the distinction is CSV versus in-app, then for the three in-app ones then I think it would help to say that.
• Jen: So where it says in-app, is that pertaining to a particular app, or once you turn on bulk edit in-app, you can do it in any app? I'm confused about whether somebody automatically if they get this permission can do it in users and in inventory.
• Erin: Right. We have not gotten to the point of trying to segment it beyond you have access to the app.
• Jen: Once we add a second app, is that when we'll segment it, I just want to make sure that we don't get to the point where we say you can do it everywhere.
• Magda: This is a very, very good point, Jen. Thank you so much. I did not think about this.
• Magda: This is a good point because someone may have permission to edit records in inventory items, but not necessarily in acquisition. Right?
• Erin: Right.
• Jen: Right. That is all my concern was.
• Magda: This is awesome. What should we do then?
• Erin: I think that's a developer question because they need to be able to do that segmenting.
• Magda; But we can work on this. And for the end of Morning Glory, the in-app will be only items. So we can discuss this later. Once we start adding more applications, we can discuss this point. But, I really liked this point.
• Magda: Should the naming contain what app is being covered by the permission?
• Erin: I think it needs to if we're going to expect the ability to segment.
• Magda; So how would you like to name it then?
• Thomas: I was going to ask though, is there any examples where somebody would be allowed to do bulk edits, but would not be allowed to edit individual records?
• Magda: I would say the other way around. Yes, but no.
• Thomas: So would it be possible instead of trying to define all the permissions in here that the permissions for bulk edit just gives you access to this app, but the actual permissions to do the bulk edits are still reliant on other permission settings. So for instance, I would have to have permissions in inventory to be able to edit the records. And bulk edit does nothing except allow access to that app and relies on my permission sets elsewhere.
• Erin: Thomas, you would still need UI permissions in the bulk edit app. Backend, you could maybe leverage the existing permissions, but you would still need to have something that says...Bulk edit can't reference the UI permission for inventory to give you a UI permission to bulk edit. But you can do the backend API permissions. It can pull in something from a module.
• Thomas: If the permissions are stored in the token saying I have access to inventory through the UI and I have permissions to edit in there, can't bulk edit access that permission set through Okai API, or is it just strictly passed on to...
• Erin: My understanding is it has to do with the way that the code references it, but that is an excellent developer question because I think you have a good idea about how to make this simpler and shorter, but I'm not sure.
• Sarah: And this raises an interesting point because in, so I discovered in our current system, since I'm part of the five colleges and currently in our current system, we do like, um, without being granted the definite the specific permissions, I cannot edit a big record, an item record, or a holdings record currently, uh, by one of the other institutions.

Right. Unless I have kind of like, if like, with like an acquisitions and folio we have now these acquisitions groups, they had to actually develop that for the pod colleges. Right. So again, going back to. So that we could assign each other, um, acquisition units. Yeah. Yes. And so this would, could come up for us, but going back to the, the question is, so I cannot, in my current system edit those records, but I can use batch services in our system to get around that if I need to.

So I can actually

actually, but anyways, but, but, but my point is in folio, I think, I think it was Thomas just now I forget who was speaking, sorry. Yeah. Was raising a really good point. Can it be that. It's not looking at what my permissions are elsewhere, about what records I can touch them when I can't touch. Would it, could it be that then suddenly with the bulk edit ability, I could potentially edit something that I wasn't supposed to admit.

Right. Or like, you know, that it would contradict other permissions that were set up where it was limiting me, you know? Cause I'm, I'm just thinking about building this out, right? Like around users, right. We're all in folio together. Now what happens if I make some kind of query, there are UMass people in my query and then suddenly I edit them because I'm dealing with thousands of records.

It's not like I'm looking at one by one by one. Right. But normally I wouldn't be able to edit that, that user. Yeah, I don't, I mean, I'm not in folio yet to no concrete examples, but I could think of running into problems like this in, um, if it's not referencing what my service point is or what my, my unit is, or my team, we, you know, for awhile there were going to be teams and things like this.

I think we do need to have some kind of,

especially as this gets built out, scaled up to include other apps. My concern, my understanding of the commission was in buckets. Uh, but this obviously can change that. Uh, once we grant you permission to the bulk edits, uh, you can, uh, you can. Do the bulk edit on the record. So it is overwriting, uh, your permissions, but, um, we did permissions that I had on my screen right now, um, that I wanted to discuss.

There were another simplistic. Those are, those were the permissions that will the timing, what you will see in the action menu, depending on the permissions you have. So we are not even getting to the point where, um, we are not getting to the point. We are writing the changes to the database. We are discussing what the user can actually see in the UI to the, to the action menu.

Doesn't make sense. Do I confuse you even more? No, that, that makes sense to me. We're just, these permissions are just going to be, if you can see the bulk edit app, as well as what options within the bulk add app, you can see, but not what actions will actually be successful in the bulk of it.

So you'll get an error message. If you try to bulk edit, um, in an area, if a system you don't have permission. That's that you, that would be one of the error stating

yes, we had, at some point to this, I could easily recreate it in the snapshots environment. Uh, this was, uh, something could be a user records that then when I was trying to update, I was getting care. There was not really very user-friendly you had to, um, scroll down right. To the, to the right, to see what was really the problem.

But it was sexually stating that you cannot edit this record because it's so, so. Going back to, uh, to the permissions that I have right now that the drive, the UI behavior. And we definitely will come back to these, the conversation about, um, what should the permissions, um, the,

to summarize what we said, first of all, you don't want the word permission. You would refer to her in op, uh, right in front of it. And I would leave the items for now out of it and leave it as an edit view and they'd eat red cards. And then when we start talking about the permissions on world records can be edited.

We will come back to this. Would that make sense for you? Would you agree? Yeah, I would want to be consistent across the.

Uh, so this would be CSV.

This will be,

is this acceptable? And the records that could come out, delete records.

So, uh, we had five minutes. I would like to walk to the scenario where the in up, uh, up in up permissions are enabled. So on the landing page, the inventory items are selected. And at this point you can all do anything. Uh, action menu is still not visible until the preview is populated. No, we have a preview populated and the action menu has options.

Download much records and you can still download them in CSV. You can download errors also in CSV and you can start bulk edit, but the behavior of the staff bug edit will be different. It will be in up, but this w we will come back to this later. Um, probably not today though, because of the time constraints, but a user is taken to in app, uh, edit, commits the changes.

And this is the landing page. Again, after all the records have been successfully completed. And then what should the action menu, uh, contain here? Save change records and save errors. What else should be here?

We currently in the CSV approach, we have a

thinking CSV approach.

Um,

we, uh, we are, uh, having, uh, we are going to have a start bucketed, but this is because we can upload the file. And in app, we don't have the file to upload. We need to go to the,

and we need to go to the, uh, to the, in up. Application that we can go only if we know what records we are going to be editing

a stupid question and sorry, but, um, even with the in-app can I, uh, can I get the, can I save the record and downloaded prior to committing to yes. So if, if, if we go quickly to, uh, how it works. So this is, uh, we are providing item barcodes. You're uploading the file. So the behavior is until now the same as we already implemented.

This is still the same behavior. Now you're clicking start. And this is the first change. So you, you have this places where you specify what changes you want to do. This is the in-app part. And then, oops. So this is what I want it to be. So this is the moment before you will be, want me to make it larger.

Can you see it a little bit larger or you can just read yet. Oh, super. So what is happening right here before you commit your changes? You are in the, in there you are sure. Are you sure? Which states how many records you will be changing. This is again review, but you have this option, download preview. You can download the files and see them.

Those are, you will see how the records will be updated once you commit the changes.

Uh, yes, that's great. That's really super. Um, I still like the, what you were asking before that to have the option afterwards to download my errors. And so when you get to this screen, so you update it, you make the changes. So right now you can upload, download the list of the records that were modified and also the errors.

Okay. And I apologize. I need to run to another meeting so I can stay much longer. Thank you very much. This was again, another very good discussion and we didn't cover all the elements, but we have something to look forward for our next meeting. Thank you very much. Thank you. Bye bye.