Message Popups Permissions and Masking

The message popup does not only apply route-level access. It also applies tag-scope and resource-level masking per flow.

Permission layers

authenticated API access through IsAuthenticatedRoleAware
tenant visibility through config access checks
tag-scoped flow visibility through apply_tag_scope_to_message_qs
resource-specific restrictions through blocked_flow_ids_for_resource

Resource types

Two restricted resource categories are explicitly handled in the current code:

Resource	Effect when blocked
`payloads`	payload metadata may be masked, payload download is blocked
`custom_headers`	header values are replaced by `***`

Masking behavior

Message list masking

When custom headers are restricted:

header names may remain visible
header values are replaced with ***
restricted_resources includes custom_headers

Detail masking

In message detail:

header_properties are replaced by masked values when header access is blocked
restricted_resources is returned explicitly
payload access is tracked independently from header access

Payload masking

When payload access is blocked:

payload metadata can still be listed
each row is marked with masked: true
raw download is denied through the download endpoint
restricted_resources includes payloads

Visibility source

Flow visibility and resource restrictions are derived from tag and access-group logic in tag_scope.py, including:

explicit iFlow tag assignments
package-derived visibility inheritance
per-resource blocked-flow resolution

Example outcomes

Situation	Result
user cannot see flow at all	message rows disappear from scoped queries
user can see flow but not payloads	message row is visible, payload metadata is masked, payload download denied
user can see flow but not custom headers	message row is visible, headers are replaced with `***`

Why this matters

A user can have enough access to review operational message state without having enough access to inspect the most sensitive technical payload or header content.