Skip to content

Plans

Bundle modules into plans (subscription tiers) — superadmin only.

Overview

As in calServer V1, modules (permission groups) can be bundled into plans to model tiers of an installation (e.g. basic, premium). Management is — as in V1 — reserved for the hidden superadmin (hidden_super_admin) and lives under Administration → Users & Access → Plans.

Plan --> Modules (permission groups) --> Operations

How it works

  • A plan is a named tier with title, description and sort order.
  • Modules are assigned to a plan (action "Assign modules"). The assignment is stored V1-compatibly as comma-separated tokens in authitem_group.subscriptions — existing V1 assignments keep working unchanged after the migration.
  • A plan is activated per installation via the SUBSCRIPTION environment variable (identical to V1). When empty, no restriction applies at all.

Effect of an active plan

With SUBSCRIPTION set, users can only use operations of modules that belong to the active plan. The superadmin and directly assigned permissions are exempt; using_API (baseline access to the V2 API) is never blocked by design.

Multiple tokens = AND semantics

If SUBSCRIPTION contains several comma-separated values, a module must carry all of them to be active (V1 behavior).

Module contents (operations)

What a module consists of is visible via the "Modules & operations" dialog on the plans page: every module lists its RBAC operations with a readable title and description. Individual operations can be moved to a different module there (equivalent to V1's operation administration, authitem.group_uID).

Operations without a module

Operations not assigned to any module are collected under "No module" in the dialog. With an active plan they are blocked for users (V1 behavior) — assign them to a module.

The plan assignment dialog also shows each module's operation count; a tooltip lists the contained operations.

Migration from V1

During the V1→V2 import, existing subscription tokens from authitem_group.subscriptions are created as plans automatically (except the V1-internal QRCODE token of the QR portal). No manual rework is needed.

API

Endpoint Method Description
/api/v2/plans GET Plans incl. module assignment and active plan (meta)
/api/v2/plans POST Create plan (optionally with module_ids)
/api/v2/plans/{id} PUT Update plan (renaming migrates the tokens)
/api/v2/plans/{id} DELETE Delete plan (token is removed from all modules)
/api/v2/plans/{id}/modules PUT Set module assignment
/api/v2/plans/modules GET Modules incl. their operations (+ unassigned ones)
/api/v2/plans/operations/{name} PUT Move an operation to another module

All endpoints require the hidden_super_admin role.