Moltaro 0.0.71-beta

Release date: 2026-09-29

Dispatchers can reorder queued work, transfer eligible tasks and set when work becomes available. Record merging now runs configured C# save functions and preserves selected Reference values. Administrators can choose whether archived records reserve unique values, while file recovery and related-data presentation gain clearer controls. Existing server-side JavaScript business functions require remediation before upgrading.

Highlights

Move tasks within a shared manual queue, transfer unassigned work and schedule its earliest assignment time.
Apply ordinary C# save validation and mutation during record merge, transfer Reference values correctly and open permitted archived merged sources.
Choose All records or Active records for record uniqueness, with existing constraints retaining their current behavior.
Restore a single file under its original name and use more accurate file API schemas when generating integration clients.
Control related-table save notices and related-section subtitles, previews and empty-state visibility.

Detailed changes

Tasks and queues

Move in queue supports First, Last, Before task and After task. A wizard shows the intended move before Save; Cancel leaves the order unchanged. Desktop dragging opens that same review step in an unfiltered, ascending shared-order list. Mobile and filtered lists use the explicit dialog. Shared ordering includes unfinished assigned, blocked and future-availability tasks; personal sorting does not change it. Reordering requires dispatcher authority and visibility of the complete sequence. A stale order is refused so the user can reload while keeping the intended move.

Change queue transfers an unassigned Idle or Blocked task to an active queue that admits its definition. The task keeps its identity, data, state and availability date. Assigned tasks explain why transfer is unavailable; remove the executor through the existing assignment command first. That removal is a separate committed action. Transfer history shows queue names, and a caller who loses access after transfer can receive an acknowledgement without task data.

Available from sets the earliest time a queued task can be taken or assigned. It can be supplied at creation or changed on unassigned Idle work by an actor with the availability permission. Empty or past dates mean immediately available; a date after the deadline produces a warning. Reaching the time does not assign or start the task. Eligibility follows the clock even if the Worker’s screen-refresh notification is delayed. Availability is separate from postponing a task already in progress.

The selected queue or personal task list survives refresh and browser Back/Forward navigation. Executor load tables support name search, numeric sorting and a fullscreen view. Definition edits also protect fields used by enabled completion requirements, preventing an edit from silently breaking an otherwise valid requirement.

Record merge and archive

Opening a permitted record directly no longer fails because the Entity’s default list sort uses a field hidden from the reader. The same correction applies when loading a bounded set of known records or refreshing their context facts. Record visibility, hidden-field protection and archive permissions remain enforced. Ordinary lists still validate access to their configured sort fields.

Updating the surviving record during merge now invokes its configured C# save functions, including validation and before-save mutation. A refused or failed save rolls back the merge’s business changes; repeating a completed operation with the same operation key does not run those hooks again.

Taking a Reference from the source now persists its target ID, including Reference cells in SourceOnly and Manual Table selections. Selected writes are refused if value-read authority has been lost since preparation. Authorized readers can open the archived merged source through normal navigation and direct links, subject to View and ReadArchive. Merged sources remain unavailable for update, restore or another merge. A hidden survivor does not expose an action that reveals its identity.

Unique constraints can reserve values across All records, including archived records, or only Active records. Archiving releases an Active records key; restoring the record fails if the key is now occupied. A conflict in a dependent record cancels the complete restore. Scope changes are atomic and preserve the previous setting when current data conflicts. Active records is limited to eligible primary tables; owned child Tables and package-managed schemas retain their existing restrictions. Hidden records still participate in uniqueness.

Form and Card designers can hide the independent-save notice for a Related table. The notice remains enabled by default. Child changes still save independently, and create-mode placeholders remain. Related sections in details pages and drawers can hide their subtitle, disable row preview, or hide when there is no related data visible to the current reader. Missing configuration or restricted reference states are not treated as an empty section. These display settings do not grant or remove data access.

Files and business functions

The temporary restore command for a single file now targets the current directory and preserves the original filename and extension, including when selecting one file from a folder backup. A folder or file-set restore uses a new destination directory. The restore console distinguishes destination files from folders; existing destination content is not overwritten. The File Protection agent-update dialog labels its status check explicitly.

File OpenAPI descriptions now preserve attachment result variants, nullable error data, raw upload bodies, binary/range responses and direct-download authorization. The existing file routes, permissions and wire behavior remain unchanged. A file mutation acknowledgement does not grant read access, and an uploaded File-field value still needs an Entity save. Public REST catalogue listing/selection is not added by this release.

Server business functions now execute through C# Net Operation Projects or .NET packages. Legacy JavaScript execution and authoring are removed; unsupported targets cannot be enabled, bound, scheduled, queued or retried for execution. Stored source and completed history are retained under existing read and redaction rules. Workspace UI JavaScript/TypeScript is outside this change.

Database and upgrade impact

The Workspace database changes to support task routing/availability, archive-aware uniqueness and the related-table save-notice setting. There are no Portal database migration changes in this comparison range. Existing unique constraints retain All records, existing tasks gain no new availability delay, and existing related-table notices stay enabled. Existing queue definitions receive availability-edit permissions for dispatchers and task administrators on Idle work; review these grants against local responsibilities.

Use a maintenance window for runtime replacement and database transition. Downtime depends on the installed data and upgrade work; this assignment has not measured it. Retain a verified pre-upgrade database backup and the separately required file-body recovery coverage. A database backup alone does not preserve external file bodies.

An older runtime is not a safe rollback after routing/availability has been used or Active records uniqueness has allowed archived duplicates. Downgrade guards refuse incompatible task facts or Active records constraints. Recovery must use the supported application/database/backup boundary; there is no automatic deduplication or conversion back to the old behavior.

The combined candidate’s upgrade on a current customer copy remains unverified. Resolve the outstanding upgrade assessment before production promotion; this note does not certify upgrade readiness.

Deployment and operator actions

Deployment mode: ReplaceRuntime. Replace Managed App WebApp, Api and Worker together with the supported release workflow. This is not a published delta update; FromVersion is not applicable. The documentation comparison base is not evidence of every Managed App’s installed runtime version.

Before replacement:

Inventory actual application versions and preserve verified recovery material. Resolve the recorded upgrade risk and rehearse the customer upgrade in an isolated copy with external integrations contained.
Run the supported upgrade preflight. On the installed version, replace any reported active JavaScript rules with published C# functions, rebind or explicitly retire their dependencies, and finish or cancel unfinished legacy work. Republish reported C# versions without obsolete JavaScript limits. Preserve source and history; no automatic conversion is provided.
Ensure API, Worker, customer configuration and environment overrides resolve Moltaro:BusinessLogic:AuthoringMode to NetOperationProject, and resolve any unsupported stored authoring mode. Changing only the setting does not resolve active legacy dependencies. Retry preflight after remediation.
Regenerate affected API clients and update Entity YAML/package inputs as described below. Review the new availability grants. Change existing uniqueness scopes only after an explicit business decision.
Use the newly published File Protection restore client for the restore fix. Customer File Protection agents have their own update lifecycle; replacement of a Managed App does not by itself update those agents.

After replacement, verify every intended running application has the exact target runtime and image, API and Worker are healthy, and the release workflow’s route and migration checks have completed. On designated acceptance records, perform these concrete scenarios and retain the outcomes:

In a manual queue, move an unassigned Idle task to First and confirm the shared order in a second session. Set Available from a few minutes ahead: early Take/Assign must fail. Transfer it to another admitted active queue; confirm its number, data, state and date survive. At the due time it remains unassigned Idle until an eligible executor explicitly takes and starts it under the destination queue’s selection policy. Verify the routing history and the original reader’s permitted result after transfer.
Merge two approved disposable records with a populated Reference and the installation’s configured C# save function. Confirm the surviving reference and function-produced value, then open the archived source with an archive reader. A reader lacking ReadArchive must be denied; exact successful replay must not duplicate history or save-function effects.
On an approved Active records example, archive, reuse the key, and attempt restore. The conflicting restore must leave the original and any dependent records archived. Do not change customer uniqueness policies merely to run this check.
Open a permitted record directly as a reader who cannot read the Entity’s default-sort field. The record must open without exposing that field; a reader without View must still be denied. A normal list using that hidden sort field must still refuse the query. Verify archived reads separately with and without ReadArchive.
Upload/save/download a designated File-field or attachment value and compare the bytes; restore one approved file to an empty destination and check its original name. Confirm a configured hidden save notice leaves child saves independent and related-section visibility behaves on desktop and 375px.

Existing customer automation that relies on trigger ChangedFields needs particular attention: fields changed by a C# before-save function can be absent from that list even when the saved values and event snapshots contain them. This known limitation is not fixed in this release. Verify the actual dependent business outcome, not only that a trigger job was queued.

Compatibility and breaking changes

Server JavaScript functions: incompatible active dependencies block upgrade. Historical runtime enum values and stored source are retained, but they no longer select an executor. Supported C# functions remain the execution path; obsolete JavaScript-only active version limits must be removed by republishing the affected C# version.
Configuration API: creating a unique constraint requires ArchiveScope (1 = AllRecords, 2 = ActiveRecords). Missing, null, zero and unknown values are rejected. Updating scope uses the constraint’s existing ID and current RowVersion; it does not edit the field set. Regenerate clients from the installed Configuration OpenAPI.
Portable configuration: Entity YAML is strictly v9, with explicit ArchiveScope on each unique constraint. Embedded Security remains v8. Re-export older Entity documents or intentionally convert them, including Entity resources in installation packages. There is no old-version import fallback. Ordinary record mutation payloads do not gain a scope parameter.
Tasks integrations: the Tasks automation contract advances from 1.22.0 to 1.23.0, adding routing queries, move/transfer commands, availability and routing history. Update consumers that enumerate permissions, property-change kinds or implement the affected service interfaces, and rebuild against the matching package. Automatic assignment is not introduced by this release.
File integrations: regenerate from the installed public Runtime OpenAPI. More precise result and nullability schemas can change generated types without a runtime JSON change. Handle both authorized attachment data and mutation receipts, empty refusals, and the X-Moltaro-Download-Authorization: 1 response when present. Do not forward workspace credentials to file storage.