Moltaro 0.0.80-beta
Release date: 2026-10-16
Entity forms, cards and tables can show fields from their Boards and Workflow context alongside record fields. Administrators can configure automatic Board placement and narrower reference-filter choices. Background retention now removes expired technical history in bounded batches.
Highlights
Section titled “Highlights”- Show Board status, due dates and Board Data fields on Entity surfaces, with supported changes saved together with the record. Show Workflow state and execution details as read-only context fields.
- Switch between a record table and the accessible Boards containing that kind of record.
- Limit the growth of processed event history, delivered realtime messages, completed function jobs and public-site analytics.
Detailed changes
Section titled “Detailed changes”Object context members can be placed on forms, cards and tables and preserved through YAML export and import. Board targets can opt into automatic placement when a record is created. An optional inherited security mode follows Entity permissions; existing Boards keep their explicit security and placement settings.
Reference eligibility is applied to a table when its required driving filters are available there. Quick filters and the filters drawer share the same selection state, and changing a driver clears dependent choices. A target Statement can further restrict reference-filter choices. The table constructor supports deleting filter and sort items.
An empty source in a SetIfEmpty mutation-effect chain is reported as a diagnostic skip instead of a user-facing warning. Actual validation failures remain errors.
The Worker removes dispatched realtime outbox rows after seven days. Completed resource-event history and terminal generic function jobs normally use 30 days, or 90 days for failed work. Pending processing, retained runs and module dependencies can hold records beyond those periods. Public-site analytics uses the configured legal retention period. Existing administrative retention settings, including Forever, are preserved; comment replay receipts are not included in this cleanup.
Database and upgrade impact
Section titled “Database and upgrade impact”This release changes the workspace database schema. Building an index on a large event history can lengthen the application’s maintenance period. Take a recoverable database backup before upgrading.
New cleaners are enabled by default and start with the upgraded services. They drain old history gradually; a falling row count does not immediately reduce database files. Disabling cleanup or reverting binaries does not recover deleted history. Restoring a database backup is the rollback path across this retention upgrade.
Deployment and operator actions
Section titled “Deployment and operator actions”Managed Apps use runtime replacement, including their API, WebApp and Worker. Portal, documentation, ingress router and Runtime VM agents are updated in the same release. The replacement workflow publishes ingress maintenance before stopping each application and reopens traffic after private readiness checks.
Deployment cache history now survives release-worktree removal. A later successful runtime replacement allows cleanup of superseded terminal attempts while current and previous versions, active operations and recovery data stay protected. Ingress receives the same bounded journald and rsyslog policy as the other managed hosts; applying it also rotates and vacuums old system journals.
Operators who need to postpone a retention category must disable its Enabled option before publication. After deployment, inspect the service-data retention metrics and errors. Keep existing run-history retention settings unless their owner explicitly changes them.
For acceptance, open an existing record, download a known attachment, save a normal change and check its background result. Also check Portal access, runtime versions and the readiness of published .NET projects.
Compatibility and breaking changes
Section titled “Compatibility and breaking changes”New Package SDK members are additive. Existing Board targets retain explicit placement and security. Automatic Board placement requires the supported creation-planning flow; direct import, SDK and package creates that do not plan that context are rejected. Review integrations before enabling automatic placement.
A terminal function job removed by retention is no longer available through its status endpoint. Persist any application-owned outcome through the owning module rather than relying on indefinite generic job history.
Hosted table binding filter presets remain unsupported; this release does not add WithinArea presets to those bindings.