@orion-front/docs

Appearance

Core Apps ​

English · Русский

Purpose ​

Use coreApps to host one of five built-in MES administration surfaces, or an overview selector for all five.

When to use ​

Use single-app mode when one application route should open one administration surface without the five-surface selector. Use selector mode when the same route should let the user move between all five surfaces. This is a navigation and composition choice, not an access-control boundary: the API and the current user's permissions remain authoritative. Use metaTypesCrud only when the smaller MetaType-only CRUD surface is sufficient.

Prerequisites and ownership ​

  • The deployed API and current user must support the selected administration domain.
  • The panel performs API requests, checks permissions, initializes the selected interface, and shows operation results.
  • Core Apps provides five administration interfaces.
  • JSON chooses the interface; it does not configure API paths or interface behavior.

Capability map ​

appUser-visible capability
orgStructureBusiness-unit CRUD, role links, linked users, and default role assignment
rolesRoles section; currently a placeholder, not a functional role-management workflow
applicationsApplication/group hierarchy CRUD, JSON config editing, icon mapping, users, and permission rules
dataModelMetaTypes, MetaLinks, attributes, methods, lifecycle options, lazy expansion, CRUD, and permission rules/state links
settingsGlobal settings and user overrides with list/detail and CRUD
omittedLeft-side selector for all five; initially selects orgStructure

Behavioral model ​

In single-app mode the panel shows only the configured interface. In selector mode it shows left-side navigation plus the active interface. When an interface opens or the user performs an action, the panel automatically requests the required data from the API and displays the result in that interface.

DataModel requests in 0.75.0 ​

When a Core Apps form needs option lists, the panel automatically requests MetaTypes, MetaLinks, and lifecycle templates from the API and displays the returned options in the form. Panel JSON does not list the options or endpoint paths.

When the user selects a non-root MetaType or MetaLink row, the panel sends GET /MetaTypes/{typeName}/Count or GET /MetaLinks/{linkName}/Count. It writes the returned number to that tree row only while the same row remains selected and no newer count request has started. A count response cannot interrupt an active create, update, or delete operation. Each eligible selection sends a new request.

When the user expands a MetaType or MetaLink, the panel requests descendants, attributes, and methods from the API. Inherited attributes remain separate in each parent branch, even when the branches contain the same attribute.

Alternatives, defaults, and precedence ​

  • Omit app for selector mode; orgStructure is initially active.
  • Set one exact key for single-app mode: orgStructure, roles, applications, dataModel, or settings.
  • The configured app always wins over selector state.
  • Split administration into separate application routes when users should not see the selector or unrelated surfaces.

Limitations ​

  • roles currently shows a placeholder and does not provide role management.
  • Domain endpoints, permissions semantics, forms, and interface behavior are not configurable through coreApps JSON.
  • Selector state is runtime-only.
  • DataModel object counts and inheritance data require GET /MetaTypes/{typeName}/Count, GET /MetaLinks/{linkName}/Count, and the isInherited, inheritedFrom, and notifyEventType fields in the API.
  • The local demo covers only the settings single-app surface.
  • The demo's Settings mutations are shared within one demo server process and reset only when that process restarts. The linked demo therefore targets an isolated single-session or access-restricted documentation deployment, not a shared public multi-user service.

Minimal configuration ​

json
{
  "id": "applications-admin",
  "type": "coreApps",
  "app": "applications"
}

Scenario: one administration hub ​

json
{
  "version": "1.0.0",
  "layout": { "padding": true },
  "panel": {
    "id": "core-administration",
    "type": "coreApps"
  }
}

Expected result: the selector lists all five surfaces and starts on Organizational Structure. Applications and DataModel show the actions allowed by the current user's permissions. When the user selects Settings, the panel requests global and user-specific settings from the API and displays them.

For production, create separate applications such as:

json
{ "id": "org-admin", "type": "coreApps", "app": "orgStructure" }
json
{ "id": "data-model-admin", "type": "coreApps", "app": "dataModel" }
json
{ "id": "settings-admin", "type": "coreApps", "app": "settings" }

Runnable demos ​

Open the stateful Settings-only Core Apps demo

The demo supports viewing, creating, updating, and deleting global and user-specific settings. It keeps changes in temporary data; restarting the panel development server restores the initial settings.

The demo covers only app: "settings". To try orgStructure, applications, dataModel, or selector mode, configure that surface in an application connected to the matching API and sign in with the required permissions.

Exact parameter reference ​

Next, use the Settings demo to inspect the single-app layout. To continue with another Core Apps surface, configure it in the target application and open it with a user who has the required permissions.