Morning Glory release planning - In app bulk edit:
- User permissions
- Delete user records
- Item locations
- Item status - inventory-specific statuses as an option to start.
- Other?
| MORNING GLORY RELEASE PLANNING - Magda: When it comes to planning for Morning Glory, I would like to spend time in the next release with the in-app application. And this would build the framework for other functionality.
- Magda: I would like to do the user permission as part of the in-app functionality.
- Magda: Since we did do delete records in this release in the scope of the pilot, I would like to work on the deletion of records?
- Magda: The next two items that are very often coming in our conversation are changing the item location and items status. Those two will also be done in an-app bulk edit.
- Magda: Your comments about that?
Erin: Magda: You know I still think permissions is maybe a bit big, but that could be included there. I think the longer that items don't go out the more unhappy people are going to be. I don't know if there's room to punt one of those scenarios so that we could have more time to move to the inventory use cases, but I don't know what other people think? Sarah says, plus one in the chat I think to my comment about trying to move as quickly as we can into the inventory. Sarah: I definitely think items are so needed. Magda: Item statuses, locations, or what from items? Magda: So if you look at this list of these four elements and you could build only three of them, which one would you remove? - In app bulk edit:
- User permissions
- Delete user records
- Item locations
- Item status
- Erin: I would remove permissions.
- Sarah: Me too.
- Erin: And when I say remove, I mean, hopefully, complete in the future. I don't mean never do.
- Amanda: I agree with that.
- Erin: I will just say that status is going to be really complicated because there's a ton of workflow stuff around how item statuses are configured and the different transitions that are allowed or not allowed depending on the case may be.
- Sarah: In connection with the item statuses I think we need a bit of clarification. What is that? What is meant by that? If I'm in inventory and I opened up item record and I click on the action, then I see what I consider certain item statuses. But if I'm in the search area and I go over to filter and I want items statuses, there are a whole bunch of other ones that are triggered by other functions or apps. There is a big difference between what we're talking about. Are we talking about things that are triggered through the circulation process? Are we talking about item statuses that are triggered or functionally interact through billing and that type of stuff versus purely inventory-related items statuses, like if I'm going to make something unavailable or missing? I think we have to treat them separately.
- Magda: Since we plan to do this using the in-app approach, we will be able to control what statuses can be edited. And I was thinking about purely inventory, statuses, not necessarily others because of what you said is the complexity of the issue. I definitely will need to get your feedback more about this. I'm not prepared for this conversation right now, but as we work on the requirements for the items we will need to define what will make the release and what needs to be addressed later. But because we will be in-app, we will definitely be controlling what status can be edited and those that cannot be.
- Sarah: So can we just add that here? Can we make that really clear that right there, maybe after items status we put inventory app or something like that, that it's really clear what we're working on?
- Erin: But again, all the item statuses are in inventory. What you're seeing are things that are controllable by a workflow transition. Like the stuff that is in the item action drop-down versus other statuses that could or could not appear. They're all in the inventory app.
- Sarah: I understand that, but how do we phrase that, that we only need the ones that are controlled by the drop-down.
- Erin: Well, I don't know that we have decided that yet. And that's part of why I said to Magda earlier that I think item status is going to be super complicated. There are also other pieces of item status like the three-part item state model that is supposed to be implemented in FOLIO but has not progressed. So there are a lot of moving parts.
- Magda: We definitely will talk about this in the next couple of weeks because this is the time to finalize the requirements. And I am aware of the high level of complexity items, statuses. So we will definitely need to talk about that more.
- Magda: But from what you're saying, the item statuses are more important than user permissions is this correct?
Leeda: You know, I would say out of that list the least complicated to work on next would be the item locations, but there's a caveat. They've proven to be a little more tricky in data import than we expected them to be when it comes to matching and calling up the correct location. That would be my pick for next up. It's not going to be as tricky as item statuses or user permissions. It still has its little pitfalls. Magda: How about deleting user records? Thomas: That is actually what I was going to mention. I would actually keep the user permissions and remove the delete user records. The only reason I say that is I think at least for our institution, the user permissions would be more helpful, especially since we onboard a bunch of students at the beginning of every semester and drop them off. So we have to edit the permissions of 60 or 70 students every semester. So being able to do that in a bulk method would be very helpful for that. Deleting user records we are already handling through background processes. Are there any institutions that are deleting a lot of user records through the UI or are they handling these through background processes? Erin: The UI deletion was just implemented. It might've just come out. And the UI deletion is one by one. So I don't know that there are many institutions out there that have this use case yet. I do think that if you're deleting user records, that kind of thing is pretty simple to script as opposed to other things. And that's one of the reasons I'm not as concerned about that one. But also my reason for saying don't do user permissions yet is I think it's really complicated. And I just I'm concerned about the fact that we are already slowing down kind of where we thought we were, which is not anybody's fault. It's just that these are complicated things. Magda: So a couple of things. I do agree with the approach. I was actually surprised to hear that you think that we can take permissions out because my understanding was that this was especially painful for users to do this one by one. I also think that the in-app approach gives us more control over what we are allowed to do. That's why I am a little bit hesitant to do the permissions with the CSV approach because then the user can really make changes that can be catastrophic for the whole system. Erin: There's also a separate feature/umbrella that is sitting because it doesn't have a PO it's UXPROD 3159. That's intended to provide a redesign of a number of the different UI aspects of permissions. So it's not to say that Bulk Edit can't do this, but the bulk delete is one of the use cases. That is part of what this thing is doing. And so, you know, if 3159 has the potential to move ahead. Then I would say bulk edit, shouldn't do this because you're duplicating work. If that makes sense. - Magda: The difference is, and, you know, we don't want to build functionality for bulk edit permissions in let's say Morning Glory only to have permissions redesigned in Nolana. Let me think about this a little bit. do believe that the permissions are important especially for those are simple use cases when users change their status from a graduate student to alumni or from being student workers to a graduate student. And when I look at the list of those four items, I think that deleting user records will be needed the least and can be dropped from the list. And I think Thomas was saying the same. And Erin I know you don't feel that deleting user records can be dropped.
- Erin: When I say dropped, I don't mean we should never do this. I'm saying it gets pushed farther out on the prioritization.
- Magda: Is there anyone else who would like to voice their opinion?
- Amanda: I would vote for deferring permissions.
- Magda: I will create a quick survey and post it to slack to prioritize the functionality.
Magda: Can you please tell me if there is anything else you'd like built that is not on the list? Erin: Not on the item record piece. Locations and statuses would be what I would hope we moved on to. Magda: I'm not only referring to items and users. I'm talking about other apps like circulation requests, etc. Erin: I'd have to go back and look at the list of the use cases? There's a ton of stuff on there. I'm not sure I could tell you right now. - Leeda: We do holding record change. If you do an item location change, that's generally understood as a temporary location, but we also do permanent collection moves in batches where we need to change the holding records.
- Erin: Yeah. On the use cases page, there is a priority column. I don't remember where that was set from. But you know, if we look at that there's changing location, and changing barcodes.
- Magda: Changing item barcodes, for this, I am working on another feature for data export that will allow export in CSV format. This will not resolve the issue of uploading because we don't have this routine, but this could be added to bulk edit, a similar approach to how we do this with the CSV approach for users but for items. But I don't want to work on that just yet.
- Magda: The priority here, item locations and the item statuses are coming pretty currently and are mentioned as high priority. I'll send a sruvey today asking for a quick response from you.
Erin for Jennifer in chat: Jennifer is asking in chat about suppression from discovery and bulk update of material types. I don't know that either of those made their way into the use cases. Suppress rediscovery is in there, but it's listed as a medium priority. Material tape isn't in that list explicitly. Jennifer: Another thing was location. A lot of times we put things like on reserve or they go to exhibits. And so it's a lot of times it's a combo bulk edit. You put them in the temporary location, you actually have a different loan status, and then you've got to take that off. But that's probably too complex and I'm not sure we need to prioritize that for items. Thomas: I was going to ask about the material type and loan type also because just as Jennifer said, we switched the loan type and location all the time for reserves. So those would be the two that would probably pop up for us the most as well. Magda: I know this group is heavy with metadata librarians. Is this the reason that we don't have requests for other areas or is this because the bulk edit... Erin: What do you mean other areas? Magda: When I say requests, I mean the suggestions from other areas. In terms of other areas, I mean reqests, for example. When we look at functional areas, user management. we have touched, but circulation, I don't have anything from circulation. Nobody mentioned anything from the circulation, agreements. Erin: So I will say that there's very few use cases I can think of for loans, which is like a snow day and you need to change due dates and stuff like that. But a lot of what circulation does for bulk edits is reflected in those item use cases and it's reflected with those users use cases. We do a lot of stuff with user records. So I don't look at this list amd think that there's a ton of RA stuff that's missing Erin: I don't think the requests app is listed anywhere and there may be a use case or two there that might be important, but it's it's, I, I really don't think that there's a ton of circ. stuff that's not there. Magda: When I was going through the use-cases sometime ago, I created a spreadsheet that lists all the areas and definitely requests were there. And I grouped them by endpoint to know for the backend work who would be accessing. Erin for Scott in chat: Scott comments in the chart that he has added acquisition use cases and that he thought we had decided to focus on one area at a time. Magda: And this is correct. I just wanted to make sure the other areas don't feel ignored or not heard. Erin: I think some people may end up feeling that way Magda, but that is completely out of your control. I think you have done exactly what anyone would have expected in terms of soliciting participation and publicizing the work that's going on. Thomas: So just building on what Erin said, I agree with 100%, a lot of the stuff that we do at circulation at least for now is already built into collection development part of this. The only thing I could think of that would be circulation specific would be modifying due dates are or potentially renewing items and that's pretty much it. And even the rebel renewing. For us as only kind of falling on our , this only happened in two or three instances, like at the beginning of the pandemic we went through and renewed everybody's items or extending them out. It's not something that we do on a regular basis. It might be worthwhile if you're worried that there aren't things covering, just sending out a general feeler to everybody to look through this list and let me know, but I don't think circulation does anything outside of what everyone else does.
- Sarah: Magda, I will also just mention I work with erm and acquisitions, but I also do all this type of work. For me, this is the priority. I can handle changing things in erm and orders without bulk editing. I would much rather be able to change temporary item location and also loan status along with that. But especially the taking them off-reserve. When you're putting things on reserve, you are very often putting them on as you get notified by the faculty member. But taking them off at the end of the semester you just want to take them all off. But I think again, we need to be specific about what we're talking about. We are talking about the temporary location, Leeda mentioned this, because the permanent would be made at the holdings level?
- Erin: Well there are use cases for the item permanent, but they're definitely not as much as the holdings record.
- So, this is interesting because my understanding of the locations was that depending on the institutions, one institution stores the location on the item level or on the holdings level. But from what you are saying, I hear now that the locations on the holdings level are permanent and the locations on the item level are considered temporary.
- Erin: There are four location fields on the records. There's a holding temporary and a holding permanent. And then there's an item temporary, and an item permanent. You have the four locations. And then you have two effective locations. You have holdings effective and the item effective. For most libraries, the holdings location is the location of record. It's what gets sent to OCLC. It's what they would consider being the record of where this thing is. There are use cases for setting an item, permanent location. I can't remember what they are, but I know that there were use cases because it was discussed way back when, when Kate was still here and when all that stuff was being architected. So there are use cases where an item may have a permanent location that is different than the holding permanent location. But I think maybe I might extrapolate a little bit from what Sarah said and say that the holding permanent edit should be a hybrid because that's often the work that the library is doing when things are moving around, not for temporary.
Leeda: The way I understood it, the holding location feeds down to the items. So if you don't get any information at the item level, it's looking to the holding records. So if you had a batch of them and you wanted to do like a permanent change to remote storage or something., you would do it at the holding level. Erin: Correct. What it does is it feeds into the effective location, which is the computer field. So it doesn't fill in a value on the item record. It is just that the logic that computes the effective location goes, oh, there's nothing here on items. Okay. Let me look at its holdings, and then I'll figure out. Magda: This is how I understood the locations, but the part that I did not know until now, and I still don't know if this is correct, is that libraries tend to use the holdings location as permanent and item level location as temporary.
- ....more notes to come......
|
