Users App (UXPROD-784)

[UXPROD-4070] Reading Room Access Created: 16/Feb/23  Updated: 07/Feb/24

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: Ramsons (R2 2024)
Parent: Users App

Type: New Feature Priority: P2
Reporter: Anne Ekblad Assignee: Tim Auger
Resolution: Unresolved Votes: 0
Labels: LC-priority2, SolutionArchitecture, loc, patronreg
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File ReadinRoomAccessUserEdit.png     PNG File ReadingRoomAccessApp.png     PNG File ReadingRoomAccessSectionUserRecord.png     PNG File ReadingRoomCheckout.png     PNG File ServicePointReadingRoom.png    
Issue links:
Defines
defines UX-529 Mockups for Reading Room Access Draft
is defined by MODUSERS-429 Spike: [UXPROD-4070] Reading Room Acc... In Progress
Relates
relates to UXPROD-4054 Indicate if a shelving location is op... Open
relates to UXPROD-36 Profile pictures In Progress
relates to UXPROD-3988 LC Reader Registration Data Flow Draft
relates to UXPROD-1835 Reading Room Feature Draft
Release: Ramsons (R2 2024)
Epic Link: Users App
Front End Estimate: XL < 15 days
Front End Estimator: Khalilah Gambrell
Front-End Confidence factor: 20%
Back End Estimate: XXL < 30 days
Back End Estimator: Khalilah Gambrell
Back-End Confidence factor: 20%
Development Team: Volaris
PO Rank: 0
Rank: Cornell (Full Sum 2021): R3

 Description   

Context: Library of Congress need this feature but it may be useful for other libraries.  The solution should be designed in such a way that it would be useful to any library with this need

Current situation or problem:  The Library of Congress has ~25 reading rooms.  Patron access to these rooms isn't contingent on whether or not they have requested something to read there - some rooms are open to most patrons while others can be accessed only by patrons with special permissions.  FOLIO needs to have a mechanism for recording which reading rooms patrons are allowed to access so that staff know who to allow/disallow from the room.

In scope

  • Staff can record/store which reading rooms a user has access to
    • Some reading rooms are allowed by default for all new library card holders (may be default setup in settings)
    • Others are allowed later (after reference librarians have had the opportunity to interview the patron)
  • Staff can pull up user record when patron arrives at reading room (either by scanning card or searching user).  Some reading rooms have security officers who will be responsible for this.  Others will only have reference librarians.
  • Pulling up the user record will enable:
    • View (security officers and reference librarians):
      • Reading room name
      • Users name
      • Users barcode
      • Whether a user is allowed when they arrive at the reading room
      • Profile picture
      • Whether or not a note is present
      • Reading room access history statistics?
    • Edit (reference librarians only):
      • Whether user is allowed/disallowed based on discression
      • Whether user is banned from reading room
      • Note about user access to the reading room
  • After pulling up a patron record, register (in mod-audit?) whether they were admitted or denied so the LC can generate reports (maybe in Circ log, FRM and/or Panorama) on reading room usage

Out of scope

  • Reader registration app UXPROD-3988
  • Profile pictures UXPROD-36 
  • Reading room request and loan functionality
  • Reporting on reading room usage

Use case(s)

Proposed solution/stories
*NOTE: The solution needs to be compatible with a multi-tenant environment and planned architecture for LC.
*This functionality needs to be optional, as many FOLIO implementers won't need it.  Could manage with a configuration in Settings or, perhaps, a permission (so if your institution doesn't use this feature, you just don't give anyone permission to see it).

  • Reading room access should be tied to the user record in Users and possibly also to the pre-registration record in Reader Registration app 
  • Could relate to the Users record and display in an accordion similar to Proxy/Sponsor?

Links to additional info

Questions

  • Should we leverage the Check-out app for the scan/lookup user workflow? NO - see below
    • Would need to add profile pictures to check-out app (which is desired anyway per comment on UXPROD-36 ) 
    • Would also need to display the reading room access along with the Borrower information on the left
      • Displaying a table of 25 reading rooms doesn't seem like it would be a good user experience
      • But, if reading rooms were a kind of service point, you would only need to display whether the patron had access to the selected reading room/service point (e.g. "<READING ROOM SP NAME> ACCESS ALLOWED" or '<READING ROOM SP NAME> DISALLOWED"
      • Reading room access note, if present
    • Current thinking is that we should not try to leverage the check out app and, instead, create a  dedicated Reading room access app because:
      • Reading room access app should capture transactions like "patron admitted", "patron denied" plus cancel option.  Really want these transactions for reporting on visits.
      • Security officers who need to check access shouldn't have access to check out functionality
      • Having a completely separate app makes it easier to turn off for the institutions that don't need it
  • Should reading rooms be service points? YES   
    • Perhaps, when setting up SPs, you can check to indicate they are a reading room 
    • SPs that are reading rooms show up in the access table on the user record
  • Can reading room staff have view and or edit access to the user record?  The whole thing or just the reading room access?
    • Security officers just check access and shouldn't have access to whole user record but they also don't need access because they aren't editing record to indicate that the patron should be given access (they will direct patron to speak with reference librarian for that)
    • Reference librarians are probably fine with access to view/edit the basic user record (may  want to disable the loans and/or requests permissions for some staff).
  • Is having a single note per-reading room sufficient or are multiple notes required?


 Comments   
Comment by Erin Nettifee [ 21/Feb/23 ]

Cate Boerema how does this relate (potentially) to UXPROD-1835 Draft ? That has been open for a long time with several libraries desiring the features detailed there.

Comment by Cate Boerema (Inactive) [ 28/Feb/23 ]

Hi Erin Nettifee!  I see UXPROD-1835 Draft as covering circulaton in a reading room.  It's an important feature, but different from this one. 

This feature is narrowly focused on tracking and controlling whether or not a patron is allowed into a reading room.  At the LC, patron access to reading rooms isn't contingent on whether or not they have requested something to read there - they are given blanket access.  Some rooms (like the main reading room) are open to anyone with a library card.  Access to other reading rooms is determined by librarians based on interview with the patron. 

This feature is not an alternative to something like UXPROD-1835 Draft .  I think they could work together (and may need to for the Library of Congress). 

Hope that makes sense! 

Comment by Thomas Trutt [ 09/Mar/23 ]

Cate Boerema Question. So your desired behavior would be that this could almost be like a circulation rule in that all patrons with the user type of X would have access to a reading room. But also that staff could give access to a reading room ad hock. 

This is an interesting request. Cornell does have some reading rooms in one of our units and currently we use SPEC cards and other list to manage them. This may be an interesting alternative to that system. I feel UXPROD-1835 Draft is closer to a feature that was in Voyager, which we never used. I can see the difference. UXPROD-1835 Draft is more about reserving reading lists, and this is more about the management of a physical space that happens to hold materials. 

I would argue though that these spaces should not be service points. Service points are an oddity as they are not really tied to a locations they just kind of float out there in FOLIO space. Because of this i feel rooms may make more sense as an extension of locations. Locations are used to hold materials as then are tied to service points that receive the materials for those belonging to those locations. I feel an expansion of the location object to include a 'restricted use' flag and then a usage list would actually meet your needs. I can also see this being a feature that would be used by other libraries that have similar reading rooms. Also since Locations are already in circulation rules it may be possible to add a rule to allow a patron group access.. again this means added a flag in one of the policies somewhere but i feel its more in line with the current FOLIO architecture. 

Comment by Erin Nettifee [ 15/Mar/23 ]

Just to mention with Thomas's comment, there is a feature out there - UXPROD-4054 Open - meant to indicate if a location is closed to patrons, and so how that would work if a service point also potentially had restricted access should be thought through.

I'm not sure I agree with leveraging locations for this instead of service points, but I think it's worth also considering whether a new data object is needed for "reading room" instead of trying to extend an existing object. I'm thinking of that in light of knowing that both service points and locations are embedded in Inventory, so if you continue extending those models, you are assuming libraries will use the Inventory modules. Makes total sense for LoC, but if you had a library that wanted to use FOLIO but integrate with another system for inventory management, or even just a different version of Inventory, you introduce a lot of complexity. IMO it's better to not build in an additional dependency there.

Comment by Thomas Trutt [ 15/Mar/23 ]

Erin Nettifee Thanks. I was looking at this form Cornell's use case as well. We have Carrels in one of our units that house research and study materials selected by faculty members. Our current solution is to check out all the items to a SPEC card and have a physical list at the desk that is checked when the key is requested. 

In my mind extending the locations object to include this as well as UXPROD-4054 Open made sense as the items are moved, if even temporary, to a new location. Similar to moving items to a reserves location.

That said and taking in consideration you point you made, of what if a library uses a different inventory system i can see where breaking this aport from inventory/service points makes sense. However I would purpose this. Add a flag to locations to allow the indication that its restricted; this could just be an indicator as suggested in UXPROD-4054 Open . Add a new authorized users app. If written generally enough it could be used for this case but also material types, maybe electronic records etc. What I'm thinking is a list of users and/or patron types and the resources they are allowed to access.

Comment by Erin Nettifee [ 15/Mar/23 ]

I think you're talking about good needs but they are potentially separate features and should go to the SIG for discussion, rather than try to expand this feature. In the context of the reading room, they don't need to do things like manage material type access, they need to manage access to a specific space.

Comment by Charlotte Whitt [ 02/May/23 ]

Hi Andreas Mace - I added you as watcher on this feature

Generated at Fri Feb 09 00:37:02 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.