Moltaro 0.0.25-beta

Release date: 2026-08-24

This release improves high-volume attachment migration, makes related-create Reference Eligibility work with server-derived values, and gives administrators a clearer master-detail workspace for users, roles and groups. It also prevents stale Data Explorer reloads from corrupting a newly selected table projection.

Highlights

• Package functions can import up to 100 attachment streams as a bounded, failure-isolated batch with independent runtime scopes and ordered per-item results.
• Large multipart attachment transfers use bounded parallel provider uploads while preserving retry, cancellation, reconciliation and idempotency semantics.
• Related-create Forms can use locked host context and authoritative create-time automation to drive Reference Eligibility without exposing those derived fields as editable client input.
• Role and Group membership consoles keep the selected principal and its members visible together in a resizable master-detail layout, with a compact mobile selector and consistent user information.
• Data Explorer invalidates stale realtime, full-reload and load-more requests when the entity, surface, model version or query context changes.

Detailed changes

Attachment transfer and Package SDK

• IAttachmentService.UpsertStreamsAsync accepts a bounded batch of independent stream upserts. A batch contains at most 100 items, requests concurrency from 1 through 8, defaults to 4, and is further constrained by the actor’s available upload-session capacity.
• Every batch item receives its own runtime scope and transaction. One rejected item does not cancel or roll back successful siblings, input order is preserved in the result, and failures include stable retry guidance without exposing provider credentials or object-storage details.
• Multipart stream uploads buffer sequential 16 MiB parts and upload each bounded window in parallel up to the provider capability. Confirmed parts are reconciled before retry so an interrupted attempt can resume without resending already accepted parts.
• Package authors remain responsible for disposing caller-owned streams and for polling each accepted upload session to Available before archiving the corresponding source migration task.

Related-create Reference Eligibility

• Related-create actions may supply declared locked create roots that are not visual Form items. Authoritative calculations and create mutation effects can derive a Reference Eligibility driver from that context, and candidate query, selection and final create all use the same server-owned values.
• Automation-derived fields are not accepted as client overrides. Existing EditableWhen rules remain the authoritative guard, and the final writer rechecks Eligibility before commit.
• Form configuration exposes non-blocking diagnostics when a dependent Reference requires external create context. At runtime, effect-populated values appear read-only and the dependent picker becomes available after the authoritative evaluation completes.

Access administration

• Role and Group pages use one shared master-detail shell so search, filters, selection, membership, permissions, tags and section actions remain in a stable workspace instead of switching between disconnected list and detail layouts.
• User rows consistently show identity, status, roles and configured user type. Protected Everyone and administrator memberships retain their existing removal restrictions with clearer locked-state guidance.
• Small screens use a searchable principal selector and the same detail workflow instead of a separate reduced mobile-card path.

Data Explorer reliability

• Asynchronous table loads are bound to the entity, surface, model version and query context that created them. A response from an older projection is discarded instead of being applied to a replacement table.
• Bootstrap, realtime refresh, reset and load-more operations use one lifecycle invalidation boundary. Returning to a table after an archive or projection change no longer lets an older request read a temporarily cleared model or replace the current rows.

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.25-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.
• No configuration, permission reassignment, DNS, storage-provider, signer, license or secret-format change is required.

Compatibility and breaking changes

The Package SDK attachment batch types and UpsertStreamsAsync method are additive. Existing single-stream calls remain supported. Integrations adopting the batch API must provide one independent readable stream per item, call it outside an ambient package transaction, and retain idempotency keys across retries.

Form administration responses add optional Reference Eligibility create-context diagnostics. Existing related-create definitions remain valid, and clients that ignore unknown response fields need no change. There are no known breaking changes to persisted data, configuration or existing API operations.