Summary
The GUI page-registration layer (aignostics_foundry_core/gui/auth.py) has no access level for internal org + superadmin role, even though the API layer already provides the equivalent (require_internal_superadmin / create_internal_superadmin_router, gating on AUTH0_ROLE_SUPERADMIN).
As a result, a module whose REST surface is gated at superadmin cannot gate its NiceGUI pages at the same level. page_internal_admin is not a usable substitute: _actualize_internal_admin does a scalar equality check role != AUTH0_ROLE_ADMIN ("admin"), and since admin and superadmin are disjoint single-value roles, a superadmin user is actively rejected by it.
Current state
AccessLevel (gui/auth.py) tops out at:
PUBLIC, AUTHENTICATED, ADMIN, INTERNAL, INTERNAL_ADMIN
with matching decorators page_public / page_authenticated / page_admin / page_internal / page_internal_admin and actualize functions. There is no INTERNAL_SUPERADMIN.
Meanwhile api/auth.py already defines AUTH0_ROLE_SUPERADMIN = "superadmin" and require_internal_superadmin (internal org membership AND superadmin role), and api/core.py exposes create_internal_superadmin_router + API_TAG_INTERNAL_SUPERADMIN.
Requested change
Add a GUI equivalent, mirroring the existing internal_admin implementation:
AccessLevel.INTERNAL_SUPERADMIN
_actualize_internal_superadmin — identical to _actualize_internal_admin but checking role == AUTH0_ROLE_SUPERADMIN (reuse the constant already exported from api.auth)
page_internal_superadmin(path, title=None) public decorator writing the registry entry
- entry in the
actualize_map in process_page_registry
- export from
gui/__init__.py + __all__
- tests mirroring the
page_internal_admin coverage (no session → redirect; wrong org or wrong role → 403 label; internal + superadmin → page renders)
Motivation / consumer
aignostics/pviz is adding a read-only integrations status dashboard (VPTHP-46) whose REST counterpart is already gated with require_internal_superadmin. To keep the GUI and API at the same authorization level, pviz needs a superadmin GUI guard.
Interim: pviz will ship a local guard (register pages via @ui.page and replicate the org+superadmin-role check inline) and migrate to page_internal_superadmin once this lands.
This is a general framework gap — any Foundry component with a superadmin-gated GUI page hits it.
Summary
The GUI page-registration layer (
aignostics_foundry_core/gui/auth.py) has no access level for internal org +superadminrole, even though the API layer already provides the equivalent (require_internal_superadmin/create_internal_superadmin_router, gating onAUTH0_ROLE_SUPERADMIN).As a result, a module whose REST surface is gated at superadmin cannot gate its NiceGUI pages at the same level.
page_internal_adminis not a usable substitute:_actualize_internal_admindoes a scalar equality checkrole != AUTH0_ROLE_ADMIN("admin"), and sinceadminandsuperadminare disjoint single-value roles, asuperadminuser is actively rejected by it.Current state
AccessLevel(gui/auth.py) tops out at:with matching decorators
page_public / page_authenticated / page_admin / page_internal / page_internal_adminand actualize functions. There is noINTERNAL_SUPERADMIN.Meanwhile
api/auth.pyalready definesAUTH0_ROLE_SUPERADMIN = "superadmin"andrequire_internal_superadmin(internal org membership AND superadmin role), andapi/core.pyexposescreate_internal_superadmin_router+API_TAG_INTERNAL_SUPERADMIN.Requested change
Add a GUI equivalent, mirroring the existing
internal_adminimplementation:AccessLevel.INTERNAL_SUPERADMIN_actualize_internal_superadmin— identical to_actualize_internal_adminbut checkingrole == AUTH0_ROLE_SUPERADMIN(reuse the constant already exported fromapi.auth)page_internal_superadmin(path, title=None)public decorator writing the registry entryactualize_mapinprocess_page_registrygui/__init__.py+__all__page_internal_admincoverage (no session → redirect; wrong org or wrong role → 403 label; internal + superadmin → page renders)Motivation / consumer
aignostics/pvizis adding a read-only integrations status dashboard (VPTHP-46) whose REST counterpart is already gated withrequire_internal_superadmin. To keep the GUI and API at the same authorization level, pviz needs a superadmin GUI guard.Interim: pviz will ship a local guard (register pages via
@ui.pageand replicate the org+superadmin-role check inline) and migrate topage_internal_superadminonce this lands.This is a general framework gap — any Foundry component with a superadmin-gated GUI page hits it.