Moltaro 0.0.67-beta

Release date: 2026-09-16

Teams can create and carry out Direct tasks with saved history, comments and files. Custom workspace pages can reuse native record controls, and runtime upgrades prepare compatible versions of already published pages automatically.

Highlights

• Direct tasks support assignment, execution, pauses, blocks and completion, with personal lists and access-controlled history and collaboration.
• Workspace UI authors can embed native record headers, paged history and archive, restore and permanent-delete dialogs with user-entered reasons.
• Workflow Definitions gain editable activation settings and multiple responsibility selections. This delivers configuration and C# storage access; automatic process execution is not included.
• File Protection offers a version-and-file-first download wizard and simpler independent recovery settings. The one-time history-preparation tool is retired.
• Published Workspace UI pages are rebuilt for the target runtime during upgrade preparation, preserving their published source and unpublished drafts.

Detailed changes

Direct Tasks

The Tasks workbench now uses persisted runtime data for Direct task creation, personal and Owner lists, previews, details and paged history. Creation requires the Definition’s Creator role and admitted participants. A Definition can allow a task with only a Task Owner; if Responsible is omitted, Owner is required. The current user’s eligible Worker can be offered as Owner when authorized. Existing Direct Definitions retain their previous requirement for Responsible; new Definitions can make it optional.

Authorized users can change Owner or Responsible, Start and Stop work, Pause and Resume, return paused work to ready, Block and resolve a block, and Complete or Cancel with an admitted outcome. Stop and reassign is one operation; replacing a Responsible on blocked work preserves the block. Current actor, state, transition, capacity and outcome rules determine which actions are available. Pause requires the actual Responsible unless invoked through trusted system automation. Block and resolution require an explanation. Completion records the outcome and comment alongside assignment and execution history.

Task-owned Collaboration supports comments, replies, files and immutable actions from saved task history. Read/create permissions depend on the current task and state; author editing limits and administrative authority still apply. Message and file publication is atomic. Counts include all permitted comments, replies and actions independently of the displayed feed page. Open lists, details and badges refresh quietly after committed changes, including Definition changes.

This delivery supports Direct Definitions with empty Input and Working Data schemas, no required Context and a due-date policy that permits no date. Rich data entry/editing, instructions, Context/Orchestrator content placement, Queue execution, timed postponement, unassignment and historical correction remain outside this runtime. Completion rules can use the outcome comment; unsupported Working Data or file dependencies reject completion rather than being ignored.

C# extensions can use typed Task command/query services, including from scheduled Jobs and TriggerHandlers. Writable generated Entity Framework (EF) sets expose Task instances and operational evidence, with explicitly loaded relationships. Service commands apply the runtime’s authorization, transaction, history and replay rules. Trusted direct EF writes leave those responsibilities with the extension; saving a row does not synthesize a task command or its history.

Records, workspace pages and navigation

@moltaro/ui adds MoltaroRecordHeader, MoltaroRecordHistory and MoltaroRecordLifecycleDialog for one saved Entity Instance. The components load current server decisions, share native history and lifecycle behavior, and support the page’s overlay target. History initially loads 25 events, with 10/25/50 page choices, and clears inaccessible or obsolete record data.

Single-record archive, restore and permanent-delete actions now ask for a manual reason on native details, previews, list actions and related tables as well as custom pages. Reasons must contain 1–1000 characters after trimming. An uncertain network result retains the original request and offers an exact retry; a later denial does not prove that the first attempt rolled back. Confirmed mutation results let custom pages clear records that are no longer readable. Focus returns to an appropriate record control after overlays close.

Data Explorer uses the available page width. The attachment composer has one Upload menu for disk/catalog sources and keeps its optional comment editor visible when permitted. Successful publication clears the draft; failure keeps it for retry. File-only publication retains the Files view. Completed user changes to grid columns persist while rows load.

The Files navigation item now follows the same effective read-permission service as the Files API, while still requiring the FileSystem module to be enabled. Module names are localized in English, Ukrainian, German, Polish and Spanish; long navigation labels wrap and keyboard section toggles no longer fire twice.

Workflow configuration and C# access

Workflow Definition details and previews show an Activation panel with a shared Edit dialog. A Definition selects Explicit or Implicit activation and an optional Boolean business precondition. Explicit settings include a context permission rule; switching to Implicit removes that rule. Preconditions exclude actor variables and security functions. Activation and User Input permission editors support multiple responsibility references, scoped to the item or current Board status where applicable.

Activation settings belong to the Definition independently of revision YAML. New Definitions receive an inherited-permission default appropriate to their Subject. Existing Definitions receive no fabricated permission rule and need explicit configuration. Saving these settings does not start a process or scan existing records. The runtime executor, start commands, event handling, runtime HTTP API and process UI are deferred.

The Workflow C# SDK exposes its configuration and instance, node-visit and history entities through the generated context. Stored state supports pinned revisions, repeated node visits, timer/user-input waits and ordered history. Database constraints reserve one unfinished instance per Definition and Subject. Direct EF writers must manage transactions, concurrency and history themselves; this access does not perform Subject authorization or execute a process.

File Protection recovery

The former backup History section is named Versions. Download backup is available from its header when the user has permission. The wizard first selects a retained version and file, then Windows or Linux, then the download. A file-row entry preselects its version/file; version previews open in an owned drawer.

Independent recovery settings make initial S3 credential upload prominent, group secondary actions in the card menu, and provide Windows/Linux restore utility links. Kit export still requires an active Owner, verified separate read credentials and complete retained-history coverage.

The one-time history-preparation API, Worker job and operator utility are removed. Existing recovery identity, credentials, publication records and backup payloads are retained. Publication for new recovery points, retention renewal and rebase continues. Always-on file observations, per-run freshness diagnosis and source-disk capacity telemetry are not delivered by this change.

Database and upgrade impact

This release changes Workspace storage for Tasks lifecycle evidence, public Task entities and Workflow configuration/runtime state. It also removes the retired File Protection preparation-job records. There is no new Portal database migration in the comparison range. Task identities and existing operational evidence are preserved through the upgrade; existing Direct creation policy is preserved. Workflow documents are not converted or started.

Managed Apps receive a full runtime replacement. Plan a service interruption while the application is stopped, its database and assets are upgraded, its prepared workspace page is activated, and services restart. No measured production downtime is established by these notes. Workspace UI compilation happens during preparation, before that interruption.

Retain a verified pre-upgrade database backup and the corresponding external file/recovery material. A database backup alone does not retain external file bodies. Several Tasks downgrades deliberately refuse to discard new history, identities or provenance. Other reverse migrations would discard Workflow runtime/configuration data, and recreating the retired preparation storage would not restore its records. Recovery may therefore require restoring a compatible backup and matching runtime; reverting container images alone is not a safe rollback plan.

Before retiring the preparation mechanism, confirm that every retained File Protection point required for independent recovery already has complete recovery metadata. An installation reporting incomplete history has no replacement preparation command in this release. Resolve that condition before upgrading the affected installation.

Deployment and operator actions

1. Use ReplaceRuntime for 0.0.67-beta, covering WebApp, Api and Worker. FromVersion is unset; this assignment does not describe an update package. Release preparation must verify the exact package’s database models and offline build toolchain before promotion.

2. Retain normal release backup/recovery evidence. For File Protection, capture retained/prepared coverage and protect any exported kit before the old preparation operation is removed. Do not infer recoverability from a green agent check or a successful database backup alone.

3. Let the upgrade prepare the exact published Workspace UI revision against the target offline toolchain. It reuses a compatible artifact or builds an inactive replacement, then validates publication identity and activates it during the upgrade. It preserves drafts and does not create an absent project. Resolve build failures or changed publication before retrying preparation; promotion cannot compile a missing artifact.

4. For an already installed runtime with an incompatible published page, the supported recovery command is moltaroctl workspace-ui repair --install-root <path>. This rebuilds/reactivates the published revision against that installation. Normal replacement uses the automatic path. Adopting the new record components still requires an author to change and publish the page’s source; upgrade automation does not rewrite customer code.

5. Rebuild affected C# extensions against the delivered Tasks/Workflow contracts and generated context. Verify custom SQL and integrations that depend on Tasks storage or the retired File Protection preparation API. Review existing Workflow activation settings without expecting process execution.

6. After replacement, verify all in-scope apps and their API/WebApp/Worker versions, database readiness, published-page compatibility, public routes and background operation health. An interrupted external import still needs the documented business-work recovery assessment; Worker shutdown does not promise replay of uncertain external effects.

7. After cancelling an unpublished preparation during local build/check work, start the replacement normally. Preparation verifies and releases eligible locks left by the stopped command automatically. An active command, interrupted remote operation or missing ownership evidence is reported with the affected host; never remove production lock markers manually.

8. Prepare and promote interrupt active backups automatically. They block new backup admission for the command, stop the affected writers and remove only the interrupted backup’s incomplete local and remote artifacts. Portal may restart briefly; application runtimes remain online during preparation. Available backups and file bodies are preserved. Fresh backups with new IDs are queued when admission reopens; a retry finishes interrupted cleanup from durable evidence. No extra operator step is required. Native external PostgreSQL placement is required for this interruption path.

Concrete post-deploy acceptance scenario

Use approved test records and a Direct Definition with empty Input/Working Data, optional Context/date, admitted Worker participants, enabled lifecycle grants, a valid completion outcome and Task-owned Collaboration.

1. As an authorized Creator, create a task with an admitted Owner and Responsible. Confirm its number and initial history survive reload and appear in the appropriate personal/Owner views.
2. As Responsible, Start, Pause with a reason, Resume and Stop. As an authorized Owner/administrator, reassign or block and resolve the task as its policy permits. Check persisted actors, explanations and intervals after reload.
3. Publish a comment with a small file, then a file-only attachment. Confirm the saved content and totals in both details and preview; file-only publication should leave the Files view selected. Verify an unrelated user cannot read the task or its content.
4. Complete with the configured outcome and a distinctive comment. Reopen the task and confirm terminal state, completion comment and immutable activity. Use a separate task if cancellation must also be exercised.
5. Open an existing published customer workspace page after replacement. Confirm it uses the same published source, loads successfully, and preserves drafts. Save one approved record and observe a configured background result through to completion and reload; page loading alone does not satisfy this check.
6. On a native test record, cancel a reason dialog and verify no change, then archive and restore with entered reasons under the permitted access policy. Check history paging and dialog focus at desktop and 375px. On a page that adopts the new components, repeat the same record scenario there.
7. For an installation using File Protection, download a selected retained file/version through the new wizard and verify recovered content. Where independent recovery is required, separately restore an old retained point using the Owner kit with Moltaro services unreachable from the recovery client, comparing the recovered bytes. Confirm coverage remains complete after a new recovery point or retention renewal.

These are required observations for the applicable release surfaces, not completed production tests. Record actual results and any approved exceptions in the release acceptance record.

Compatibility and breaking changes

• Tasks automation contract advances from 1.16.0 to 1.18.0; Queue installation format remains 8. The public Task entity is TaskInstance, and generated module sets are writable. Regenerate/rebuild code that consumed prior schema types or timestamps. Direct EF writes do not acquire the behavior of typed command services. Task creation/mutation may succeed with no readable task projection; clients must respect the receipt and current access.
• Workflow Engine and Workflow SDK advance from 3.2.0 to 3.3.0. EF schema types now belong to Moltaro.Package.NET.Workflow.Schema; the separate Moltaro.Workflow.Persistence assembly is removed. Update affected extension references/imports. YAML stays at version 2, including the existing single-responsibility form; multiple responsibility selections use anyOf. Activation is Definition configuration, not revision YAML or a start endpoint.
• Workspace UI HostContractVersion remains 1, but its declaration and fingerprint change. Existing artifacts require target compatibility; automatic upgrade preparation handles the published revision. The new record components require a saved identity and the page overlay target, and provide no bulk lifecycle or automatic page navigation.
• The File Protection GET/POST /api/workspace/admin/file-protection/recovery/preparation routes, the Preparation member of recovery status, the preparation service method/types, and /downloads/file-protection/recovery-preparation/windows-x64.zip and /downloads/file-protection/recovery-preparation/linux-x64.tar.gz distributions are removed. Update operator scripts and clients. Recovery status, credentials, kit export/import and the normal restore utility remain available.
• Existing Entity lifecycle HTTP contracts and server access decisions are preserved. The UI now collects the required reason instead of supplying an action label. Exact lifecycle retry state survives reopening the same mounted dialog, but not a full reload or destroyed component; inspect the outcome before initiating a new write after losing that state.
• Record history still does not expose lifecycle Reason as a display field or backfill imports. Entity application Create/Patch can record field history without function Source provenance. Missing Source is not proof of a manual change; customers requiring that provenance must account for this known limit.