/
Expectations for querying user records in ECS

Expectations for querying user records in ECS

This diagram of user affiliations can be used to help identify what records will be returned (based on what context the user queries are from).

Note: the same diagram has been inserted in each section for easy reference.

image-20250715-182916.png

Expected results:

  1. Records returned when querying Users from the Central tenant........................... 1

  1. Records returned when querying Users from the Secure tenant........................... 2

  1. Records returned when querying Users from Data tenant A................................. 3

  1. User definitions........................................................................................... 4

  

1.    Records returned when querying Users from the Central tenant

Assume the user has required affiliations and permissions

image-20250715-183015.png

 

Record (Queried from Central tenant)

FQM/Lists

Users app

1

Staff users with a primary affiliation of Central tenant

·         Staff user 1

·         Staff user 2

·         Staff user 3

True

True

2

Staff users with a primary affiliation of a member tenant

·         Staff user 4

·         Staff user 5

·         Staff user 6

True*

*Limited data

True*

*Limited data

3

Patron users with a primary affiliation of Central tenant

·         Patron user 1

True

True

4

Patron users with a primary affiliation of a member tenant (either Secure or A)

·         Patron user 2 (Secure)

·         Patron user 3 (Tenant A)

False

False

*In cases where “Limited data” is noted, the record that’s being returned is a shadow user. Shadow users contain a limited amount of fields/data

 

2.    Records returned when querying Users from the Secure tenant

Assume the user has required affiliations and permissions

image-20250715-183137.png

 

Record (Queried from Secure tenant)

FQM/Lists

Users app

1

Staff users with a primary affiliation of Central tenant + affiliation in Secure tenant

·         Staff user 1

·         Staff user 2

True*

*Limited data

True*

*Limited data

2

Staff users with a primary affiliation of Central tenant but without affiliation in Secure tenant

·         Staff user 3 (Central)

False

False

3

Staff users with a primary affiliation of Secure tenant

·         Staff user 4

True

True

4

Staff users with a primary affiliation of a member tenant A + affiliation in Secure tenant

·         Staff user 5

True*

*Limited data

True*

*Limited data

5

Staff users with a primary affiliation of a member tenant A but without affiliation in Secure tenant

·         Staff user 6

False

False

6

Patron users with a primary affiliation of Central tenant

·         Patron user 1

False

False

7

Patron users with a primary affiliation of Secure tenant

·         Patron user 2

True

True

8

Patron users with a primary affiliation of member tenant A

·         Patron user 3

False

False

*In cases where “Limited data” is noted, the record that’s being returned is a shadow user. Shadow users contain a limited amount of fields/data

 

 

3.    Records returned when querying Users from Data tenant A

Assume the user has required affiliations and permissions

image-20250715-183240.png

 

Record (Queried from Data tenant A)

FQM/Lists

Users app

1

Staff users with a primary affiliation of Central tenant + affiliation in data tenant A

·         Staff user 1

True*

*Limited data

True*

*Limited data

2

Staff users with a primary affiliation of Central tenant but without affiliation in data tenant A

·         Staff user 2

·         Staff user 3

False

False

3

Staff users with a primary affiliation of Secure tenant

·         Staff user 4

False

False

4

Staff users with a primary affiliation of a member tenant A + affiliation in Secure tenant

·         Staff user 5

True

 

True

5

Staff users with a primary affiliation of a member tenant A (with or without other affiliations)

·         Staff user 6

True

True

6

Patron users with a primary affiliation of Central tenant

·         Patron user 1

False

False

7

Patron users with a primary affiliation of Secure tenant

·         Patron user 2

False

False

8

Patron users with a primary affiliation of member tenant A

·         Patron user 3

True

True

*In cases where “Limited data” is noted, the record that’s being returned is a shadow user. Shadow users contain a limited amount of fields/data

 

4.    User definitions

  • Primary affiliation: home tenant of user. Identifier of the tenant of a primary user. Upon login, the user’s primary affiliation is set to active

  • Active affiliation: current tenant with which folio actions are performed. Always displayed in the main navigation bar

  • Primary user: user account created in the active affiliation tenant. Acts as a primary link to shadow users in other tenants

  • Staff: users employed by a library and must log into folio to conduct library work. Staff accounts are assigned a primary tenant and a unique username. If the staff account is associated with multiple tenants, the username is used to log in at a single service point.

  • Patron: users who borrow library items. Patrons have user records in the users app, but do not log into folio to manage library accounts. They are assigned a primary tenant only, and do not have any assigned affiliations or user permissions for other tenants in the consortium.

  • Shadow: shadow accounts serve as a representation of a user record and are automatically created by the folio system. Shadow accounts display a user’s assigned permissions for a member tenant and allow management of permissions for the user records outside of the central tenant. If an affiliation is removed, the shadow account becomes inactive. If the staff user is deleted from their primary tenant, all the user’s shadow accounts are also deleted from the member tenants.

    • When additional affiliation(s) are added to staff users, a shadow user is automatically added to each non-primary tenant affiliation

      • In the diagram Staff user 1 has a primary affiliation of the Central tenant. Staff user 1 has shadow users in the Secure tenant, and in data tenant A).

    • When the primary affiliation of staff user is a member tenant (the user was created in a member tenant), a shadow user is automatically added to the central tenant.

      • In the diagram Staff user 4 has a primary affiliation of the Secure tenant. Staff user 4 has a shadow user in the Central tenant.

    • Example with both:

      • In the diagram, staff user 5 has a primary affiliation in data tenant A, and shadow users in the Central tenant, and in the Secure tenant

 

Data in user Shadow records

These records contain limited data:

  • Last name

  • First name

  • User UUID

  • Active

  • Email

  • Preferred contact type

  • Type (i.e., shadow)

  • Record metadata:

    • Updated by user UUID

    • Updated date

    • Created by user UUID

    • Created date

  • Username*

    • Shadow users have an underscore and random string appended to the username e.g., Staff: username

    • Shadow: username_kcqo

  • Patron group*

    • This is the patron group of the shadow user, which is independent from the patron group of primary staff user. The patron group of the primary staff user is not visible in the shadow record.

  • Address*

    • This is the address of the shadow user, which is independent from the address of primary staff user. The address of the primary staff user is not visible in the shadow record.

 

 

In this screenshot:

The primary staff affiliation for this user is the College tenant. The left window is the Users app in the Central tenant and shows the shadow user. The right window is in the College tenant and is the staff user. Some of the info is the same between the records (I outlined in green), but most of the fields from the staff user aren’t part of the shadow user. This screenshot cuts off many of the additional data sections but gives you an idea of some of the differences.

 

image-20250715-183851.png