Skip to content

Modules (Admin)

The Modules registry defines feature keys (e.g. item) that roles reference. Non–Master admins (modules is an array) cannot mutate registry entries—UI disables those actions.


GoalsNon-goals
Explain registry vs role modules JSONChange backend guard keys without code deploy
Document list/detail routesList every module row in every environment

  • Roles store modules: string[] | nullnull means all modules (Roles).
  • Registry CRUD is disabled in the UI unless the admin JWT has modules === null (Master) (Admin overview).

  1. Master admin opens Modules → reviews keys and metadata.
  2. Aligns new feature work with a module key → updates Roles to grant keys to appropriate roles.

  • Treat module keys as contract with backend guards—coordinate releases when adding keys.
  • Avoid duplicate keys; document in changelog when adding a new module.

IDScenarioExpected
MD1Role-limited admin opens ModulesMutations disabled or API 403
MD2Master admin edits registryPersists if API allows
MD3Role without new keyFeature APIs return 403

PathPurpose
/dashboard/modulesModule list
/dashboard/modules/:idModule detail

Roles store a JSON modules array (or null for full access). Each entry is a string key the backend guards check (for example catalog item). The Modules screen maintains the registry of module records that correspond to those keys.

See Roles (Admin) for JWT modules semantics.

  • Search — debounced, paginated list via fetchAdminModulesList.
  • Create / edit — modal form; navigation can pre-open edit or delete via router location.state (editModuleId, deleteModuleId, etc.).
  • Delete — confirmation modal, then deleteAdminModule.

The page sets canMutate when profile.modules == null (Master admin). If modules is an array, canMutate is false: create, edit, and delete affordances for the module registry are disabled. All admins can still view lists when the API allows.