Skip to main content
Version: 🚧 Next

Filters

A scope normally applies to all records of its namespace. A filter limits a scope to the records that match it, for example only dossiers with a high RBA rating.

:::danger Use filters sparingly

Only add a filter when you have a clear reason for it, and check first that no other configuration does the same, such as assigning a role only for a specific FSP, or forRoles on status transitions and bulk actions.

Filters come at a cost:

  • A role with a filter only fits users who need exactly that restriction, so the role is harder to reuse.
  • Filters refer to values from your configuration, such as dossier types, document types or metadata fields. When those values change, for example when you add a dossier type, you have to update the filters yourself: the application cannot know whether the new value should be included, while most other configuration keeps working without changes.

:::

Configuration​

Instead of the empty object that switches a scope on, give the scope one or more filters:

{
"fsp": {
"dossier": {
"permissions": {
"read": {
"dossierFilter": {
"rbaRatings": ["HIGH"]
}
}
}
}
}
}

This role can only read dossiers with RBA rating HIGH, and everything in them.

Which filters a scope takes depends on its namespace. The Permission reference shows them, and their fields, for every scope. Fields with relative dates use the relative datetime format, and metadata conditions follow the metadata filter structure.

Matching​

  • A record must match every field you set.
  • For a list, one matching value is enough. Relative dates and metadata conditions are the exception: all of them must match.
  • When a scope has several filters, such as a dossierFilter and a documentFilter, the record must match all of them.
  • When several roles allow the same action, one matching role is enough.

Inheritance​

Filters are passed down together with their scope. A dossier filter on dossier therefore also limits the documents, bank accounts and due diligence results that the user can read.

Give each filtered scope its own role​

To keep roles simple, put each filtered scope in a role of its own, without any other scopes. Give the user the rest of their access through other roles.