Moltaro 0.0.30-beta

Release date: 2026-08-28

This release makes new Entity Definitions immediately usable by administrators, simplifies Work Schedule operational setup around current Entity fields, restores several Board and Activity Feed paths, and removes avoidable RabbitMQ probe load from shared runtime hosts.

Highlights

• Every newly created standalone Entity Definition receives a removable, one-time Admin_access policy that assigns all current non-field Entity permissions to the built-in Admin role. Existing Entity security configuration is never overwritten and deleted default access is not recreated by Repair.
• Work Schedule now uses the current Site.OperationalLocation reference and OperationalLocation.TimeZone field as its single operational-context source. Explicit Create/Repair also provisions the protected fields and the standard Table, Card, and Form surfaces needed to maintain the catalogs.
• Board runtime authorization, transaction rollback, historical replay, and package-host behavior are aligned again; related Activity Feed content can be read through its own authorized relation even when the target resource does not own that content kind.
• Business-function schedule API documentation and localized administration copy now state the existing non-overlap contract: a due occurrence is recorded as Skipped while work for the same function is queued or running.
• Runtime RabbitMQ health uses a lightweight, secret-free AMQP listener probe instead of starting an Erlang VM every 30 seconds. Runtime VM diagnostics now show real CPU busy separately from normalized load pressure and raw Linux 1/5/15-minute load averages.

Detailed changes

Entity administrator access

• Ordinary, system, association, Work Schedule, and .NET Package Entity Definition creation paths initialize the same Admin_access statement inside the owning transaction when the new definition has no security configuration.
• The statement discovers the live stable key of the built-in Admin role and the current permission catalog rather than relying on hard-coded permission ids. It assigns every non-field permission and remains ordinary editable Entity Security configuration after creation.
• Imports preserve their exact contained security boundary. Reconciliation of an existing definition never expands, restores, or replaces customer-owned statements and assignments.

Work Schedule operational catalogs

• Operational Location, Site, and Worker Create/Repair uses the standard Entity Definition and Entity UI administration services to add the required protected fields and module-owned Table, Card, and Form surfaces. Existing customer surfaces and defaults are preserved; known obsolete module surface keys are migrated to the stable keys.
• Current Site-to-location and location-to-time-zone values are edited through ordinary Entity Forms and Data Explorer. Effective schedule, authorization, exception authoring, readiness, lookup, and package runtime all resolve the same current fields and canonical IANA time-zone validation.
• Readiness stays fail-closed until every required catalog, field, usable surface, and current value is present. The setup screen reports Create, Repair, or Open per catalog and keeps access configuration separate.
• The old effective-dated operational-context HTTP endpoints, WebApp editor, package schema types, and host extensions are removed. Historical Site location and Operational Location time-zone chains are not converted to the new current-field model.

Boards, activity, and automation contracts

• Board host and Package SDK paths now preserve Unified Security decisions, deterministic locking, relationship tracker rollback, Board history replay, and governed mutation behavior across failed and retried operations.
• Activity Feed queries authorize owned comments or attachments independently from readable related content, so a resource that can appear as a relation no longer rejects an otherwise authorized related-only query.
• Business-function schedule OpenAPI descriptions, public documentation, and supported locales explain the lease-backed non-overlap behavior and the Skipped run-history outcome without adding a new client setting.

Runtime host operations

• Docker and Light Docker packages check the local RabbitMQ AMQP listener with Bash TCP support. The recurring health command contains no broker username or password and does not invoke rabbitmqctl; the bounded startup path still reconciles and authenticates application credentials before services start.
• Runtime VM agent 0.1.42 calculates CPU busy from consecutive /proc/stat samples. Portal thresholds that signal for host health while retaining Linux load pressure and the raw 1/5/15-minute load averages as separate diagnostics.
• The Runtime VM detail page exposes all three values in English, Ukrainian, German, Polish, and Spanish and no longer labels normalized Linux load as CPU utilization.

Database and upgrade impact

This release changes both Workspace and Portal schemas. Each Managed App has ordinary full-replacement downtime while its recovery point is captured, the Workspace migration runs, and API, WebApp, Worker, package runtime, and broker health are replaced and verified. Portal has a short deployment window while its additive host-CPU metric is applied.

The Workspace change permanently removes the old Work Schedule Site-location and Operational Location time-zone revision history. It performs no backfill to the new current Entity fields. After replacement, an administrator must run the explicit Work Schedule Repair action and fill missing current Operational Location and IANA time-zone values before assignment and effective-schedule features become ready.

Rollback must restore the verified pre-release Workspace and Portal database backups together with the previous runtime. A schema-only downgrade can recreate empty legacy tables but cannot reconstruct the removed historical rows, so it is not a valid data rollback.

Deployment and operator actions

• Publish 0.0.30-beta with full ReplaceRuntime for all three production Managed Apps. Do not prepare or apply an update package.
• Preserve the attached Runtime VM staging volume, automatic Managed App backups, Object Storage bindings, application secrets, and current Workspace databases. Confirm the latest automatic backup of each app is Available before publication.
• After replacement, open Work Schedule administration in each workspace that uses the module, run Create/Repair for Operational Location, Site, and Worker, and populate missing OperationalLocation.TimeZone and Site.OperationalLocation values. A workspace with incomplete values is expected to remain ConfigurationRequired and fail closed.
• Verify agent 0.1.42, separate CPU/load telemetry, RabbitMQ health without recurring Erlang CLI processes, exact target images, Web/API/Worker readiness, Board customer paths, and the Work Schedule readiness result.
• No new infrastructure setting or credential is required.

Compatibility and breaking changes

The Work Schedule operational-context contract is intentionally breaking. Clients must stop calling the removed Site operational-context and Operational Location time-zone history endpoints under /api/workspace/work-schedule/catalogs/... and must edit the current protected Entity fields through the standard Entity API and UI instead. Package consumers must stop using the removed SiteOperationalLocationAssignment and OperationalLocationTimeZoneRevision schema types. Existing historical values are not migrated.

The one-time Admin_access initialization applies only to newly created Entity Definitions. Existing definitions keep their current security configuration, and removing or changing the generated policy is respected. The Runtime VM agent heartbeat adds a nullable CPU-busy value; Portal accepts the first sample as unknown and displays it after a measurement interval. The schedule documentation, Board corrections, Activity Feed correction, and RabbitMQ probe do not require client changes.