Skip to content
MoltaroMoltaroMoltaro Docs

Workspace UI Project

The Workspace UI Project is the frontend authoring surface for one Moltaro installation: a single workspace-owned Vue/TypeScript source project that Moltaro checks and builds with its own packaged toolchain, and that publishes full-page workspace UI pages inside the WebApp. It is the frontend counterpart of the Net Operation Project — the workspace owns the source files, Moltaro owns the Vue, Pinia, Vuetify, TypeScript, Vite, ESLint, and host SDK versions, and a successful build produces an immutable runtime artifact that is activated explicitly.

One project can register multiple pages and multiple embeddable components. Typical page uses are workspace-specific operational workflows that configured surfaces cannot express: import conflict resolution, side-by-side comparison, specialized reconciliation, interactive planning, or screens that combine Moltaro data with an external browser API. Typical component uses are one non-standard block inside an otherwise standard record: a risk summary section, a computed card item, a status cell in a table, or a questionnaire inside the record form, placed by Constructor without rebuilding the screen (see Embedded components and Form components).

When to use it

Section titled “When to use it”

Before building a custom record shell, use the supported Record components: MoltaroRecordHeader, MoltaroRecordHistory and MoltaroRecordLifecycleDialog. They reuse native record loading, permissions, paged history and reason-based lifecycle operations. The reference picker provides the corresponding native single-record selection flow, and Safe Entity writes saves records from page code with one operation key and a check after a lost answer.

  • Configured Entity UI surfaces first. The UI surface library provides declarative Table, Card, and Form surfaces over entity data with no source code. Reach for a Workspace UI page only when the user experience cannot be represented by those surfaces.
  • C# for business decisions. The Workspace UI Project owns only frontend source. Validation, mutation, integrations, scheduled work, and inbound HTTP endpoints remain C# business logic; custom pages call existing APIs and functions instead of introducing new backend behavior.

Where it lives in the product

Section titled “Where it lives in the product”

Authoring lives in the Constructor area under the Automation & logic group, on two pages:

  • UI Studio (/business-logic/ui-development) — in-browser source editing, templates, Page Wizard generators, and save/check/build actions. Requires the Manage source permission.
  • UI Project (/business-logic/ui-project) — project lifecycle: source revisions, build history, artifacts, activation, and ZIP download/upload.

Access is gated by the Workspace UI Project permission group: View, Manage source, Build, and Publish.

End users never see the project. They open published pages through configured user menus — the runtime menu leaf type is Workspace UI page — or directly by stable route:

/apps/<pageKey>

The runtime page title shown for these routes is “Workspace page”.

Trust and security model

Section titled “Trust and security model”

Workspace UI source is trusted workspace code compiled by Moltaro. The boundary is governance and review — explicit Manage source, Build, and Publish permissions plus revision and build history — not a hostile-code sandbox. A published page can show any data the signed-in user is allowed to read, so treat page source with the same review discipline as C# logic.

  • Moltaro owns the framework, toolchain, and design-system versions. Source compiles against a versioned host contract; there is no user-managed frontend stack.
  • Pages render inside the host-owned Default or Fullscreen layout and may use only compiler-isolated scoped or inline styling — never global application CSS.
  • After a Moltaro update the source may need a rebuild, and a breaking host contract change may require source edits. GET /api/workspace/admin/ui-project/compatibility reports whether the active artifact still matches the host. See Build, publish, and upgrade.
  • External browser calls are allowed and remain subject to normal browser and network policy (CORS, TLS, mixed content). Moltaro does not impose an application-level destination allowlist.
  • The managed API client attaches the Moltaro bearer token only to app-relative Moltaro paths; it is never attached to an external URL.
  • Confidential external credentials belong in server-side C# logic. Compiled UI assets are client-delivered code and must never contain secrets.
  • Server-side permissions remain authoritative for every Moltaro API call. A page manifest’s RequiredPermissions gate menu visibility and client-side access to the page; they do not replace authorization on any API call.
  • Telemetry for the managed external client is bounded, and direct browser calls (plain fetch) are not captured by Moltaro.

What it is not

Section titled “What it is not”
  • Not a visual page designer or no-code layout builder.
  • No arbitrary npm dependencies, third-party build plugins, or remote JavaScript/stylesheet imports.
  • No hot module replacement, and no activation without a full WebApp refresh.
  • No server-side rendering.
  • No arbitrary injection into standard Moltaro pages. Workspace components reach native screens only through the supported placements, always placed by Constructor: the read-only Details/Drawer section, Card item and Table column cell of Embedded components, and the editable form item of Form components, which changes fields only through the native form’s own draft and save.
  • One Workspace UI Project per workspace; there are no multiple independently activated projects.
  • No automatic activation: a successful build produces an inactive artifact until someone with the Publish permission activates it.

For AI agents

Section titled “For AI agents”

Everything the UI Studio and UI Project pages do is available through the Configuration API under /api/workspace/admin/ui-project, authenticated with a service-account API key: source revisions, templates, page generators, checks, builds, diagnostics, artifacts, and activation. The full lifecycle is documented in Build, publish, and upgrade.

These routes belong to the configured workspace API host, not the public documentation or portal host. Obtain WORKSPACE_API_BASE_URL, the guide, and the key through the workspace connection handoff before starting API authoring.

Web Application registration, credential provisioning, and Agent integration remain Portal or administrator tasks. If the delivered handoff is incomplete, the agent asks the user to complete it rather than calling administration endpoints to provision itself. Use Reliable API automation for source concurrency, build polling, activation recovery, and safety rules.

In this section

Section titled “In this section”

For the end-user view of published pages, see Workspace pages.