Deployment and application capabilities
Meratyn has two deliberately separate authority contracts. Deployment capabilities describe what a hosted installation is willing to expose at all; application roles and privileges describe what a person, workspace, or embed host may do inside that deployment. Neither contract is a replacement for authentication or the authorization rules of a backing service.
Deployment policy
MAPPVIEW_CAPABILITIES is an optional comma-separated policy read by the web
runtime and the processing sidecar. The supported deployment capabilities are:
| Value | Governs |
|---|---|
project:edit | Project editing commands and project-owned changes |
data:add | Add Data sources |
processing:run | Processing commands |
export:data | Data and project export commands |
plugins:install | Plugin installation and admin |
settings:manage | Settings and style-manager changes |
When the variable is absent or blank, the deployment keeps the full local
default. none grants no deployment capabilities. Other values are trimmed
and deduplicated; unknown values are ignored, so an explicit unknown-only value
fails closed. The command palette and keyboard shortcuts apply the same policy
as the visible menus, and execution checks it again to prevent a stale command
from bypassing the deployment boundary.
Processing that uses the Python sidecar requires the deployment’s
processing:run capability and a sidecar-specific processing:sidecar
application privilege. The sidecar also checks its deployment policy and
returns HTTP 403 before dispatch when processing is not allowed. This is a
deployment-wide control, not a per-user access check.
For Docker, publish the value to both the Vite runtime configuration and the sidecar environment. Desktop and embedded deployments use the same runtime contract. Kiosk and classroom layouts can continue to use UI profiles for presentation, combined with this policy for authority.
Application roles and privileges
The application capability store starts with the administrator role unless a
host supplies another policy. Built-in roles are:
| Role | Included privileges |
|---|---|
viewer | export:data, export:image |
editor | Save projects, add local/remote layers, edit layers, run client processing, and export data/images |
publisher | Editor privileges plus project sharing (including public links), sidecar processing, and assistant use |
administrator | Every application privilege |
custom | Empty until a host grants individual privileges |
The individual privilege names are project:save, project:share,
project:share-public, layers:add-local, layers:add-remote, layers:edit,
processing:run, processing:sidecar, export:data, export:image,
plugins:install, assistant:use, connections:manage, settings:manage,
embed:access, and scripting:execute. A host may intersect policies, grant
or revoke one privilege, and attach a privacy-safe denial reason to that
privilege. Selecting a built-in role replaces ad-hoc grants and stale reasons.
Menus and the command palette omit actions that the current application policy
does not allow. Direct document, embed, and scripting calls still reach the
same typed boundary and return an AuthorizationDenied/authorization-denied
result without exposing credentials or infrastructure details. Use the
Diagnostics panel and the operation’s denial message to distinguish a policy
decision from a missing service or runtime failure.