Moltaro 0.0.23-beta

Release date: 2026-08-23

This release replaces legacy Boards authorization with immediately effective Security Statements and SQL-only persisted decisions, improves user and role administration, and hardens several Entity, package and file-runtime paths.

Highlights

• Every Board now uses Security Statements, Permission Assignments and keyed Responsibilities for Board Item and Board Status access. Persisted Board decisions are filtered and enforced by PostgreSQL before data is returned or mutated.
• The Boards cutover is intentionally destructive: legacy Board permission profiles, grants, delegated access and responsibility assignments are not converted. Board process data is preserved, while access fails closed until administrators configure the new model.
• User administration adds persistent desktop and mobile filters for search, status, roles and user types, with identity presented consistently in list, preview and detail surfaces.
• Role administration separates module entry from authoring capabilities and replaces the generic permission tree with a focused permission-management workflow.
• Entity, managed-file and package-runtime paths receive additional concurrency, authorization, retry and collectible-runtime safeguards.

Detailed changes

Boards Security Statements cutover

• Board Item and Board Status are separate security profiles. Missing root View assignments deny access; Owner, Admin and Configurator do not receive implicit Board data access.
• Board Item list, search, export, direct reads and action matrices use one compiled SQL policy before count, sorting and pagination. Mutations recheck exact permissions and final visibility inside the transaction and roll back when the final decision fails.
• Board targets use typed Security DSL selectors. Displaying target data still requires the Board Item View, Target:View, and the concrete target resource’s own root and field permissions.
• Board Item and Board Status responsibilities use named definitions, Initial Assignment Rules and Assignment Rules. The old unnamed responsibility mode, profile grants and delegated-access model are removed.
• Board configuration remains available to Owner, Admin and Configurator or a Board-scoped ManageConfiguration assignment. Cycle commands remain available to Owner/Admin or a Board-scoped ManageCycles assignment. These administration authorities never bypass runtime data access.
• Boards, statuses, transitions, target definitions, Board Items, Board Data, cycles, links, Board Statements and Board Constraints are preserved.

Administration and user experience

• The Users surface aligns with Data Explorer filtering and keeps search, status, role and user-type filters across desktop and mobile use.
• User preview and detail surfaces expose identity consistently and use the shared detail-header presentation.
• Role permissions distinguish module access from Owner/Admin/Configurator authoring authority, present assigned permissions in a compact management surface and remove obsolete granular authoring capabilities.
• Public documentation is reorganized into user, configuration, developer and operations tracks with task-oriented navigation for people and AI agents.

Runtime reliability and compatibility

• Manual Order writers use the canonical allocator lock, preventing duplicate tail ranks under concurrent REST and Package SDK writes.
• Entity search treats malformed persisted paths as bounded invalid configuration instead of returning an unhandled server error, while secured hierarchy, import, history, Record Merge and trusted-system paths retain the SQL-only authorization boundary.
• OpenAPI retains required positional-record metadata without causing MVC validation failures.
• Package installation reconciles removed .NET package metadata before ownership-column checks, allowing dependency conflicts to fail and roll back cleanly when a package migration removes tables.
• Managed upload verification and FileSystem lifecycle work retain the correct Entity Security transaction, purge terminal upload sessions safely, keep active sessions blocking folder purge and preserve abort cleanup after target deletion.
• Runtime-epoch JSON resolver identities are isolated so collectible .NET runtime assemblies are not retained through shared serializer metadata.

Database and upgrade impact

Every Managed App Workspace database changes. The upgrade deliberately deletes all legacy Board permission profiles, grants, delegation state, Board-specific responsibility assignments and related legacy authorization history. Any pre-cutover Board Security configuration already stored in the common Security tables is also reset. Existing Board definitions, process configuration, Board Items and Board Data remain intact.

The new Board Security configuration starts empty, so Board Item and direct Board Status access fail closed immediately after upgrade. No legacy access or responsibility assignment is converted or recreated automatically. A separate post-release administration task must configure Security Statements, Permission Assignments and Responsibilities for every actively used Board.

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. The migration’s technical downgrade recreates only an empty legacy-compatible schema and does not restore deleted grants, delegations or responsibility history.

Deployment and operator actions

• Publish 0.0.23-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/image versions, API, WebApp, Worker, PostgreSQL, RabbitMQ, public routes and operation queues for every Managed App.
• Treat fail-closed Board access after the schema cutover as the expected breaking state. Preserve the application backups until the separate Board access-restoration task has been completed and verified.
• No Runtime VM agent version, DNS, storage provider, signer, license or secret format change is required.

Compatibility and breaking changes

Legacy Boards permission profiles, subject grants, delegated-access policies, reconciliation routes, Board-specific responsibility assignments and unnamed responsibility SDK contracts are removed without a compatibility reader or fallback. Legacy Board YAML security is rejected. Packages and Net Operation Projects that use the Boards SDK must rebuild against the current package and replace old authorization or responsibility calls with Security Statements, Permission Assignments and keyed responsibility operations.

Owner, Admin and Configurator retain Board definition-management authority but have no implicit Board Item or Board Status data access. Administrators must create explicit root View and operation assignments before users, including administrators, can read or work with Board data.

Role-management clients must consume the simplified permission catalog rather than relying on removed granular Business Invariants, Workspace UI or hidden module permission entries.