2018-09-06 Resource Access Meeting Notes

Date

06 Sep 2018

Attendees

Discussion items

Time	Item	Who	Notes
5min	Housekeeping	Andrea Loigman	Note-taker - Joanne Leary
20min	Historical Data Migration questions	Sharon Markus	9/14 deadline - Historical Data Migration - Planning Questions for Functional Areas
15min	Staff permissions	Holly Mistlebauer (for Tania Hewes)	The Requests Sub-group has defined the following permissions needed for requests: View requests Edit & Cancel requests Create requests All permissions The breakdown of what would be allowed can be seen on the Requests tab of this spreadsheet: https://docs.google.com/spreadsheets/d/1IJnlWvi4k-wFatDNimx9fQ375evHSIIxtGMookHvs-I/edit#gid=525257038 Two things Tania would like signoff on (besides the general concept) are: Any user who can access requests is allowed to add a note - the reasoning is that if they are allowed to see a request, they should be allowed to add a note to it to annotate the request with any info that might be needed by another staff person who may have higher permissions and can act on a note RESOLUTION: Anyone who views, adds, updates, or cancels a request should be able to add a note for internal staff use. Edit and cancel permissions can be tied to each other - right now in the back end they are using the same function. We could separate them but it would facilitate quicker development if the two functions don't need to be separately assigned. The subgroup thought this would be OK - does anyone know of a compelling reason to separate them? RESOLUTION: This is the first time we are deciding on permissions for Resource Access. We want the RA permissions to be consistent across all features–we want each permission to be separate: Edit and Cancel should not be together. Also, should not have an All permission. Instead, institutions will be combining permissions to make permission groups for various types of users. For example, a Requests Staff Supervisor roles would have Create, Edit, and Cancel combined into a group. There may be a Requests Student Supervisor role that can Create and Edit a Request but not Cancel it. Anya mentioned Cate's Permissions PowerPoint that we should look at. We will review this and then reconsider Tania's question.
5min	Display of cancellation reason	Holly Mistlebauer for Tania Hewes)	Display of cancellation reason + additional info on a cancelled request The full audit trail of what has happened to a request (changes in status, details of edits, cancellation, who did what and when, etc) is something we are working on for inclusion in a "Request actions" area of the request detail (similar to the Actions area of a Loan record). This will be handled by the change tracker, which is still under development. Request metadata (creation date/time, edit date/time) is already on the request record. While we wait for the change tracker to enable us to display a full list of Actions, we need a way to see the Cancellation Reason + any Additional Information that was entered during request cancellation. Tania has two primitive mockups of how the Request cancellation info might be displayed on a Cancelled request. Before she sends them for UX design, it would be nice to know if there is a consensus on which one is preferable. The subgroup favored one, but they didn't have a strong opinion. The mock-ups are below: RESOLUTION: All things equal, we prefer to see everything on one screen–prefer mock-up on the left. If it is extra overhead, more work, whatever, we can live with mock-up on the right.
15min	Data elements review (con't)	Emma Boettcher Cheryl Malmborg	https://docs.google.com/spreadsheets/d/1l8cuzfljiaTYkCP34nO_rR6dDNfrSWAw_XJSMuyagRw/edit#gid=579719430

Notes

Sharon Beltaine – IMPORTANT! Circ data migration questionnaire (due by Friday Sept. 14):

· Each institution needs to decide what historical circulation data from their current LMS must be migrated. Historical data is everything except current checkouts/requests. Please review the Historical data migration document in Google Docs and edit to indicate your library’s needs (label your responses with your institution’s name, or make a copy and upload to Google Docs). Talk with your colleagues! We will discuss this next week’s SIG meetings (Monday and/or Thursday). https://docs.google.com/document/d/19YmhThCILK8VZ1rYBSMPYJPdqbMxnPJNzIXqRQNuWpQ/edit

· There will not be a perfect one-to-one mapping from your institution's current system into FOLIO; how the data transfer will be done is not yet determined, but talk with your institution’s implementation team to be informed about how this is being planned

· Deb mentioned that for Cornell’s migration from NOTIS to Voyager (in summer 2000), a data dump of transactions in NOTIS was created for historical reference and backup

Holly Mistlebauer – user (FOLIO operator) request permissions:

· The group agreed that as a general principle for assigning permissions, functionalities should not be combined, which will give us maximum flexibility now and in the future as needs evolve

· Anya mentioned that there is a PPT from Cate B that illustrates how permissions are handled in FOLIO; we should review this

· If a request is cancelled it would be best to display the reason for the cancellation on the same screen as the other information relating to the request, but if the layout eats up too much real estate, we could live with clicking through for more information

Emma Boettcher – IMPORTANT! Gap analysis spreadsheet

· Please review the data elements Gap Analysis spreadsheet for circulation data, and if there are omissions, please indicate what those missing elements are. Each institution has its own column.

· Q: should data relating to a given transaction be static, even if elements associated with the item or patron changed? Discussion to be continued.