OpenMES v0.25.0

OpenMES v0.25.0 is a release about two things: unit-level traceability — serialised units, component genealogy, cartons and pallets, and tester-log import — and a module system that finally works on a running installation, where a module uploaded as a ZIP brings its own frontend instead of silently rendering nothing.

OpenMES is an open-source Manufacturing Execution System (MES) built on Laravel and React, for discrete and batch manufacturing: work orders, process routing, material lots, quality control, OEE, downtime and shop-floor terminals.

---

Added

Unit-level traceability and serialisation

• Serialised units with their own identity. A unit can now be born with a process serial number (PSN) at the bench and receive its product serial number (SN) later with the label, or be registered with its serial number up front. Units carry status — in production, completed, blocked, scrapped, shipped — and are found by either identifier.
• Unit label station. A dedicated operator screen for issuing identifiers, printing labels, and binding what goes into a unit. Identifiers are drawn from configurable numbering sequences per product type, so serial number formats follow the plant's own convention.
• Component genealogy — what went into this unit. Scanning a component binds it to the parent unit: another serialised sub-assembly, a material lot, or a bare identifier that can be resolved later. Unbinding closes the record rather than deleting it, so a swapped part remains part of the device history. Double-installation and circular assembly are refused.
• Cartons, pallets and shipping. Units are packed into cartons, cartons onto pallets, and the pallet's quality state follows the units actually on it. A held or blocked unit no longer leaves as shipped with its pallet.
• Tester log import. Automated test equipment writes its own log; OpenMES now imports it, attaches the measured values and pass/fail verdicts to the unit, and applies a configurable policy on failure — scrap, block, or record only, with a retry limit.
• Traceability console. Search by serial number, process serial number or a component identifier and get the whole history of that unit back: product, work order, carton, pallet, every station it passed, the operator, the time between steps, the measured parameters and the result. Forward trace from a material lot to the finished goods, backward trace from a unit to its source lots, and recall impact across both.
• Work orders, material lots and pallets in traceability. Lot consumption, allocations and pallet movements feed the same genealogy, so a recall question is answered from one screen rather than three.

Module and extension system

• A module installed after the fact now has a working frontend. Previously a module's React pages were never in the bundle — the bundle is compiled before the module exists, and the production image removes node_modules right after the build — so every page of an uploaded module rendered the missing-page card while its routes answered normally. A module now ships its own compiled JavaScript, which core loads before the first render and reads as a third source in the page resolver. Precedence is unchanged: core, then a compiled-in module, then a runtime one.
• Modules can add fields to the user and worker forms, rendered by core, validated server-side through Form Requests, and stored by the module inside the controller's transaction — so a failed write rolls the whole save back instead of losing the field.
• Modules can reach the operator's station screen with their own display region, and their own keys now survive validation when a step is started or completed.
• Operator top-bar tabs, module translations and module import entities. A module can place a screen on the operator top bar, ship its own lang/<locale>.json merged into the frontend translations, and register its own CSV import entity.
• requires_core is enforced. Every module manifest has carried a minimum core version and nothing read it, so a module built against extension points this core does not have installed cleanly and then quietly did nothing. Installing or enabling one now refuses and names both versions.
• Uninstall hooks run, so a module can clean up after itself rather than leaving its tables and settings behind.
• ModuleTestCase migrates a module's own tables inside the test transaction, so a module ships with tests like the rest of the application.

Installation

• The install scripts ask about anonymous usage reports. The web setup wizard has asked since reporting became opt-in, but a Docker install never reaches that wizard, so nobody installing with install.sh or install.ps1 was ever asked. The prompt defaults to no, an unattended run is treated as no rather than as consent, and the answer is recorded once so it can never overwrite a later choice made in Settings → System.

---

Fixed

• A failing module no longer takes the whole application down. Providers were registered inside a try/catch, but Laravel calls boot() later, outside it — so a module throwing there took every route with it, including the admin screen needed to disable that module. Recovery meant deleting its directory by hand over SSH. Providers now run behind a guard covering both phases: a broken module contributes nothing and is logged, and the rest of the application is unaffected.
• The release package no longer strips the Modules admin screen. The packaging rules dropped three frontend pages, so a self-hosted installation had no way to manage modules at all — the feature was in the code and absent from the build.
• Docker builds no longer fail on a RoadRunner download. The binary is taken from its own image instead of fetched from GitHub during the build, so an image builds on a machine or network that cannot reach github.com.
• Barcode scanner mode is honoured on the packaging screens, and the reader capture is shared rather than reimplemented per screen.
• User administration validation moved into Form Requests, which is also what allows a module's contributed fields to pass validation at all.

---

Upgrade notes

Database migrations run automatically on container start. No configuration changes are required. Modules built against earlier cores should declare requires_core in their manifest — an unreadable or missing declaration is now refused rather than treated as "any version".

---

Installation

Web / self-hosted: download openmmes-v0.25.0.zip below — it is self-contained (PHP dependencies in vendor/ and the built frontend in backend/public/build/ are already bundled, so no composer install or npm build is required).

Desktop: grab the installer for your OS — Windows *-setup.exe, macOS *.dmg, or Linux *.deb / *.rpm. They bundle PHP and the backend and run OpenMES as a local app or LAN server.

Mobile (Android): install openmes-mobile-v0.25.0.apk and point it at your OpenMES server.

Shared hosting (no terminal): unzip the web package, upload the folder, point the document root at the package root, then open the URL — the browser-based setup wizard handles environment, database and the admin account.

Docker: unzip the web package and run docker compose up -d from the package root (or bash install.sh).

---

Full commit history: v0.24.3...v0.25.0