Page Comparison

• Magda: The progress on bulk edit development has stopped because the same team is working on the call number and subject browse functionality, and those need to be completed by this Friday because they are part of core modules, inventory. Once this is done they will return to bulk edit. There are two or three stories that when completed will open all functionality. This is the scrum board if you would like to see where we are. These three front-end stories are preventing us from seeing everything.

Image Added

• Erin: Magda, you may not know the answer to this, but do you expect that bulk edit will eventually become a core app or a core module?
• Magda: I think it's too early to tell. Definitely not in the Lotis release. I am not sure who decides what is core or not.  From my point of view, the difference between core and platform complete is the deadline where we have to finish development. I'm sorry I don't have good news, but it's not really bad news. We were kind of expecting that we will use the call development time, the development deadline is February 1st. By our next meeting, which is February 8th, I would expect we will have something to demo.

• Magda: Regarding the acceptance criteria, all login issues should have been resolved by now, if they are not, I'm not aware of them so please let me know.

• Magda: I granted bulk edit permissions to everyone who reached out to me. So if you log in and you don't see bulk edit permission it's because you don't have the required permissions. This is by design. We don't want everyone to have access to bulk edit right away due to the powerful functionality that is being handled with this.

• Magda: On the scenarios for UIT, I sent the survey last week. I got only one response which I believe was probably due to confusion. I will rephrase it and resend it for the group.

• Magda: On the morning we grow glory release priorities we got 18 responses and it is pretty obvious which is the most sought-after functionality. I did a simple calculation and assigned a weighted point value, P1 five points, P5 one point and the rankings are as follows: Item location is on top with 35 points. Next is item status, then delete users and user permissions. So I think this is the order we will be addressing the issues. I'm not sure all of them will make it into the Morning Glory release.

Image Added

• Magda: I have a couple of questions regarding the other areas that were mentioned. Loan policy, we touched on that and I would like to exclude loan policies for now, unless you tell me that my doing item location without it does not make sense.
• Erin: So loan policy would be editing alone, which is not any of the data types that we have talked about so far.
• ???: So can I just ask the question though? It's only editing alone if the thing is checked out. For the reserves use case, we need to take off the loan type and the location. We can't just take off one or the other. Does that make sense?
• Magda: Yes, but it complicates things for me. But we will get to this may be a little bit further down the road. I would like to understand the correlation and I would like to make sure if we do these without including loan types if this makes any sense or not
• Magda: The next one was item status. Hopefully, we will get to this today.
• Magda: Delete users, this will be the in-app approach. This was something that I originally thought we will do in the scope of a pilot release. I was really surprised that user permissions are on the bottom.
• Magda: Question about holdings. The holdings were mentioned, and they were mentioned twice in other areas. Thus item location without holding location makes sense, or do they need to be combined as well?
• Erin: If you have an item record and there's no permanent or temporary location on the item record, it inherits the effective location from the holdings records. I think what we may need to think about for the item location use case is we may need to be able to query for item records based on the holding permanent location and then edit the item. Let's say that I want to be able to see a holding location because I'm going to move a bunch of things or I'm going to temporarily put those items somewhere else. I need to be able to identify them based on the holdings in order to then edit the item record.
• Magda: I think I have this in my slides that I'm going to share shortly. So I think we will get to this. The holdings location will be a separate record that we will be modifying later, but not in the scope of the item location.
• Erin: I think they need to be in scope for the query.
• Magda: They will, but this is separate, it's also on the slides.
• Christine: I wanted to go back just a moment when you were going through the rankings. I think I need clarification. The delete users. I thought that was out of scope for this project, but are you saying that people rallied for it to be part of this?
• Magda: Yes, according to the feedback I got. Delete users were not in the scope of the pilot project that we are just finishing. The bulk adding of records is definitely not in scope because this would be a load. But the deletion is actually in scope. So you will need to have an option to delete a group of users.
• Christine: Thank you for clarifying that for me. You mentioned that you were surprised that user permissions were at the bottom of the rankings? I feel the same. I think that user permissions are super important for bulk editing from a user management perspective. And I know there have been conversations about a possible permissions app, um, in the future. So. Kind of wondering why people ranked user permissions the lowest.
• Magda: Maybe we can come back to this at the end of the meeting, if we still have time, and let's also discuss this on the Slack channel. I do believe user permissions were treated as less important in terms of those four options. I'm not saying we are not going to ever do this. I'm saying this is just further down on the list.
• ???: I think they were also among the most complicated.
• Magda: My most recent experience with user permissions is that it is kind of a baggy area. There are problems with this. So, I really appreciate Erin's feedback about user permissions making her nervous. They are making me nervous as well. But I see this as important functionality.
• Magda: Update expiration date and add patron group. Someone mentioned this. This is already supported in the scope of the pilot project that we are completing. And I'm not sure if the person who asked the question meant this is an in-app approach instead of the CVS files approach. I don't remember who asked this question. If the person is present, please speak up. And if not, I can reach out in slack directly to the person.
• Magda: The next question, "User search interface/tools that would generate the list of records to be worked on." I did not understand what was meant by that. If the person who asks the question is on the call can clarify what was meant by that?
• Thomas: It may be coming from an institution that's using underlying Marc records instead of the instance records. I know Cornell has a bunch of those, so I could see somebody from my metadata management group wanting to update fields or subfields in those records.
• Magda: This is the next bullet item Thomas but this is a good segue. So I will follow up with the person that posted this suggestion.
• Magda: The bib data for MARC records, I agree with you, Tom. This is on the roadmap but not happening in Morning Glory. It may happen with Nolan, or even later due to the complexity of this work.

• Magda: I would like to jump into item location and I have a quick presentation here.
• Magda: I want to gather your feedback about the elements that you need to identify item records.
• Magda: The question of item identifiers is to populate the dropdown as we have now for user records: user ID,  user barcodes, external ID, and username.
• Magda: For the item records to be identified to change the location or anything else we will select a different checkbox which for the next release will probably just be for items instead of Inventory.

Image Added

• Magda: And the question, which I posted on slack, is how would you like to identify the item? The responses I got were: Item UUID, Item HRID, Item Former Id, Item Accession Number, Item Barcode, and Holdings UUID. Is there anything else?

Image Added

• Erin: Nothing I can think of. Everything that I can think of is on the query side. This screen assumes that we already have what we want, we've already done the query and we're just starting to figure out how we're going to identify the records. Based on what is potentially on the item or on the holding record is all I can think of. But others please chime in.
• ????: That's a good distinction, Erin, that at this point you'd already have done the query. So you don't need as many here.
• Magda: I have a slide about the query and I will get back to this shortly, but let's for the moment assume you have submitted the list of identifiers. And this is a screenshot from user records, and obviously, we need to modify it for item purposes. The question is what columns do you need to have here.
• And these are the responses that I got in slack: HR ID, Former ID, Status, Material Type, Permanent Loan Type, Temporary Loan Type, and Effective locations. Do we need to have anything else to know these are the items you want to edit?

Image Added

• Sarah: If somebody gives me a text file of barcodes, I can use that here, right?
• Magda: This is exactly the purpose of this screen. So let's say the Circulation or other department scans the barcodes and you have the list of the files. You upload the files here and based on the barcodes, it populates this screen. This screen will also be populated if you click query to submit a query. I just want to make sure that the columns that are here are the columns that will help you to identify them.
• Sarah: Then I think I would want the barcodes here too for confirmation.
• Magda: Anything from anyone else?
• Jennifer: I was thinking instead of the effective location, at least for the item, maybe the permanent and then temporary location.
• Magda: In addition to effective location or instead of?
• Jennifer: That's a good question. If there is nothing in the item, then it will be coming from the holding as Erin explained. I don't know actually what do others think? I guess I was thinking instead of, just to not have a million columns, but I could go either way.
• ????: I would agree that instead would be more beneficial.
• Magda: Show columns will continue to be available. So let's say by default we put the permanent location and a temporary location, but the select columns will have effective location available. Would that work?
• Leeda: Do you need to set this for every session or will it hang on based on your user preferences?
• Magda: I think the current implementation is that for every session you need to reset this is a common component that’s being used in different areas as well if it is implemented it will preserve the selection for the user then it would work here as well but I don’t think this functionality is implemented yet. Any other comments?
• Sarah: I do have a comment. I was just trying it out. And the effective location is the same as what is in the holdings record. It seems then that the temporary and permanent location in the item is blank if you’re accepting the holdings location. It’s on the effective location basically tells you what that location is.
• Magda: the item location overrides the holdings location.
• Erin: It becomes the item effective location it does not change anything on the holdings record.
• Sarah: I know that. Override is the wrong word. But wouldn’t we still want to see then the effective location if I change the item location because otherwise, I don’t know what the holdings location is for that item to which it is attached?
• Leeda: We would want to know that they are different. And in Aleph it is a column temporary location on yes or no. Especially if we have a situation where we can change item locations but not holdings. We need to keep up which are different.
• Magda: Sarah it means that you are saying we need to have a permanent location, temporary location, and effective location all of them right here?
• Sarah: I would say yes. Otherwise, you will not be aware of when they are different.
• Erin: So is there an option to preview some columns and to download all columns? That might be a middle ground in the UI. So if you needed to verify more fields than listed you could prior to doing your change?
• Magda: So let's say we have 100 records and we see five or ten on top. Do you want to see all of them before you commit?
• Erin: I want to see a preview because you're giving me a preview in the UI.
• Magda: So in the preview, you would need to select them. Let's see how much space we have and what we can fit. I may follow up with you with the prioritization of the columns. But I am hearing that you definitely would like to see three of them: item permanent location, item, temporary location, and item affected location. And this may be a combo. So once you select one of them, considering that you will be changing the location, I would say this is rather important to see.
• Sarah: I have my FOLIO item displayed and my problem is it is not the item's permanent location which is still showing blank for me. Under location in the item, there is holdings location and the permanent location is that of the holdings record. Then as soon as I change the item's temporary location, the effective location for the item changes to that temporary location. So what I need to know is the holding's permanent location in relation to the item temporary location which would be the effective location if I am understanding correctly. So maybe it’s the holding's permanent location and effective location for the item that we need to know so we can see that they are different.
• Cammie: Why wouldn't we do the holdings permanent location, the item permanent location, and then the temporary location, because the effective location changes whenever you change any of those three.
• Erin: Would it be possible, Magda, to do a couple of different screenshots that could just help us see what might be possible? Because I think everyone is bringing up good points. It may be a thing where getting the visual will help us kind of understand what the trade-offs are for different combinations.
• Leeda: I don't want to put more work on Magda, but I definitely agree with what Erin is saying about having some visual mock-ups.
•  Magda: This sounds good and this would be done with Kimi’s help. I'm not sure if we have Kimi on the call, but if not I will relay that to her. It also makes sense and is easier for me to visualize. So we will come back to this. But what was important about what was just said is you want to see item permanent location, item temporary location, and item effective location but also you want to see the holdings permanent location, holdings temporary location, and holdings effective location. Is that correct?
• Magda: Right now what you're talking about is you want to see everything because you don't see the option of selecting based on the holdings permanent location, for example, which I believe should happen in this scree.

Image Added

• Magda: This is the query form on bulk edit. The identifiers where first and now you want the query and you want or query by permanent location, temporary location, effective location, holding IDs. Those are the suggestions that came up in the Slack channel.
• Erin: I think what you really want to query here is the holding permanent location, not the ID number.
• ????: But that's the holding ID. So if you've got 200 items on one holding ID, you might want to change the 200 items on that holding ID.
• Magda: The holding ID was added by me. But what you are clarifying right now is you want to have holdings permanent location, holdings temporary location, holdings effected location, but I also think you would need to have item permanent, temporary location, and effected location as a basis for query?
• Erin: Why can't we just say that I should be able to query by any field on the item record and then maybe a set number of fields on holdings or are they having to hard code the query values?
• Magda: No, I think this is a matter of supporting the query at the backend because it is one thing to query one the entire item record, that is pretty straightforward. But adding holdings complicates things because it has to go to one database table to get the holdings. From what you are saying Erin, you don't want any limitations. I am not sure we can support this out of the box. I would rather have a query that works than a lot of queries that do not work.
• Erin: So can we, can we take information from inventory about what is searchable and then use that to ...
• Magda: But in inventory, you don't have the support for query search on holdings. Oh, wait yes it is there so maybe this will be easier than I thought because we will use whatever has been implemented for Elasticsearch.
• Thomas: I was actually kind of wondering if it would make more sense to have an export from the inventory app that could be imported into bulk edit? It seems like we are duplicating the entire search and export process.
• Erin: You are building even more of a dependency between the apps. And I don't know if there are use cases for editing inventory records where people would not have access to inventory. I would worry about that. It just seems a little too far outside the approach to me. But, I don't know.
• Magda: I think one of the requirements was that we would like this app separate because of the damage it could do. And that's why we went with the approach that separates it. And also we are building on the functionality that will be used across the different modules. We will come back to this.
• Magda: This next slide that I have to discuss relates to the functionality mentioned here:

Image Added

Image Added

• Magda: I really like how effective location is simply phrased here about how it is being populated. So the question in my slide here is we are modifying the item record where in our example we have some value on the permanent location, we have a temporary location, and effective location  (new values that we will add in the scope of bulk edit).  If we update the permanent location and the temporary location, the new effective location will become T.

• Magda: If we had a case where we did not have any location specified and we added new value for the permanent location. This will become effective location.

• Magda: And the same here. If there was no value for permanent location and we added a value for temporary location, this will become effective location.

• Magda: And the last use case is where we had some values, but we left them blank and the holding record is not populated. The location will be blank for this item. Any comments on that?

• Erin: I'll just remind folks that the effective location is always calculated. You don't have to set it to anything.
• Magda: Yes that's why I made it greyed out in the table.
• Erin: In the last row, the effective location is not empty. The effective location is the holdings permanent location. And we are talking about the item effective location here correct?
• Magda: Yes. We are talking about items only (slide updated as shown above).
• Sarah:  And I guess that is my point about why we need to see all the values. If all we're seeing is the effective location how will we know what the effective location is calculating off of?
• Magda: The next slide is what we introduced in this release. We will add an additional option which will be to start bulk edit "in-app" to differentiate from the CSV approach. I am questioning the label "CSV." Would be better to use the label ETL, export, transform, load. Would that make more sense to you?

Image Added

• Erin: CSV would make more sense to me, and I think that parallels what other apps are doing but other people should chime in.
• ????: I would prefer CSV as well.
• Magda: I think it's just naming what is happening and straightforward.
• Magda: Obviously there will be two different permission sets, one for the in-app approach and one for CSV. Some users will only see in-app, others will have both. Because the CSV approach is more powerful we control it more here.
• Magda and Jenn: there was some discussion around the naming convention or verbiage of the menu drop-down names for "start bulk edit (in-app)" and "start bulk edit (CSV)." We will come back to this.
• Mockups from Magda of in-app approach:
• Magda: For the item, you would have these two options only, temporary item, and permanent location.

Image Added

• Magda: And then you would see the replace all with those two options. I think in a replace with make more sense.

Image Added

• Magda: And then you get this default select from a permanent location. And then you would select the location you are interested in.

Image Added

• Magda: I think it's clear from the feedback you would need to have clear mockups and not the Frankenstein mock-ups I created by copying and pasting the different elements. I don't want to confuse you, but I'm afraid I'm confusing here.

• Jennifer: Magda, will we be able to do multiple operations at once using the in-app application? For example, if you wanted to change the temporary location and loan type.

• Magda: Yes, you build multiple change requests one after the other in the app one after the other.
• Jennifer: Will there be collisions in-between statuses, loan types, and locations.
• Magda:  In the scope of the next release, we would like only to talk about item and location, not loan types.
• Magda: In the beginning, I asked whether it makes sense to separate those and from what you're saying, it does not?
• Jennifer: No, I think I'm just thinking if we're going to do multiple operations down the road, then do we have to think about how those operations are related to each other and the business logic.
• Magda: So this is one of the reasons the bulk edit loan types are not in the scope of the item location because it would add complexity. This is one of the areas that was mentioned in the beginning. Here is the feature for item location and here is where I stated here that loan types and holdings location are not in scope.

Image Added

• Magda: So once we get to loan types we will need to take into account that changing location impacts the loan types.
• Jennifer: I agree with Jenn that is the start bulk edit language trips me up for some reason.
• Magda: That will need to be revisited when we will come back next meeting, or I will reach out to you on Slack. We have six minutes left. I would like us to take a quick look at the item status.