Page Comparison

...

As described in prod ticket:

...

• 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

• ModifiabilityExtensibility:

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

• Maintainability:

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

...

...

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

...

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.