2022-1-11 Bulk Edit Working Group Meeting Notes

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:
  • UIBULKED-12 - Populating preview of matched records based on identifiers search

  • UIBULKED-16 - Populating preview of matched records based on query search

  • UIBULKED-13 - Populating error accordion
  • UIBULKED-22 - Completion of the bulk edit

• 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 boxes 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.
  • https://bulk-edit-perf.ci.folio.org/
• 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 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.

  • Please submit your suggestions before the end of the week (January 14th)
  • https://forms.gle/K1JyUGaAWEKqBAd66

• 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 the latest, 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.
• 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 I don't R it's so needed, so I Thames statuses locations or what? From items. Both. So if you look at this list of those four, uh, elements, APU, uh, could build only three of them, which one would you remove?

I would remove permissions meet too, in the sense. And what I say remove, I mean, hopefully, complete in the future. I don't need like. But I agree with that. Um, 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.

Um, and yeah, in connection with the item, I think. I think we need, or I feel like I need a bit of clarification. What is that? What is meant by that? Like, I was worried and I opened up item record and I click on action. Then I see what I consider certain items, statuses. And then, but if I'm in, uh, the. Area and they go over to filter and I want to on items, statuses, there are a whole bunch of other ones that are triggered by other, other functions, right.

Other apps to also make a big difference between what we're talking about. Like, are we talking about things that are trickle or trigger it through the circulation process? Are we talking about item statuses that are triggered? Or, you know, functionally interact through like billing and, um, you know, that type of stuff versus purely inventory related items, statuses, or that's how I'm thinking of them.

Like I'm going to make something unavailable or it's missing or, and I don't think, I think we have to treat them separately. I was thinking about a sub because we do this. W we plan to do this in, in app approach, we will be able to control what the status is, can be edited. And I was thinking about usually inventory inventory, statuses, not necessarily.

Oh, there's because as you said, of the complexity of the issue, so let's start with the available on the available, or I definitely will need to get, uh, your feedback more about this, and I'm not prepared for this conversation, um, right now, but as we will be fine as I will be working on the requirements, uh, for, for the items that is.

Uh, we would need to define what can make the remedies and what needs to be addressed later, but because we will be in our, uh, we will be definitely controlling what status can be edited and can, and those that cannot be so can we just add that here? Can we make that really clear that right there, maybe in front incidents, after items status?

Yeah, inventory app or something like that, that it's really clear what we're working well, but again, all the items statuses are in inventory. They're just there. What you're seeing is, is things that are controllable by like, by like a workflow transition. Like the stuff that I have dropped out, the action drop down versus other statuses that could or could not appear, but.

They're all in the inventory app. Like how do we phrase that, that we only need the ones that are controlled by the, well, I don't know that we have decided that yet. Um, and that's part of why I have said tobacco that I, why I was saying it back to earlier that I think item status is going to be super complicated.

Um, because there's also other pieces of item status, where there are, there's at least one I can think of that hasn't been developed yet. Um, and then there's also a whole. Three per items, state model that is supposed to be implemented in folio and just doesn't have a PO it hasn't progressed. So there's, there's a lot of moving parts there.

Um, so there's, uh, there is some documentation in the Wiki. I'll put the link in the chat. There's. Uh, a page that has the, sort of the different items status is what circulation transactions are allowed or not allowed. Um, I think there was also one that was all they can see if I could find the other page, but there was another one that more generally was talking about transitions between had a chart that am a veteran.

Um, that had transitions between the different states and what's less loud. And what was on that.

We definitely would, uh, talk about this, uh, in the next, uh, couple of weeks because, um, so this is the time to, to, to finalize the, um, the requirements. And, um, I am aware of. Of, um, complexity while I'm aware, uh, high level of complexity of items, statuses. So we will definitely need to talk about that more, but from what you're saying, the item statuses are more important that user permissions is this correct?

You know, I would say out of that list, possibly the. The least complicated to work on extra B item locations, but there's a caveat. There is they've proved a little more tricky and data import than we expected them to be when it comes to matching and calling up the correct location. That would be the, um, my pick for next u

Permissions implemented in scope of UIBULKED-11 (known permission issues: UIU-2486 - Getting issue details... STATUS and UIU-2075 - Getting issue details... STATUS )