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.
|
Scenarios for UAT | SCENARIOS FOR USER ACCEPTANCE TESTING I would like to ask for your help with providing scenarios that you think should be a part of the user acceptance testing. This is the link to the survey to provide your suggested scenarios. Bob: Is there a suggested format. - Magda: I was thinking you can be descriptive here. Based on the feedback I will create test cases in Test Rail. And they will go through the mechanics of entering test cases there. But also I think for our acceptance testing, we can agree on a spreadsheet that will be available to all of us and where we can record our findings. Would that work for others? I assume the quiet means agreement.
- Erin: I think that makes sense. I think we just want to make sure that we are looking at the user acceptance testing scenarios that go back to what we described as the requirements as well.
- Magda: Yes, exactly. I don't want to impose my scenarios. But, if I don't get your responses. I will put whatever I think is appropriate. But definitely, I would like rather hear from you.
- Erin: Magda, are we doing user acceptance testing separate from bugfest?
- Magda: Yes we are, and I would like to start by the end of the sprint, January, 21st at thelatest, hopefully, we can start next week.
- Magda: I would like us to start playing with the app we build so we have more time to address issues hopefully before bugfest.
|
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. - 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.
- ....more notes to come......
|