Page Comparison

Housekeeping

• Please add your name to the attendees list
• Could we meet weekly until the end of the Lotus release?

• Magda: I would like to increase the frequency of the meetings and start to meet weekly and do this until the end of lots the Lotus release or at least until the end of February.
  • Group: Several had conflicts and this was tabled.
• Magda: I will be reaching out via Slack with some specific questions. The reason that I wanted to increase the meeting frequency is that I'm trying to finalize the requirements for the Morning Glory release and I have a lot of unanswered questions. Let's see how quickly it goes via Slack and if this does not work,  I will follow up at the next meeting to see what we can do.

Development updates

• Development status
• Development team scrum board
• Acceptance testing environment (Kiwi bugfest user loggings should work)

Scenarios for UAT 

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:
    1. User permissions
    2. Delete user records
    3. Item locations
    4. 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.

....more notes to come......

Survey review:

• Bulk Edit Limit Size
• Bulk Edit Permissions

Future discussion topic (time permitting):

• Bulk Edit of the linked records
• Scheduling edits