Versions Compared

Old Version 19

changes.mady.by.user Robert Scheier

Saved on

compared with

New Version Current

changes.mady.by.user Donald Depoorter

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Attendees (please add your name):

Magda Zacharska leeda.adkins@duke.edu (OLD ACCOUNT) Erin Nettifee Christine Tobias Amanda Ros Erin Weller gongd@msu.edu Jackie Magagnosc Monica Arnold Scott Perry Kimie Kester Sara Colglazier Robert Scheier Donald Depoorter 

Note taker:

Robert Scheier

...

, . is permissions didn't work on the delete are opening on the the all form reporting. What is, uh, of CSV, and if there are errors. Okay. So that option, if Exactly. It's not available. Okay. So this

Image Removed

You are getting additional option, which is download a March to records with CSV. And once all the changes are done, meaning you uploaded the modified file, the upload completed, and you are all the last form reporting.

What is, uh, what records have been modified? You see the option of download records and CSV, and also download errors if applicable, if there are errors. Okay. So that option, if there are no errors, that option just won't appear in the menu. Exactly. It's not available. Okay. So this is how it is implemented right now.

And I refer to this functionality CSV because we are using the, um, the CSV files.

Uh, this is, uh, this, uh, it's sort of a repeat of the. Yeah, that makes sense to me. And that's the same, that's similar to how other apps treat sort of references to things. So what we are going to do in morning glory in morning, Gloria, we will have two sets of bulk edit permissions because we would like to separate those behaviors, um, into different streams.

In morning glory, we will be implementing the, um, a UI driven or in app a bug edit. So whatever was delivered in lottos, will it be, uh, we'll have extension CSD and every new functionality will carry on us. A bulk edit permission, bulk edit view permission, and the permission. W w I'm not sure I understand that.

So, and so we're going from first off, we're not releasing and Lotus, right. Um, when I'm still in a saying about the functionality we built so far, the pilot project or the pilot project. So yeah, so, so in morning glory, we would have six permissions

that I don't understand why are we? Because, because the behavior will be different. Okay. I think for, well, first off it would help me if we didn't have permissions in the name, because we don't really do that in the, in the naming bunker. Did the edit bucket that you bucket it delete, this is what you would prefer.

Well, so, um, It's I, I guess, I don't know, but I'm 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 and I'm not, and it's not clear to me why I would assign somebody full edit, edit CSB versus bulk, edit, edit all or whatever that ended up being called.

I thought the reason was that the CSV was much more powerful in terms of what, what damage it can do except. So, uh, when we are done with morning glory, you will be able to, uh, edit some fields in inventory. You're using the. And you will be able to edit all user records using CSV approach by the end of morning glory.

Most likely you will not have an option to edit all fields in. I tem. Right.

So if the distinction is CSV versus in-app, then for the the three and a half ones, I think it would help to say that right. Bulk edit colon in app at full or, cause I assume it's also not clear to me. It's it's bulk edit, delete records. Is that what we're saying there? Like you can do it, you can, through the in-app workflow, you can delete records.

So maybe even we can flip that. We can say bulk edit colon in app dash, edit records, full, get it. Colon in-app dash, you records. And then the, then the other ones you could, you could flip it and say bulk edits, CSV. And it records both at CS. I think that would be a clearer. Delineation of what we're actually trying to do.

And I can, I can put that in the slack channel if that would, if that would help. But I think that's, that would make it clear to me what each of these does.

Uh, someone wanted to say something just going to ask, so where it says an app, is that pertaining to a particular app, or once you turn on bulk edit in app, you can do it in any app. Uh, so with enough, this is what we need to build and we will start writing, build it for the item records. So when we turn up it enough, it will be only for inventory item records, but in app, um, let me, let me.

As opposed to the extract transform load spreadsheet. I'm not confused about that. I'm confused about whether somebody automatically, if they get this permission can do it and users and an inventory. Right. We have not gotten to the point of trying to segment it beyond you have access to the app.

Therefore you can, no. Once we add a second app, is that when we'll segment it, I just want to make sure that

this is a very, very good. Thank you so much. I did not think about this. So you would like to, uh, separate like, um, bulk edit in up item items.

So, uh, This is a good bond because you, it, someone may have a permission to edit records in inventory items, but not necessarily in, in acquisition. Right.

So, uh, what should we do to make it Christina's had her hand up for a little bit. Go ahead, Christie. Oh, thanks. I think that my question's been answered because my question was, are we giving permission to edit permissions or permission to edit the records, but you have clarified that through your discussion that it's a bulk edit, edit records, view records, delete records, right?

It's not actually granting, it's not, uh, permitting to.

Okay. Got it. Thank you. Yeah. So, um, how do we handle this?

Right. And I think that's a developer question too, because they need to be able to do that segment. Yes. But we can work on this. And for the end of morning glory, the in app will be all the items. So we can discuss this later. Once we start adding more application, more apps, but I really liked this point.

Should do we should the naming company. Um, well up is being, uh, edit, uh, covered by the permission or not. And if I think it needs to, if we're going to expect the ability to set that. So how would you like to name it then? I was going to ask though, I mean, do, is there any examples where somebody would be allowed to do bulk edits, but would not be allowed to edit individual record?

I would say the other way around. Yes, but no. 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 to inventory and to be able to edit, to record.

And bulk edit does nothing except allows me access to that app and relies on my permission sets elsewhere. Cause I'm afraid like if you right 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 cause cause bulk edit book, edit, can't reference the UI permission for inventory to give you a UI permission to bulk.

Right, but you can do the backend API permissions. It can pull in something from a mod. Um, if the permissions are stored in the token though, one country, couldn't, it just are. I'm thinking out loud here. 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 would walk out of can't access that permission set through Okai API, or is it just strictly passed on to 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, you have a good idea about how to make this simpler and shorter, but I'm not, I'm not sure Sarah has her hand up. 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.

Future discussion topic (time permitting):

  • Bulk Edit of the linked records
  • Scheduling edits

Chat and Notes:

Kimie Kester (noted post meeting via Slack): I checked with a developer, John Coburn , Stripes-Component-Lead for FOLIO, and he said the button at the top of the left-hand pane, in our case, Identifier and Query, is called a ButtonGroup.I said a Segmented Button because I have heard other Devs and UI people call it that but officially they call it a ButtonGroup: https://ux.folio.org/storybook/?path=/story/buttongroup--basic-usage
TopicNotes 

Housekeeping

  • Please add your name to the attendees list
  • Please state your name when you join the conversation to help with meeting notes

Magda: Just some quick housekeeping. Please add your name to the list of attendees and to help Bob with notetaking, please state your name when you participate in the conversation.

Development updates

  • Magda: Frist status updates. The bulk edit developers are living in some of the cities that are in the news of the war. Nobody expected this. Obviously, there were a lot of challenges.
  • Magda: The other challenge is that some of the engineers not on my team, the Firebird team, could not work to the full extent. So we need to rely on other teams like devops to set up all the environments. This time it is falling on the Firebird on my team's responsibility. They don't know this. They need to learn. They are learning the new functionality as they go. So things are just happening much slower.
  • Magda: When we partnered last time, 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.

Image Removed

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

Image Removed

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

Image Removed

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

Proposed modification to the landing page

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

Image Removed

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

Image Added

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

Image Added

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

Image Added

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

Proposed modification to the landing page

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

Image Added

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

Image Added

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

Image Added

  • 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.
Action menu - support for in app and CSV approach 

Pilot Project UAT  

Image Added

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

Image Added

  • 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
Action menu - support for in-app and CSV approach 
  • 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.

Image Added

  • Magda: But a user is taken to in-app 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 contain here? Save change records and save errors. What else should be here? 

Image Added


  • Magda: Currently, in the CSV approach, we have a start bulk edit. 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 application where we need to know what records we are going to be editing.
  • Sara: With the in-app can I save the record and download it prior to committing?
  • Magda: Yes. So this is the moment before you will commit your changes which states how many records you will be changing. You have this option, to download preview. You can download the files and see them. You will see how the records will be updated once you commit the changes.

Image Added


  • Sara: I still like what you were asking before that to have the option afterward to download my errors.
  • Magda: When you get to this screen you can download the list of the records that were modified and also the errors if an error occurred.

Image Added

  • Magda: This was again another very good discussion and we didn't cover all the elements, but we have something to look forward to our next meeting.

Pilot Project UAT  


Future discussion topic (time permitting):

Bulk Edit of the linked records

Scheduling edits




Chat and Notes:

Kimie Kester (noted post-meeting via Slack): I checked with a developer, John Coburn, Stripes-Component-Lead for FOLIO, and he said the button at the top of the left-hand pane, in our case, Identifier and Query, is called a ButtonGroup. I said a Segmented Button because I have heard other Devs and UI people call it that but officially they call it a ButtonGroup: https://ux.folio.org/storybook/?path=/story/buttongroup--basic-usage

Chat

00:02:06	Erin Nettifee:	agenda link if people want to add their names https://wiki.folio.org/display/BULKEDIT/2022-3-8+Bulk+Edit+Working+Group+Meeting+Notes
00:02:39	Sara Colglazier (MHC/5C):	brb
00:07:23	Ros, Amanda L:	agreed Magda
00:07:42	Christine L Tobias:	Agreed, Magda. I think we all share these feelings.
00:11:53	Kimie Matsudo Kester:	Thank you Magda for sharing 💙💛
00:20:28	Thomas Trutt:	i love UI consitancey
00:20:42	Bob Scheier (Holy Cross):	I like consistency too
00:20:46	Scott Perry:	+1 Thomas
00:22:15	Thomas Trutt:	id agree.. i think this will also be limited by staff duties as well, just not workflow.
00:24:11	Thomas Trutt:	change app to Areas..??
00:25:47	Scott Perry:	Areas or, maybe, functions?
00:27:21	Kimie Matsudo Kester:	Segmented button
00:27:27	Erin Nettifee:	thanks Kimie :-)
00:27:54	Kimie Matsudo Kester:	Developers call it a segmented button as far as I know
00:30:49	Jenn Colt:	I’m sorry I know this got said but I missed the answer - what is “circulation” representing in the app list?
00:33:49	Thomas Trutt:	3-STATES.. LOL
00:34:34	Thomas Trutt:	PO anyone..??
00:35:36	Ros, Amanda L:	project owner
00:40:25	Jenn Colt:	How do these intersect with the app permissions?
00:42:49	Bob Scheier (Holy Cross):	+1 Erin
00:42:49	Erin Weller:	+1 Erin
00:43:01	Sara Colglazier (MHC/5C):	Agreed ... +1 Erin
00:43:18	Scott Perry:	+1
00:43:28	Thomas Trutt:	+1 I like that naming
00:47:15	Scott Perry:	Maybe create groups as in the top level list (Acquisitions, Circulation, etc.) if this doesn't reference existing permissions in other apps.
00:48:58	Jenn Colt:	But you might have BE perms in one thing you can edit and not another
00:51:23	Thomas Trutt:	That is true if you are doing bulk edits across different BE apps.. Id love to see it be able to check permission before taking action and then coming back and saying you do not have permission do change X.
00:52:12	Erin Nettifee:	i need to drop off for another meeting - thanks all
00:52:16	Scott Perry:	+1 Thomas
00:53:39	Jenn Colt:	Are you referring to my comment? It isn’t about going across apps. If I can edit in both inv and users, I should be able to then be given bulk edit access only to one or the other
00:56:39	Thomas Trutt:	i was.. So UI wise you are saying you would like to control what areas you can bulk edit.. IE just cause you have edit access to users may not mean you can bulk edit users. (am i understanding that correctly??)
00:57:56	Jenn Colt:	yes
00:58:30	Thomas Trutt:	I think that makes sense. Limit damage staff can do.. :)
01:00:00	Ros, Amanda L:	+1 Thomas :-)
01:00:26	Scott Perry:	I need to leave for another meeting.
01:00:38	Jennifer Eustis (she/her):	I also need to drop off for another meeting
01:01:43	Christine L Tobias:	I like the Download Preview option!
01:02:26	Thomas Trutt:	YES.. thank you all