Overview

This page contains notes and proposed solutions for optimizing the Users UI App in the context of Secure Requests functionality.

Color legend for the scope proposed for releases Ramsons, Sunflower, Trillium+.

Concerns and Proposed Solutions

#1 Unoptimal UX of the Users UI App due to too many user records

Problem statement: Having many User records that look almost identical makes it difficult to work with the UI application.

Solution:

• Ramsons

  • Set the User record status to Inactive after the loan is closed

• Sunflower

  • Add a "Staff suppress" field to the user record schema (boolean, possible values on UI yes/no). When creating records for Fake Patron, this field should be true. The Users UI App should add a facet for selection and filtering. The filter "Staff suppress = no" is selected by default

  • Note: The logic and behavior are similar to how the Inventory UI App handles the "Staff suppress" and "Suppress from discovery" flags

  • Note: Data migration is not planned

  • Note: the flag of suppression can be re-used in situations where User records would need to be hidden from the Users UI App by default

Image Removed

Image Added

#2 The ability to edit records about fake patrons is not desirable

Problem statement: The Fake Patron entry in the Central tenant is a one-time entry in the current design and is essentially auxiliary. Therefore, editing it does not make sense. In addition, we would like to disable editing it to eliminate the possibility of any fraud based on it.

Solution:

• Sunflower

  • Add a new, scenario-specific type of user record (for example, Hidden, Secure Patron, or Obfuscated - an agreement on the optimal name is pending), and do not show the Actions menu for User records with this type

  • For your reference: The user record includes a field that determines the type of the record. The possible values at the moment are Patron, Staff, Shadow, System, DCB (see https://github.com/folio-org/mod-users/src/main/java/org/folio/domain/UserType.java)

• Note: this user type should be scenario-specific

#3 The growth of the mod-users database due to the accumulation of User records

Problem statement: Since the Fake Patron entry in the Central tenant is a one-time entry in the current design, a new user record is created for each real request. Consequently, this leads to a continuous accumulation of records in the mod-users module table. Depending on the frequency of use and number of requests over a prolonged period, this may have negative consequences - growth in database size and its cost, slowing down database operations (insertion, search), and, as a result, slowing down the performance of the Users UI App (though it should be noted that the performance decline might be a gradual process).

Solution:

• Trillium+ - there are some options described below; the analysis and decision is pending though

  • Split the user data into 2 parts - operational and archive, and move such records into an archive after some period (though this doesn’t solve the problem of overall data volume)

  • Use a Single fake patron for all the requests - Could there be problems with the limits on the number of requests/loans? Is it possible to bypass them?

  • Implement a reusable pool of fake patrons with no correlation to real congressional patrons

  • Implement a safe mechanism for deleting user records - this is a separate topic and a separate big task for FOLIO

  • Adopt the functionality of requests/loans anonymization and remove of Fake Patron records after request/loan anonymization

 T-shirt estimates

• Sunflower

  • FE - 10 SP

    • This estimate is based on the assumption that the behavior of the Inventory UI App in handling the flag can be replicated in the User UI App. A spike task is needed to investigate how the Inventory UI App handles the "Staff suppress" flag - depending on the results, the estimate may increase

  • BE - 10 SP