Moltaro 0.0.27-beta

Release date: 2026-08-26

This release prevents overlapping scheduled function work, adds guided and atomic Security administration for Entity Definitions and Boards, corrects draft-specific Reference Eligibility, and increases trusted attachment batch capacity without raising ordinary user upload limits.

Highlights

• A scheduled occurrence does not enqueue a second job while the same business function already has queued or leased work. The skipped occurrence remains visible in run history with its schedule identity and due time.
• Entity and Board Security administration now centers on Responsibilities, Access Policies, and Permissions. Policy changes use a server-generated Plan and one atomic Apply operation, while raw Statement and Assignment operations remain available in the Advanced surface.
• Standalone create Forms may provide an editable Reference driver even when that field can also be populated by a mutation effect in another draft. Related-create locks and server-owned calculated values remain authoritative.
• Trusted host automation may execute attachment transfer batches with up to 32 file-level operations. Ordinary actor upload capacity remains limited to eight active sessions.
• Historical Entity audit entries written with the former assignment payload name are materialized correctly, and trusted Board automation uses its system-validation path when adding a target.

Detailed changes

Scheduled business functions

• Before enqueueing a schedule occurrence, Moltaro checks for any queued or leased job for the target business function, including a job created through another supported source. An active job is reused as the single-flight fence and receives a wake-up instead of allowing overlapping execution.
• A suppressed occurrence is recorded as a completed skipped Run owned by the schedule, without linking it as the active job’s execution result. Terminal jobs do not block later scheduled occurrences.
• Cancellation, retry, lease, heartbeat, and terminal-state behavior for the active job remain unchanged.

Entity and Board Security administration

• Access Policies project one canonical Security Statement together with every exact Permission Assignment that references it. The guided condition editor and DSL editor produce the same runtime configuration.
• Policy creation and editing, partial Permission binding changes, and exact field-refinement normalization use Plan/Apply. Apply rechecks the current RowVersion, Permission catalog, management authority, and complete candidate before committing configuration, audit, outbox, and replay receipt in one transaction.
• Permissions show inherited field access separately from explicit refinements. Capability groups are current server-owned selection aids, not stored presets; Board transition permissions remain exact.
• Responsibilities and Assignment Rules use focused workflows with preview drawers and unsaved-change navigation protection. Entity Definitions and the Board Item and Board Status profiles share the same administration concepts.
• Existing Security Statements, Permission Assignments, Responsibilities, and runtime authorization semantics are preserved. Expert users and integrations may continue to use the immediately effective raw configuration endpoints; a raw mutation invalidates an outstanding guided Plan.

Reference Eligibility

• Mutation-effect targets are no longer treated as permanently server-owned. When the effect does not apply to the current create draft and field behavior permits editing, the field appears in CreateDraftFieldIds and the Form may provide its raw value for candidate query, selection, and final save.
• Calculated targets remain server-owned. Related-create roots remain locked, and a caller value is rejected when authoritative field behavior makes the driver non-editable.
• An unavailable required driver continues to produce ContextIncomplete; supplied fields outside the operation-specific allow-list fail closed.

Attachments, Boards, and audit history

• Package .NET attachment batches may request file-level concurrency up to 32. The runtime grants the larger active-session limit only to a verified trusted system actor and preserves the ordinary limit of eight for users and other callers.
• Board application automation validates additions through the trusted system automation path, so configured target rules are evaluated with the correct provenance rather than the ordinary interactive-actor path.
• Entity change history accepts both current ResponsibilityChanges and legacy AssignmentChanges payloads, preserving responsibility history for records written before the terminology change.

Database and upgrade impact

There are no Workspace or Portal schema changes and no data migration. Existing Security configuration, Entity data, Board data, jobs, Runs, attachments, and audit history remain in place.

All three Managed Apps use sequential full runtime replacement and have ordinary replacement downtime while a complete recovery point is created and API, Worker, WebApp, and RabbitMQ 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.27-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.
• No Entity or Board Security bootstrap is required for this release. Existing Statements, Assignments, Responsibilities, and Permission configuration are preserved.
• After replacement, verify exact package and image versions, API, WebApp, Worker, PostgreSQL, authenticated RabbitMQ readiness, public routes, and operation queues for every Managed App.
• Observe one configured scheduled function across a due occurrence. When a prior job for that function is still queued or leased, verify that no second active job is created and that run history records the skipped occurrence.
• Open an existing Entity or Board Security scope without applying changes and verify that Responsibilities, Access Policies, Permissions, and the Advanced raw configuration surface load from the existing configuration.
• Verify one standalone create Reference picker whose editable driver can also be a mutation-effect target; candidate query must accept the user-owned driver when the effect is inactive.

Compatibility and breaking changes

Scheduled execution is now single-flight per business function. A due schedule occurrence is intentionally skipped while any job for that function is queued or leased, including an API-enqueued job. Customers that intentionally relied on concurrent executions of one function must separate the workloads into different functions or schedules; Moltaro no longer starts those overlapping runs.

MoltaroAttachmentTransferBatchOptions.MaximumFileConcurrency increases from 8 to 32. The larger request is honored only for trusted host automation; ordinary actors remain limited to eight active upload sessions. Existing SDK callers that request eight or fewer require no change.

Security Plan/Apply endpoints and policy projections are additive. Existing raw Security Statement and Permission Assignment endpoints remain supported and immediately effective. Reference Eligibility request shapes are unchanged; the server corrects ownership of editable effect targets for the current draft.

There are no persisted-data compatibility changes.