Moltaro 0.0.26-beta

Release date: 2026-08-25

This release gives API-enqueued business jobs durable per-publication timeouts, makes Reference Eligibility depend on one authoritative server-evaluated Form context, and improves drawer navigation and actions across operational details.

Highlights

• Asynchronous API functions can declare a timeout from 1 through 86400 seconds. The selected value is captured on the queued job, preserved across retries and exposed in job status.
• Reference candidate queries, candidate confirmation and final Entity writes now use the same server-owned defaults, effects, calculations and locked related-create context.
• Related-create Forms may declare alternative host roots without requiring every possible root from the client. Automation-owned values stay server-owned and cannot be replaced by a caller-provided draft value.
• Detail drawers adapt section actions to measured space and localized content, keeping concise actions visible and moving additional actions into a stable overflow menu when required.

Detailed changes

Asynchronous business functions

• Package .NET and Net Operation Project functions published with MoltaroApiEnqueue may set TimeoutSeconds from 1 through 86400. When it is omitted, the configured runtime Job timeout remains in effect.
• The timeout is copied into each API-enqueued Job at publication time and is reused by every retry. A later runtime-setting change therefore cannot alter the execution boundary of an already queued job.
• Job-status responses include the captured timeout together with the existing lifecycle, attempt, cancellation and latest-run information.
• Check/Build rejects an API-enqueue publication whose declared timeout is outside the supported range. The override applies only to trusted jobs created through the API-enqueue publication contract; other Job sources keep their configured runtime behavior.

Reference Eligibility and related create

• Form runtime shaping, candidate query and selection, configuration diagnostics and final create/update evaluation share one authoritative server-side context. Defaults, create effects and local calculations are evaluated before the SQL candidate query and are evaluated consistently again by the final writer.
• Create and update expose separate draft-field allow-lists. An allow-list identifies values the current operation may contribute; it does not require the client to send every listed field.
• Locked related-create roots are accepted through the server-owned create context. Alternative roots such as Case and GroupEvent may be declared together while the current host supplies only the root it owns.
• Fields owned by defaults, effects or calculations are omitted from the client overlay. Supplying such a value does not override the authoritative draft, and a manually supplied derived value is not used as a fallback when required host context is absent.
• The WebApp no longer blocks a Reference picker by treating every possible create input as required. It sends the operation-specific context and uses the server’s Ready or ContextIncomplete state for availability.
• Entity Definition diagnostics report possible external create roots as neutral configuration guidance rather than claiming that every root is mandatory.

Adaptive detail drawers

• User, Entity Instance and Board Item detail drawers use the same resizable work header, section navigation and action measurement behavior.
• Section actions select labelled, icon or overflow presentation from the actual header and title space. Localized or runtime-provided action changes are remeasured, and a single narrow action remains directly accessible.
• Activity, attachment, assignment and Board actions retain their existing permissions and behavior while using the shared adaptive presentation.

Database and upgrade impact

There are no Workspace or Portal schema changes and no data migration.

All three Managed Apps use sequential full runtime replacement and have ordinary replacement downtime while a complete recovery point is created and API, Worker and WebApp containers are replaced and verified. Rollback must restore the matching pre-release runtime files, configuration, Workspace database and managed object storage together.

Deployment and operator actions

• Publish 0.0.26-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 active application mutation.
• Back up PortalDb and create a complete recovery point for each application before its sequential replacement.
• After replacement, verify exact package and image versions, API, WebApp, Worker, PostgreSQL, RabbitMQ, public routes and operation queues for every Managed App.
• Verify one existing governed Reference Form using a read-only candidate query or picker open: the response must use the current server runtime state and must not be client-blocked because an unused alternative create root is absent.
• No configuration, permission reassignment, DNS, storage-provider, signer, license or secret-format change is required.

Compatibility and breaking changes

MoltaroApiEnqueue.TimeoutSeconds and the corresponding job-status field are additive Package SDK and API contracts. Package or Net Operation Project sources that declare a value outside 1 through 86400 must correct it before their next Check/Build. Existing publications that omit the property continue to use the configured runtime Job timeout.

Reference candidate clients must treat CreateDraftFieldIds, UpdateDraftFieldIds and LockedCreateFieldIds as operation-specific allow-lists, not required-all lists. Clients must send scalar Reference values as raw instance IDs, omit automation-owned targets, and use the server-returned runtime state as the readiness authority. A custom client that pre-blocks on every listed field or sends derived values as a fallback must be updated.

There are no persisted-data compatibility changes.