feat: authorization dataset tiles

[nitrosx]

Description

Adds tile-level authorization to dataset detail page for fine-grained access control based on user group memberships.

Motivation

Enables administrators to control which user groups can view specific blocks/tiles in dataset details. Allows hiding s
ensitive metadata, creating group-specific views, and complying with data governance policies while maintaining backwa
rd compatibility.

Fixes:

• Moved authorization field in admin dashboard JSONForms schema from root level to individual customization items

Changes:

• Added authorization?: string[] to CustomizationItem interface
• Modified DatasetDetailDynamicComponent to filter tiles based on user access groups with canViewBlock() method
• Updated admin dashboard UI schema to support tile-level authorization configuration
• Added new header-5 color theme for consistent tile header styling
• Changed datasetView from static array to Observable reacting to user group changes

Tests included

• Included for each change/fix? No
• Passing? (Merge will not be approved unless this is checked) Tests need to be added

Documentation

• swagger documentation updated [required] N/A - Frontend-only feature
• official documentation updated [nice-to-have] Yes - docs/dataset-detail-block-authorization.md

official documentation info

Documentation file: docs/dataset-detail-block-authorization.md (812 lines, comprehensive)

Backend version

• Does it require a specific version of the backend? No
• which version of the backend is required: None - Frontend-only feature

AI contribution

• Changes created with Mistral Vibe
• PR message created by Mistral Vibe*

Summary by Sourcery

Introduce tile-level authorization for dataset detail tiles based on user access groups and update styling to use a new shared tile header theme.

New Features:

• Filter dataset detail tiles by user access groups using per-tile authorization metadata.
• Drive the dataset detail view from an observable so it reacts to changes in the current user's groups.
• Add a new shared tile header theme and class for consistent styling of dataset detail tiles.

Enhancements:

• Extend customization items with an optional authorization field to configure tile-level access control.
• Update admin frontend configuration schema and theme configuration to support tile-level authorization and the new header theme.

Documentation:

• Add comprehensive documentation for configuring dataset detail block/tile authorization.

[sourcery-ai]

Hey - I've left some high level feedback:

• The canViewBlock semantics for undefined vs empty authorization (defaulting to #all but treating [] as deny-all) are non-obvious; consider making this behavior explicit in the type/usage or using clearer sentinel values (e.g. ['#none']) to reduce configuration mistakes.
• Filtering sortedDatasetView in the component via datasetView$ on every userGroups$ emission couples authorization logic tightly to the UI; consider moving this filtering into a selector or a dedicated service to keep the component lean and make the logic easier to reuse and test.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `canViewBlock` semantics for undefined vs empty `authorization` (defaulting to `#all` but treating `[]` as deny-all) are non-obvious; consider making this behavior explicit in the type/usage or using clearer sentinel values (e.g. `['#none']`) to reduce configuration mistakes.
- Filtering `sortedDatasetView` in the component via `datasetView$` on every `userGroups$` emission couples authorization logic tightly to the UI; consider moving this filtering into a selector or a dedicated service to keep the component lean and make the logic easier to reuse and test.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Junjiequan]

I left few comments, would to hear you back what you think

[Junjiequan]

This could be removed by adding userGroups$ = this.store.select(selectProfileAccessGroups); on line 78

[Junjiequan]

Backend needs to be updated accordingly

[Junjiequan]

Is this condition intentional? that authorization: [] blocks all users from accessing the widget? In the admin panel, if we add an authorization group and then delete it, the frontend config JSON ends up with authorization: [], and nobody can access the widget, until it is changed to authorization: [#all].

I'm not sure which behavior is more intuitive

    if (auth.length === 0 || auth.includes("#all")) {
      return true;
    }

or return false when authorization is an empty array

[bpedersen2]

Yes, this seems inconsistent, arising from the fact that an empty array is "trueish" in js ( as opposed to e.g python), casing line +153 to pass on the empty array. I would adjust the code either map empty to "#all" or if possible handle it in the config setting to set it to undefined/null if all elements are dropped