@orion-front/docs

Appearance

Core Apps ​

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 integration owns API calls, Pinia state, initialization, permissions adapters, icon registry, and feedback.
  • Installed @ornn-mes/core-apps@1.6.1 owns the five UI components and their emitted integration contracts.
  • JSON chooses the surface; it does not configure package internals or endpoints.

Capability map ​

appUser-visible capability
orgStructureBusiness-unit CRUD, role links, linked users, and default role assignment
rolesPackage-exported Roles surface; 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 wrapper renders only the configured component. In selector mode it renders navigation plus the active component. Initial OrgStructure and Applications lists are fetched on mount when needed; DataModel, permissions, and Settings load through their own interaction/mount paths. Package events are translated into panel-owned API/store operations.

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 is a package placeholder in the installed version.
  • Domain endpoints, permissions semantics, package forms, and component behavior are not configurable through coreApps JSON.
  • Selector state is runtime-only.
  • The local fixture covers only the settings single-app surface. It does not prove the other four surfaces or the five-surface selector.
  • The fixture'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 Data Model use panel-owned permissions adapters; Settings loads global/user values when selected.

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 mounts the installed Settings package through the real coreApps renderer. It loads full global and user-override records and exercises the panel-owned POST /settings/find, POST /settings, PUT /settings, and scoped delete routes against disposable in-memory data. Restarting the panel dev server restores the seed settings.

This fixture proves only app: "settings". Before rollout of orgStructure, applications, dataModel, or selector mode, exercise that surface with a user whose permissions match the intended role.

Exact parameter reference ​

Next, use the Settings demo to inspect the single-app boundary, then verify every mutation and permission dialog of the production surface against the deployed API.