Moltaro 0.0.54-beta
Release date: 2026-09-09
This release restores File Protection access after an upgrade of the shipped security catalog, separates storage health from access-readiness problems, and removes persistent notifications for successfully completed file uploads.
Highlights
Section titled “Highlights”- Existing File Protection role assignments work again after the supported catalog upgrade, without recreating roles or configuring storage again.
- Storage and readiness panels show consistent, actionable diagnostics, with a direct entry to Sources and Agents and readable mobile layouts.
- Successful upload notifications dismiss automatically; upload history remains available from the account menu.
Detailed changes
Section titled “Detailed changes”File Protection
Section titled “File Protection”The upgrade repairs the known shipped security-catalog checkpoint while keeping module enablement, role assignments, sources, agents, monitoring settings and recovery data. Unknown or customized catalog fingerprints remain blocked for review rather than being overwritten. An unavailable module is reported as a module problem, separately from an individual user’s insufficient permissions.
Repository status no longer describes a security dependency as a storage failure. An independently detected repository problem remains visible even when an access problem also exists. Administration provides text actions, a direct Sources and Agents entry when available, and diagnostics that wrap on narrow screens. These changes are localized in all five supported languages.
File uploads
Section titled “File uploads”A successful upload produces a dismissible notification for six seconds. Loading previously completed history does not display a new notification. Active uploads, failed or unfinished work, and queue-loading errors remain visible. The account menu opens upload history at any time; the history drawer offers retry when its queue could not be loaded. Dismissing a notification does not delete files or upload history.
Database and upgrade impact
Section titled “Database and upgrade impact”The Workspace upgrade makes a narrowly scoped persisted security-catalog correction with an audit record. It does not change table structure, customer role assignments, protection policies or backup contents. PortalDb is unchanged. Managed Apps have a short maintenance interruption while their runtimes are replaced sequentially. Recovery points are created by the release workflow.
The correction is retained on migration rollback because the preceding runtime already expects the corrected catalog. Restoring a complete earlier database recovery point would also restore its earlier catalog state and requires operator assessment; do not use downgrade as a security-reconciliation mechanism.
Deployment and operator actions
Section titled “Deployment and operator actions”Deploy to Production using ReplaceRuntime: prepare the frozen candidate,
inspect its ready state, then promote with its frozen runner. Replace all three
Managed App runtimes from 0.0.52-beta with 0.0.54-beta; the currently deployed
Portal-only 0.0.53-beta is the documentation comparison base. Publish the Portal,
documentation and runtime artifacts through the same guarded workflow. Runtime
VM agent version remains 0.1.46 and is verified through normal publication.
No new Object Storage, manual SQL reconciliation, role or menu edits, or local File Protection Agent installation is required. Existing file-body storage bindings and objects are retained, not recopied. After activation, verify OMS Owner access to recipients and audit, its existing File Protection navigation entry, consistent Storage/Readiness panels and the direct Sources/Agents action. Also verify runtime health and the upload-history entry. Do not change customer Source policies or launch extra protection/retention jobs for release acceptance.
Compatibility and breaking changes
Section titled “Compatibility and breaking changes”File Protection signal endpoints now return HTTP 503 with the module-specific error when the module is disabled or unhealthy; healthy-module permission denials remain HTTP 403. Integrations should distinguish module availability from actor authorization. Role and source scopes remain authoritative, without an Owner bypass. There are no new configuration requirements or changes to backup formats, file-body bindings or external Agent protocols in this release.