Reading Room Access

Context

Context: The Library of Congress needs 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.

Requirements

Functional Requirements

As described in prod ticket: https://folio-org.atlassian.net/browse/UXPROD-4070

Non-Functional Requirements

• Security:

  • The solution should allow permission-based access to reading rooms for patrons

  • The solution should allow read-only access to patron records for security officers

• Extensibility:

  • The solution should allow extending the room access feature’s capability with additional functionality

• Maintainability:

  • The solution should be independent and loosely coupled as the FOLIO core modules do not include the feature.

Solution Options

Target Solution

Assumptions:

1. In LoC tenant structure the patron data is stored in the central tenant

2. In LoC the modules and UI related to Reading Rooms should be enabled for the central tenant only.

Context Diagram

FOLIO should provide the capability to allow access to individual reading rooms for a patron. Patron records can be represented in user records with Patron or Staff user type

Container Diagram

To provide loose-coupling and independent management for the solution it is required to introduce UI and backend modules to manage the list of reading rooms and patron permissions for reading room access. The mod-reading-room module should use patron information from mod-users through a synchronous interface (REST). To avoid circular dependencies on the modules it is necessary to listen to updates on patron records in an asynchronous way. Preferably to reuse existing Kafka topic where mod-users publishes information on update/insert/delete events.

The mod-reading-room module should be implemented as a microservice with a spring-way approach and multitenant nature of FOLIO in mind.

Component Diagram

The access verification component should provide a list of Reading Room permissions for the Security Officer. In case when no specific permission was set for a patron then the component should return the default access level for each reading room.

The access management component should provide a capability for FOLIO users to allow/restrict access to a particular reading room and ban a patron with a description of the reason for banning.

The access log management component should provide a capability for FOLIO users to view patrons' activity in reading rooms.

Entity Relationship Diagram

mod-reading-room requires the use of two external entities in the scope. Patron from mod-users and Service Point from mod-circulation-manager.

The relationship between the Service Point and the Reading Room is crucial to providing the ability for a Security Officer to choose a Service Point in UI and automatically detect which Reading Room is currently in use.

Permissions

The solution requires the creation/extension of the following roles:

• Security Officer. Allowed actions:

  • View patron permissions for reading room access

  • View/Create/Update “allowed” and “denied” events for access log

• Librarian.

  • View/Create/Update/Delete patron permissions for reading room access

  • View/Create/Update “allowed” and “denied” events for access log

  • View/Create/Update/Delete relation between Reading Room and Service Points

For LoC the creation/modification of roles should be implemented through Roles & Capabilities

For tenants with OKAPI, the related permissionSets should be created in FOLIO.

Eureka Support

The new modules included in the solution should support the “application” approach for LoC

Questions

1. Should the Security Officer log access on a patron entering and exiting events or only on entering the room?

   1. >> Just entering. Also, LoC will not be collecting gate counts.

2. Can we use user-type for distinguishing Security Officer and Librarian roles?

   1. No, use permissions or Eureka roles for the purpose.