Skip to content

Module Permission Token

The module permission token is a JWT (JSON Web Token) provided to a module by the HortiView platform during module initialization.

It is used for frontend permission handling only:

  • Masking or showing UI content
  • Enabling or disabling actions (for example buttons)
  • Controlling whether components are rendered

It represents the module permissions of the active user, derived from the user's organization-level role in the main platform.

Unlike the main platform permission token, this token is focused on module context and currently contains organization-level scope only (no farm-location split).

Required UI behavior for actions

This is mandatory for all module developers:

  • If an action is temporarily unavailable (for example no internet connection or license limits), the button must be shown but disabled.
  • If an action is not permitted by user permissions, the button must not be rendered.

Token Handling in Modules

  1. The platform injects modulePermissionToken into module base properties.
  2. The module stores and reads it (for example via useBasePropsStore).
  3. The permissions by organizationId are extracted from the token using getPermissionsFromModulePermissionToken (Shared Repo).
  4. The permissions are passed to the SharedComponentsPermissionProvider to be available in all permission guard components.

Structure of the Module Permission Token

For permission logic, the relevant parts are grouped as follows:

1) Identity Claims (Informational)

Fields such as name, givenname, surname, emailaddress, userGuid, and nameidentifier identify the user.

These claims are useful for context but do not define module permissions by themselves.

2) ModuleRolesAndPermissions (Permission Core)

This object defines the effective permission scope for the module:

  • FarmOrganizationId: Organization scope of the token.
  • UserId: User identifier inside the permission scope.
  • ModuleId: Module for which this token is issued.
  • RoleNames: Module roles (for example SeasonReader).
  • ExecuteEndpointPermissionNames: Allowed action permissions (for example season-read).
  • DataAreaEndPointPermissionNames: Allowed data area groups (for example FarmOrganization).

For more information about custom module roles see also: Custom Roles and Entities