Skip to end of banner
Go to start of banner

Lists App: Cross-tenant Queries

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Cross-tenant queries

The Lists app is adding initial support for cross-tenant queries as part of the Ramsons release as part of UXPROD-4566 - Getting issue details... STATUS . The specific functionality described on this page is only available in ECS environments.

Definitions

Term

Definition

Intra-tenant query

  • Defined as a query that relies on data within the local tenant, or, a query that relies on shared data (e.g. central instance records)

  • This is the equivalent of core Lists/FQM functionality in non-ECS environments

  • All queries in a member tenant are intra-tenant

  • Can occur in central tenant (for record types that don’t support cross-tenant queries)

  • ECS: can include shared data (e.g. shared instance records), but will rely on appropriate shadow records within the local tenant

  • Results are affected by the user’s app + content permissions in the active affiliation

Cross-tenant queries

  • Query that can include data from more than one tenant

  • Only supported from the Central tenant (you cannot query data from member tenant to another member tenant)

  • Users need the relevant tenant affiliations* and permissions to conduct these queries. Affiliation and permissions is needed for each tenant included in the cross-tenant query.

  • Cross-tenant queries will be limited to a subset of available entity-types in the initial release

  • Note: cross-tenant queries are only supported in ECS environments

Entities (record types) that support cross-tenant queries

Limited record types support cross-tenant queries as of the Ramsons release.

  1. Instance records

  2. Holdings records

  3. Item records

Cross-tenant query restrictions in the Lists app

  1. For the Ramsons release, lists with a cross-tenant query will be restricted to a single user (via ‘private’ visibility option). Important note: as of the Ramsons release, all lists of Instances, Holdings, or Items in the Central tenant will set to ‘Private’ visibility.

  2. Simplifies experience: no accounting for scenarios when users with different affiliations / permissions interact with the same list), and allows us time to gather user feedback

  3. An indicator that a List uses a cross-tenant query will be added to the Lists UI

[Add screenshots]

Permissions

In the context of ECS, Lists/FQM access is enforced at each member affiliation.

For an overview of Lists app permissions that were added as part of the Ramsons release, see https://folio-org.atlassian.net/wiki/x/YIAmIg

Lists app ECS permissions.png

Example of permissions based on user affiliations + app permissions + content permissions

  1. The table below reflects the permissions for a single user in an ECS environment. Each row reflects the access the user has within the context of a given tenant.

  2. When the Central tenant is the active affiliation (Row 1): this user can access the Lists app and:

    1. make lists of Instances, Holdings, and Item records that exist in the Central tenant

    2. make lists of Instances, Holdings, and Item records that exist in Member tenant A (cross-tenant queries)

    3. notes:

      1. No other record types are available due to the content permissions

      2. Data from Member Tenant B won’t be returned in cross-tenant queries because the user lacks Lists app permissions from that tenant (and therefore the data won’t be returned)

  3. When Member Tenant A is the active affiliation (Row 2), this user can access the Lists app and make lists of Instances, Holdings, and Items records that exist within Member tenant A.

    1. note: while Member Tenant B is the active affiliation, the user cannot query records from the Central tenant

  4. When Member tenant B is the active affiliation (Row 3), the Lists app won’t be visible (because the user lacks permissions), and no data from this tenant can be returned in queries

  5. The user doesn’t have an affiliation for Member tenant C (row 4), so it will never be an active affiliation, and it’s data cannot be returned in queries

Tenant

Tenant affiliation

Lists app permissions

Content permissions

Outcome - Access to data from this tenant?

1

Central Tenant

✅ Tenant affiliation

✅ App permissions

✅ Instances, Holdings, Items

✅ Access to Lists app/ FQM in the Central tenant for Instances, Holdings, Item record types

2

Member Tenant A

✅ Tenant affiliation

✅ App permissions

✅ Instances, Holdings, Items

✅ Access to Lists app/ FQM in Member tenant A for Instances, Holdings, Item record types

3

Member Tenant B

✅ Tenant affiliation

❌ App permissions

✅ Instances, Holdings, Items

❌ No access to Lists app / FQM in Member tenant B (or data from it)

4

Member Tenant C

❌ Tenant affiliation

N/A

N/A

❌ No access to Lists app / FQM in Member tenant C (or data from it)

  • No labels