OpenMES v0.24.2

🔒 Security release

A required password change is now actually required. If you use
"require password change at next login" as part of your incident
response, the version you are running does not enforce it after the first
redirect. Upgrading is worth doing promptly.

These notes cover the whole 0.24.x line — 0.24.0, 0.24.1 and 0.24.2 — so
this is the only page you need if you are coming from 0.23.x or earlier.

---

New in v0.24.2 — security

A required password change is now actually required

Ticking "require password change at next login" produced a control that looked
like it worked. The user was taken to the form once, at the end of login — and
could then type any other address and carry on, because by that point the
session was already authenticated. The one moment the control exists for was the
moment it failed.

It is now checked on every request, on the web and the API alike. The form
and logout stay reachable, because enforcement that traps someone on a page they
cannot leave is a lockout rather than security. API clients receive a 403
carrying the reason instead of a redirect to HTML they cannot render.

Login also issued a full-scope API token to an account that owed a change,
and merely reported the flag in the response body — leaving enforcement to the
client's good manners. A mobile app, an ERP integration or curl has no reason
to honour that. Such a login now yields a token that can do exactly one thing:
change the password.

Reported privately and responsibly by
Maxwell Jones.
Rated Low — it requires credentials the attacker already holds, grants no
privilege escalation, and exposes no data that was not already reachable. Low
severity, high priority: a control that silently does not work at the one
moment it is called upon.

Changing a password now actually revokes access

Found while checking whether administrators had a working alternative to the
forced change. They did not: nothing ended sessions or revoked API tokens when
a password changed — including when an administrator set one on a user's
behalf.

So after a suspected compromise the defender did everything right, reset the
password, considered the incident closed — and the attacker kept a live session
and a valid token. Unlike the bypass above, no procedure worked around this.

Fixed across every password-change path, not only the one API endpoint that
already did it.

Also in 0.24.2

Loading a different example company no longer rebuilds the database schema. It
was dropping every table and replaying 249 migrations in order to delete rows
from a schema that was already correct. The cost of that grew with the size of
the database, so it was felt most on long-running installations.

---

From v0.24.1 — usage reporting

This introduced outbound network traffic. If you upgraded straight from
0.23.x, read this.

OpenMES reports on itself once a day — versions, which features are switched
on, rough size bands, and where errors occur. It never sends anything you
entered into OpenMES: no material or product codes, no lot numbers, no order
data, no recipes, no personal data, and no error message text.

Error messages are excluded outright rather than filtered, because filtering
them reliably is not possible — our own exceptions name materials and their
codes. The boundary is enforced by a test that seeds a plant's worth of
realistic data, builds the real payload, and fails if any value from the
database appears in it.

On by default, one click to switch off in Settings → System → Usage
reporting, or OPENMES_TELEMETRY=false before you start. The installer says
so up front, and the settings page prints the actual payload on request
rather than describing it. An installation behind a closed firewall behaves
exactly like a connected one: nothing fails, nothing slows down, and a year
offline does not fill the log.

Full detail: docs/telemetry.md

Also in 0.24.1: the Android APK build asked the SDK for tools, a package
Google withdrew — which is why v0.24.0 shipped without one.

---

From v0.24.0 — releases work again

Every workflow had been rejected at startup since 14 September, because the
repository requires SHA-pinned actions and ours referenced tags. That is why
v0.23.0 and v0.23.1 were published with no downloadable files at all, and why
no container image was pushed for either. If you were waiting on a download that
never appeared, this is the fix.

The release package also omitted the root modules/ and packages/
directories the Dockerfile copies, so it could not run the
docker compose up -d its own notes prescribed — the build failed on every
machine. Releases now fail if any path the Dockerfile needs is missing.

Fixed in 0.24.0

• Checklist items and operator parameters were filed against the wrong process
  step. The step card was reused rather than remounted, so both forms kept
  whichever step was open when the page loaded — normally step 1. Anything added
  from a later step went there instead. Existing templates are worth
  reviewing: the fix stops new mistakes but does not repair old ones.
• Completing an inspection returned a server error when no criteria had been
  recorded. Refusing is correct; crashing instead of saying so was not. Now a
  422 for API clients and a message on the web, and the screen no longer offers
  a button it cannot honour.
• A work order with no production steps rendered as a blank screen. An order
  keeps the configuration it was created with, so steps added to the template
  later never reach it — now stated rather than shown as an empty page.
• Material shortages caused by reservations reported "have 0" beside a full
  store. On-hand and reserved now travel with the shortage.
• Machine counting, transfer ledgers and step-ledger rollback hardened
  throughout; operator pages synchronise through authorised, data-free events;
  en/pl translation key parity restored.

Added in 0.24.0

• Drawer-based editing for product types, workstations and material forms
• Work-order availability planned by plant-local start date and time
• Transfer production ledger with explicit machine counters
• Step-aware quick counts with station-scoped routing
• Modules can place a flat navigation entry of their own
• Consolidated daily scheduling view with shared calendar components

---

Full history: CHANGELOG.md

Installation

Web / self-hosted: download openmmes-v0.24.2.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.

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

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