2021-11-30 Bulk Edit Working Group Meeting Notes

• Magda: The first question I have is related to the transcript. If I turn on this transcript, it will crash my computer and then I will not be able to last until the end of the meeting.
• Bob: I will record with my phone if everyone is OK with that.
• Magda: Please add your name to the list of attendees on the wiki page.

• Magda: Developments - Unfortunately not that many changes that can be visible. There is progress on the backend happening that will unblock the UI work. Hopefully next time there will be more to discuss. However, the team has created a rather detailed technical design document. The link is in the agenda. Please feel free to review the document. The document is fairly technical and is inventory specific. However, the development team is aware that we are building an application that will support bulk edit in other areas.
  • Erin: Question: This document specifically mentioned S3. Will this be similar to other approaches where S3 will be required to use the app. I am thinking about Texas A&M and other places?
  • Magda: Actually, we started using S3 in data export but in Kiwi release we made the hosting gnostic, meaning the libraries don't need to use S3. And this will be also a part of the bulk edit. They will not be required to run bulk edit on AWS. It's a very good question though. Feel free to add this into the comments on the page. I discussed this with the developer. He did not respond that in writing, but I will follow up and confirm.

So far we discussed and I believe we agreed upon :

1. Small but reliable functionality that is limited to the user records as defined in in the scope of UXPROD-3225 
2. Evaluated by Bulk Edit Working Group, SIGs, Product Council and  Technical Council: 
3. Available for acceptance testing in a separate environment that will contain larger dataset and will not be refreshed nightly (RANCHER-63)

We still need to discuss:

• Should it be included in Lotus release?
• Next steps

-------------Notes from Meeting----------------

• Magda: I would like to continue with the bulk edit expectations. In a very short summary, I think we agreed that:
  • Scope should be small, but reliable
  • functionality is limited to user records as defined in scope of UXPROD-3225
    • In scope will be:
      • Limited bulk edit for user records
      • Search by user group, list of barcodes
      • Edit: remove permissions, update expiration date, update patron group, update email
      • All elements related to bulk edit workflow (even if only limited form):
        • Identify records for editing
        • Edit record(s): add data, remove data, update data, i.e., change the values of the fields within the records. It is not adding new or deleting recorders.
      • Question from Erin: I think that removing permissions which aren't in the core user record shouldn't be in scope for the pilot.
        • Magda: I would agree with you that permissions will be a difficult thing to implement, especially since this is a separate record. It is not, as I like to refer to it a linked record, similar to fees and fines. But I would like to keep it for now. And then maybe towards the end of the release, we will evaluate it.
      • Question from Jennifer: When you say remove the permissions, is that like both individual and group permissions?
        • Magda: I was thinking in terms of groups especially the use case where you have student workers and at the end of the semester you need to remove permissions for this group of users.
        • Erin: Permissions are different because you have the concept of a user record and then you have the concept of a permission user record. Permissions aren't directly stored on the user record, they're just linked. It's not like you would go into the user record and just say, remove this attribute and this attribute and this attribute, you have to break the link with the permission user. So that's where this would be really complicated. But if you were to remove permissions, you are removing the link to that person's permissions, whether it was individual permissions, permission sets, visible, invisible, whatever. You're just removing them all.
        • Magda: It's not only breaking the link; it is also removing the record from the table that contains the data. We don't want to have abundant data left in the tables.
        • Sara: In our current system I can have an expiration date for the permission. So, I can assign a student worker, certain permissions and it expires on such and such date, but the record remains because I find this useful to be back, we'll shoot and see that that person did work here with this username and find if they did anything that I want to fix.
          • Erin: Unfortunately, FOLIO does not have that functionality to expire permissions. There's an expiration date on an account, but there is no expiring on permission.
          • Magda: I really liked the comment, Sarah. This is important feedback you need to go back to the data, and if we remove it, it's gone. I will make a note of this. Also, if you talk with Erin about this, please include me as well.
          • Sara: At the Five Colleges permission groups will be set up by the FOLIO Administrator. Will this be a permissions problem for me in bulk edit if the permissions are controlled by someone else?