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. Typical 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.

When to use it

Section titled “When to use it”
  • 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 component injection into standard Moltaro pages or Entity UI surfaces — pages are full-page routes only.
  • 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.