| | | |
|---|
10min | Process check-in | Chris | How are people feeling about the process we’re using? Any feedback or suggestions on how we can improve? As we delve into more specific areas, do we need subject-area specific meetings? No complaints about process so far In general, people are happy with just one standing meeting per week We should have a clear agenda so they can make sure the right people are in the meeting The SIG said they were willing to coordinate additional meetings, if absolutely necessary to keep the project unblocked, but only if really needed Given this, Cate said she and Filip would meet and try to prioritize their needs for the group to determine whether additional meetings are necessary
|
15min | FOLIO 2018 Release doc, User Management tab | Chris/Paula | Harry Kaplanian has put together a spreadsheet designed to gather requirements and define what should be included in the initial release of FOLIO. There was some initial discussion of it at the tail end of the Product Council Face to Face, but it needs further review. We’ve been asked to look at the User Management tab and give Harry our feedback. Google Doc Link Decision frame: would you want your implementation to be delayed for this feature? Group agreed that, for v1, we could live without custom fields and removeable fields in the Users app SSO, on the other hand, is crucial for some. But that is marked as v1 on the Library Dependent tab If we can't support fully custom fields of configurable type, we might just support a few "catch all" custom fields which the library could use if needed. This is nice-to-have for v1.
|
20min | Circle back on user metadata items | Cate | : Proxy, Notes, Patron block Notes were added in document: https://docs.google.com/spreadsheets/d/121RpsJNaewhQEKb7k58eNVIhZ7N9oSWowNRJGYjPJ2M/edit#gid=0 |
5min | Are there additional user metadata fields needed? | Cate | None needed |
10min | User permissions | Cate | What aspects of User Management app need to be permission-controllable. User view, edit, create and delete is probably not granular enough. Let’s discuss the specific metadata elements and functions and determine what should be rights-controlled. Looked at User Permissions document: https://docs.google.com/spreadsheets/d/1IJnlWvi4k-wFatDNimx9fQ375evHSIIxtGMookHvs-I/edit#gid=1828294931 Discussed how permissions will be assigned and grouped in FOLIO Focus of our discussion is on the base permissions that come with the Users app Discussed notion of flagging user metadata items as "basic" or "special" (meaning, essentially, security level 1 and 2). You could then grant users permissions to view or edit basic or all fields. Group thought this might work Some use cases discussed: As a person who deals with patrons, I shouldn't be able to modify staff permissions As a person who deals with staff, I shouldn't be able to see staff members' borrowing history or fees and fines10 As a student worker in Circulation, I shouldn't be able to inactivate or delete users
Decided we really want the Resource Access folks to participate in this conversation. Chris will coordinate with Andrea and try to get some RA SMEs on our regular call next week.
|