Moltaro 0.0.24-beta

Release date: 2026-08-24

This release adds role-aware runtime navigation, clearer fail-closed Boards states, improved role and group membership administration, consistent Card layouts, and safer repeatable historical Board imports.

Highlights

• Administrators can restrict individual runtime-menu sections and links to selected roles. Existing menu nodes remain unrestricted until roles are assigned, and menu visibility never grants access to the linked data.
• Role and group administration now provides searchable membership consoles, direct member management, permission workflows, mobile layouts and clearer user previews.
• Boards distinguish an access-filtered empty result and a restricted object context from genuinely absent data without disclosing hidden records.
• Card items use one supported responsive span contract of 1, 2 or 3 across configuration, packages, the editor and runtime rendering.
• Large historical Board imports use their durable source identity for exact replay, avoiding false idempotency-capacity failures during repeatable bulk imports.

Detailed changes

Runtime navigation and administration

• Runtime-menu sections and leaves accept an optional set of role IDs. A node with no assigned roles remains visible under the existing rules; a restricted node is visible only when the current user has at least one assigned role.
• Visibility is ancestor-aware: hidden sections and their descendants are removed before menu targets are resolved, and empty sections are omitted. This is a presentation boundary only; target and data authorization remain independently enforced.
• Runtime-menu YAML import and export preserve role restrictions and reject duplicate or unknown role IDs.
• Roles and Groups use full-height, route-backed membership consoles with search, quick filters, member add/remove actions, permission management and responsive mobile cards. User previews present identity, status and actions consistently across these workflows.

Boards access feedback and historical imports

• Board Item surfaces can distinguish unrestricted, conditional and denied list availability. Empty-state text now separates a genuinely empty Board, an active search with no matches and a result set filtered by access, without revealing hidden totals or record identity.
• When a Board Item itself is visible but access to its object context is denied, the runtime reports the context as restricted rather than absent. The underlying object and relationship remain undisclosed.
• Historical Board imports commit the source-key lock, nested Board Data creation, Board Item and durable identity in one per-item transaction. Exact replay is therefore safe for imports above the ordinary idempotency ledger’s per-scope capacity while normal Entity and Board submissions retain their bounded anti-abuse limits.
• Expired idempotency entries are removed before capacity admission. A genuine capacity limit returns a stable error code with bounded capacity and retry metadata so integrations can wait and retry deliberately.

Card and responsive user experience

• Card configuration, the Package SDK, YAML/API validation, the visual editor and runtime renderer now share the same 1–3 column-span contract. A valid span is still clamped to the number of columns available in the current Card.
• Values above 3 that were already stored for Card items become 3, which preserves their current full-row rendering. Form item spans are unchanged.
• Data Explorer’s archive mode controls retain an accessible touch target even for short localized labels.
• On mobile, an empty application bar is replaced with an accessible edge navigation handle while existing toolbar content and drawer focus behavior are preserved.

Database and upgrade impact

Every Managed App Workspace database receives schema changes for optional runtime-menu role restrictions. Existing menu nodes are not assigned roles by the upgrade and therefore keep their previous visibility until an administrator configures a restriction.

Persisted Card item spans above 3 are changed to 3. This preserves the current full-row layout, but the original authored number cannot be recovered. Package, YAML or API clients that still send Card spans from 4 through 12 must change them to 3 before the configuration is applied again. Form spans are not changed.

Managed Apps use sequential full runtime replacement and have ordinary replacement downtime while a complete recovery point is created, Workspace migrations run, and API, Worker and WebApp containers are replaced and verified. There is no Portal database migration.

Rollback must restore the matching pre-release Workspace database, runtime files, configuration and managed object storage together. A technical database downgrade cannot reconstruct the Card span values that were normalized.

Deployment and operator actions

• Publish 0.0.24-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.
• Administrators may optionally assign roles to runtime-menu nodes after the release. No assignment is required to preserve existing menu visibility.
• No Runtime VM agent version, DNS, storage provider, signer, license or secret format change is required.

Compatibility and breaking changes

Card configuration has a deliberate compatibility change: authored Card ColumnSpan values are now limited to 1, 2 or 3. Package SDK code, YAML and direct API clients using 4 through 12 must use 3 for a full-width Card item before their next Check or Build.

Runtime-menu configuration adds optional RoleIds on sections and leaves. Existing configurations remain valid and unrestricted; consumers that preserve or round-trip menu configuration should retain this field.

Board runtime view-shell responses add item-view availability information, and idempotency-capacity failures add a stable error code plus retry metadata. These are additive response contracts. They do not relax Security Statement authorization or expose filtered records.