Moltaro 0.0.22-beta

Release date: 2026-08-21

This release makes Entity access consistently PostgreSQL-authorized across interactive and background work, adds independently persisted Related Tables to Entity forms, and improves retry safety for automation, managed uploads, record lifecycle operations, comments, and concurrent mutations.

Highlights

Entity list, detail, projection, mutation, import, automation and Worker decisions now use the same SQL-first Security Statements policy, including field-safe projection and authorization inside mutation transactions.
Entity forms can host Related Tables for independently persisted child records, with role-aware table selection, paging or tree navigation, sorting, archive access and governed create/edit/archive/delete actions.
Managed large-file uploads expose actor-local capacity and retry guidance, release capacity after interrupted background attempts, and safely resume an expired or recoverable logical upload with the same idempotency key.
Package and Net Operation Project automation receives clearer idempotent replay receipts, lifecycle results, bounded failure metadata, and safe comment reassignment with optimistic concurrency.
Dialogs and operational overlays no longer expose editable state while their owned initialization request is pending, and stale responses cannot replace newer state.

Detailed changes

Unified Entity authorization and concurrency

One compiled PostgreSQL policy now governs Entity list, point lookup, references, projections, mutations, imports, automation and background work. Root View filtering happens before count and pagination, while unreadable fields are removed before results leave the governed query path.
Create and update authorize the proposed database state inside the command transaction. Reference and collection dependencies are evaluated through bounded SQL instead of application-side graph loading; an incomplete or unsupported policy dependency fails closed.
Delete-trigger automation receives a durable authorization receipt tied to the exact deleted snapshot. Numeric JSON tokens retain their exact textual representation in the receipt hash rather than passing through a lossy CLR conversion.
Concurrent mutations of one Entity record use a collision-resistant transaction lock and fail quickly with conflict diagnostics instead of waiting behind an unrelated or stale writer.
Entity history, reference sorting and filtering, inverse references, responsibility lifecycle, secured mutation effects, archive/restore and attachment/comment ownership paths retain the same authorization and optimistic-concurrency boundary.

Configurators can add a Related Table item to a Form when a standalone child Entity has a direct paired Reference to the parent. The Designer, Configuration API, YAML v8 and Package SDK preserve the relationship and role-aware child Table Surface selectors.
Existing parents can create, edit and open child records without closing the parent form. Child changes save independently; the parent Reference is supplied and locked by the runtime so this workflow cannot attach the child to a different parent.
Related Tables support flat paging or the configured tree view, personal sorting, and Active/Archived scopes when authorized. Archive and permanent delete actions remain separate, confirmed lifecycle steps.
Parent and child access are evaluated independently. Child filtering runs in SQL before count and pagination, and the compact table omits fields and actions the current actor cannot use.

Automation, lifecycle and managed files

Automation idempotency is scoped by actor and operation. Exact retries return the original result; changed input with a reused key is rejected. SDK receipts now identify idempotent replays and lifecycle operations return a typed receipt with operation, completion and audit correlation data.
Archive and restore automation use the same trusted SQL authorization and receipt boundary as interactive lifecycle commands. Delete jobs retain the authorization evidence needed to run their configured triggers after the source row is gone.
Managed upload capabilities report active session and reserved-byte limits, lease durations and an optional retry delay. Capacity rejection uses the stable filesystem.upload.activeLimitReached failure code and retry-safe metadata instead of requiring message parsing.
Host cancellation of trusted background upload work releases its physical attempt and capacity. Retrying the same logical operation can create one successor attempt after current policy is rechecked; explicitly aborted or rejected uploads remain terminal.
Comment owners can be reassigned between supported resources through a stable operation id and expected row version. Exact retries are replayed, conflicts fail closed, and trusted system attribution is recorded without inventing a customer user.

User interface and operations

Form dialogs, configuration wizards, previews, board details, Geo Zone and Entitlement overlays wait for their owned request before enabling edits. Closing, reopening or changing context cannot let an older response overwrite the current record.
Data Explorer archive scope and filter controls preserve their current server-authorized context, including secured Reference filtering and manual ordering behavior.
Function operations expose bounded retry and failure metadata needed to correlate recoverable background work without revealing sensitive payloads.
The administrator Entity access guide now supports either workspace access tokens or Agent Access Kit API keys, preserves unrelated OR assignments, preflights supported limits, verifies every live permission, and securely clears credentials after use.

Database and upgrade impact

This release changes every Managed App Workspace schema. Existing comment rows receive concurrency versions, and new durable state is added for delete-trigger authorization, managed-upload recovery and idempotent comment reassignment. No Portal schema migration or customer data rewrite outside those bounded schema changes is required.

Managed Apps use sequential full runtime replacement. Each application has ordinary replacement downtime while its complete recovery point is created, the Workspace migrations run, and API, Worker and WebApp containers are replaced and verified.

Rollback must restore the matching pre-release Workspace database, managed object storage, runtime files and configuration together. Do not downgrade only the containers after new-version work has written the upgraded schema.

Deployment and operator actions

Publish 0.0.22-beta with production ReplaceRuntime for all three Managed Apps. Do not prepare or apply a delta update package.
Run target-runtime compatibility Check/Build for every Managed App before Portal, documentation, Runtime VM or application mutation. Resolve every Package .NET or Net Operation Project compilation failure before proceeding.
Back up PortalDb and create a complete application recovery point before each sequential replacement. Verify the exact package/image version, API, WebApp, Worker, PostgreSQL, RabbitMQ and public routes after every application.
After replacement, exercise sign-in, Entity list/detail/create/update, secured Reference selection, automation/Worker processing and the hot form and attachment paths actually used by each customer application.
No Runtime VM agent version, DNS, storage provider, signer, license or secret format change is required.

Compatibility and breaking changes

Package .NET and Net Operation Project consumers must rebuild against the current SDK. Code that deconstructs AuthorizedEntityDetail or ResourceMutationReceipt must accept the added IsIdempotentReplay member or use named properties. Lifecycle automation should consume the new typed EntityLifecycleMutationReceipt.

Security Statements that previously depended on an application-side preload, an implicit Admin/Owner data shortcut, or an unsupported persisted-instance evaluation path no longer grant access. Configure explicit root View, field and mutation Permission Assignments that compile for the current SQL policy; unresolved dependencies fail closed. Existing valid Security Statements and administrator assignments require no recreation.

The Related Table APIs and Package SDK builders are additive. Child changes commit independently from an unsaved parent form draft, and clients must use the server-issued related-table context revision rather than supplying their own relation filter or target.

Managed upload clients should handle filesystem.upload.activeLimitReached as retryable only when the response says so, wait for RetryAfterSeconds, and retry with the same logical idempotency key. Package code that reassigns comments must supply a stable operation id and the latest comment row version.