Umbrella actions & admin

Umbrella actions

Some actions, called umbrella actions in this documentation, automatically imply other actions. This exists to ease management. Functionally, granting a permission on an umbrella action has the exact same effect as granting them to each of its implied actions.

Examples of umbrella actions and their implications

Project umbrella actions:

• read_project implies:

  • read_project_info

  • read_project_readme

  • list_project_samples

  • view_project_assets

  • And more...

Analysis umbrella actions:

• read_analysis implies:

  • read_analysis_info

  • open_analysis

  • read_analysis_result

  • And more...

Write umbrella actions:

• write_project implies:

  • write_project_info

  • write_project_readme

  • manage_project_samples

  • create_project_analysis

  • And more...

Automatic inclusion: If Panomics adds other actions, and they are added under an already existing umbrella action, they will be implied automatically.

The admin action

admin is special as it implies all actions (only relevant for actions on the resource it's applied to and its children) and cannot be denied.

Key characteristics:

• Implies all actions on the resource and its children

• Cannot be denied - once granted, it cannot be overridden

• Can be granted on children only via the Child Resource Permissions section

• When granted in the Child Resource Permissions section, it only applies to the children, not the parent

Design Intent: Actions are split between resource types (e.g., read_project_info vs read_analysis_info) and umbrella actions (read_project vs read_analysis) intentionally. This avoids accidentally granting read access to a parent without meaning for it to be inherited and applied to its children. With actions having specific resource and verb verbiage, every grant is intentional and precise.