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 for the pilot project.
• 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 our current system, since I'm part of the five colleges, without being granted the specific permissions, I cannot edit a bib, item, or holdings record of the other institutions, but I can use batch services in our system to get around that if I need to. And so this would be an issue for us. But my point is that in folio could it be that suddenly with bulk edit ability, I could potentially edit something that I wasn't supposed to? We're all in folio together. What happens if I run a query where I pull in UMass people 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. I could think of running into problems like this if it's not referencing what my service point is or what my unit or team is.
• Magda: My understanding of permissions in bulk edit, but this obviously can change, is once we grant you permission to the bulk edit, you can bulk edit any record type. So it is overwriting your permissions. But the permissions that I had on my screen right now that I wanted to discuss. They are rather simplistic. Those are permissions that will determine what you will see in the action menu, depending on the permissions you have. So we are not even getting to the point where we are writing the changes to the database. We are discussing what the user can actually see in the UI on the action menu. Doesn't make sense or am I confusing you even more?
• Thomas: No, that, that makes sense to me. These permissions are just going to determine if you can see the bulk edit app, as well as what options within the bulk edit app you can see, but not what actions will actually be successful in the bulk.
• Bob: So you'll get an error message if you try to bulk edit in an area of the system you don't have permission for?
• Magda: That would be one of the errors.
• Magda: Going back to the permissions that I have right now that drive the UI behavior, we will definitely come back to this conversation about what should the permissions do. But to summarize:
  • Magda: You don't want the word permission.
  • Magda: You would prefer to have it in-app in front of it.
  • Magda: And I will leave the items out of it for now but leave edit, view, and delete records.
  • Magda: And once we start talking about the permissions on what records can be edited we will come back to this.
• Magda: Does this make sense for you? Would you agree?
• Bob: Yes (not other objections). But, I would want to be consistent across all the permission names.
• After the discussion this list was the result:
  • Bulk Edit: CSV - Edit 
  • Bulk Edit: CSV - View 
  • Bulk Edit: CSV - Delete 
  • Bulk Edit: In-app- Edit 
  • Bulk Edit: In-app - View
  • Bulk Edit: In-app - Delete

• Magda: We had five minutes. I would like to walk to the scenario where the in-app permissions are enabled.
• Magda: So on the landing page, the inventory items are selected. And at this point, you cannot do anything. The action menu is still not visible until the preview is populated.
• Magda: Now, we have a preview populated and the action menu has options.
  • Magda: Download matched records and you can still download them in CSV.
  • Magda: You can download errors also in CSV.
  • Magda: And you can start bulk edit.
  • Magda: But the behavior of the start bulk edit will be different. It will be in-app, but we will come back to this later. Probably not today though, because of the time constraints.