Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

Sunflower -

Jira Legacy
serverSystem Jira
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-4993

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+.

#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.

...

  • 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 true/false). 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 = false" 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

#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.

...

  • Note: the 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).

...