Development updates | DEVELOPMENT STATUS - Magda: Unfortunately the main piece that will populate the results in the Bulk Edit app is still in progress. So when we look at the development scrum board, the front end pieces that we need are:
So this the work that is in process and it's been was blocked for a while by the backend work. That backend work is done. Now we are waiting for the front end to be finished. So that's why there was not much you can see in the app. But to make you feel a little bit more comfortable about the progress I would like to take a look at the features that cover the work for the user data pilot project, UXPROD-3225.Edit. The work is being covered in three separate features: Preliminary work - this was the UI work that puts the elements on the page. This is already completed. Identifying, user records for bulk edit - the stories are either in progress or in code review, meaning they should be available soon. User records - bulk edit - pilot implementation - most stories are closed with a handful in review. Those that are in review are waiting for the other elements to be completed in order to be verified. Do you have any questions about that?
- Erin: Magda, we can't see anything yet.
- Magda: You can through the API. Most of the work is done. And when you click on the record you can see examples of how the requests are built. So if you want to venture into the API you can do this. Most of this work is done. As of today, you cannot see this functionality in either of the environment. I can only say the solution is pretty close to being completed, but UI is not there yet.
- Erin: But we just don't have an idea of when?
- Magda: We have the idea and the optimistic approach that it should be done by the end of this week. The realistic approach is by the end of the next week when the sprint ends.
- Erin: Okay. Okay. That makes sense. Thank you.
ACCEPTANCE TESTING ENVIRONMENT - Magda: So this brings us to be to the next bullet, which is acceptance testing. I don't know if anyone had the chance to take a look at this. The environment has been a setup. And it's based on the Kiwi bugfest environment with the user data. We control this environment. So it means it's not refreshed nightly. The data that is there is there. Once we complete the UI development of Bulk Edit, we will deploy it to this environment. And I will let you know when this happens which will probably will be sometime next week. The users are the same that are in the Kiwi bugfest. So if you participated in Kiwi Buckfast, you should have your logging there. This is the case for me.
- Magda: If you have any problems with logging in let me know and I will help. I don't want to share the admin password to protect the data, etc. If you think this is being paranoid let me know and I can share the admin password. But otherwise, I think we should all have access to this environment.
- Erin: That makes sense to have us working as actual users and not using the admin account Magna.
- Lita: I'm curious, the Kiwi accounts that come over, will they have the same permissions? I had a superuser account on Kiwi with all permissions. Would it be the same permission set on this one? And will Bulk Edit permissions be rolled into that?
- Magda: No you would need to add Bulk Edit permissions to this account They are not assigned by default.
|
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 potentially renewing items and that's pretty much it. And even the rebel renewing. For us as only kind of falling on our two or three instances, like at the beginning of the pandemic we went through and renewed everybody's items or extending them out.
- ....more notes to come......
|