OpenMES v0.24.3

Read this one before upgrading. Telemetry turns off for every installation in this release — including ones where somebody deliberately turned it on. If you rely on OpenMES reporting back to you, switch it on again in Settings → System after upgrading.

Telemetry asks first

Telemetry shipped in 0.24.0 as opt-out: a migration seeded the setting to true, and an absent row meant the same. That put every installation on the reporting side of a question nobody had been asked.

It is opt-in now. This release turns it off once for everybody, and yes — that includes the administrator who said yes on purpose. There is no way to tell a deliberate yes from the seeded one, and between those two mistakes the safe one is asking again.

Nothing about what is collected changes. The payload describes the software — versions, which features are switched on, rough size bands, where errors occur — and never anything entered into OpenMES: no material or product codes, no lot numbers, no order data, no personal data, no error message text. That boundary is held by tests, not by convention.

OPENMES_TELEMETRY still overrides in both directions and is read before the database exists, so a packaged or air-gapped deployment can be born with it off, and a maintainer can force it on without a database.

Fixes

All six share a shape: a screen or an endpoint that assumed something was there.

Classifying a stop no longer fails on the stops that need it most. The shift monitor draws a stop for every DOWN slice on the state timeline, but the downtime record behind it is a separate row and can be missing. The drawer decided what to show from the segment's kind alone, so such a stop got the full cause picker and the escalate button — and clicking either sent the missing id as the literal string null, which PostgreSQL refuses with a type error rather than a refusal. The segment keeps its place on the timeline, because the machine really was down, and loses only what it cannot carry out. Two smaller lies in the same panel go with it: the drawer opened with no heading at all, and the status chip claimed the stop was classified when there was no record to have classified.

Six places where core reached into the optional workforce module without checking (#308, reported by a user running a plain community install). The worker edit form was the one reported. The team-day activity feed and the production cost report over the API were failing on every call. Saving a worker, a line or a process segment with a crew, division or skill answered with a server error instead of a validation message. The detail page also offered to add and remove certifications through endpoints that are not installed.

This is not a niche configuration: a fresh community installation has the HR tab on and no Enterprise module, which is exactly where all six lived.

Sample data loaded before the first shift is usable straight away. The demo seeders marked orders as running while planning their start for later the same day — a row that contradicts itself, which the work-order rules rightly refuse to save again. Loading an example company early in the morning produced orders nobody could start until the shift they were nominally already working in, and reseeding failed outright. One generated order was worse still: in progress, planned to start tomorrow.

Loading the sample data can no longer collide with replacing it. A demo install deadlocked when one administrator was seeding an example company while another was replacing it — the replacement empties the tables and then runs migrate, and the two met in the middle. Onboarding, Settings → Data and the nightly demo refresh now take one lock between them.

Also

A stop drawn with no downtime record is now recorded in the log, once an hour per station. It is harmless to the screen and always has been — which is precisely why nobody could say how often it happens or what produces it.

Known, not fixed here

The packaged enterprise.zip is behind the module directory. Installing the Enterprise module from that package leaves the plant reports screen missing. Rebuilding the package is a separate job.

Installation

Web / self-hosted: download openmmes-v0.24.3.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 + the backend and run OpenMES as a local app / LAN server.

Mobile (Android): install openmes-mobile-v0.24.3.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).