Reading Room Access
Submitted | Feb 6, 2024 |
---|---|
Approved |
|
Status | DRAFT |
Impact | medium |
Arch Ticket | |
Prod ticket |
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
Solution | Description | Pros | Cons | Decision | |
---|---|---|---|---|---|
1 | Reuse existing service points mechanism to serve as a reading room |
|
|
| Declined |
2 | Introduce a separate entity for the reading room |
|
|
| Target Solution |
Target Solution
Assumptions:
In LoC tenant structure the patron data is stored in the central tenant
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
Should the Security Officer log access on a patron entering and exiting events or only on entering the room?
>> Just entering. Also, LoC will not be collecting gate counts.
Can we use
user-type
for distinguishing Security Officer and Librarian roles?No, use permissions or Eureka roles for the purpose.