Features
What the current version of BPMS does.
This page lists what BPMS does today. Each feature works on the BPMS 3.x database, so it uses the users, roles, and tenants that 3.x already holds.
Sign-in with the BPMS 3.x users
- Users sign in with their BPMS 3.x username and password; nobody needs a new account.
- Passwords are upgraded to Argon2id on the first successful sign-in, and passwords stored by 3.x with BCrypt keep working.
- A user whose credentials expired in 3.x must change the password before doing anything else.
- A user is locked after too many failed attempts, as in 3.x, and the attempt that locks the user also closes all of the user's sessions.
- Sign-in attempts are rate-limited per client address and per account.
- Every failed sign-in gets the same answer, so the response never reveals whether a user exists.
Sessions
- Signing in opens a session and returns an opaque token; the server stores only a hash of it, never the token itself.
- A session lasts 9 hours, and a user keeps at most 3 sessions; a new sign-in closes the oldest. These are the 3.x values, configurable per deployment and per tenant.
- Users can change their password and sign out; after signing out, the token no longer works.
Tenants and roles
- Each tenant (a company or business group) sees only its own data; the tenant comes from the user's session.
- The internal tenant number is never published; clients see an opaque public token.
- The roles of the tenant can be listed, paged, and sorted by name or id, without changing them.
A contract for every client
- The API is described by an OpenAPI document, served by the platform with an interactive Swagger UI.
- Every error has the same shape (RFC 9457 problem details) with a stable code that clients can rely on, and every response carries a request id that ties it to the server logs.
Safe on the 3.x database
- The application connection is read-only: PostgreSQL rejects every write it attempts.
- Only sign-in writes, through its own connection, and only the session table and four columns of the 3.x users table.
- Schema changes are additive, and against a 3.x database they run only as an explicit migration step, so a restart never changes the schema a running 3.x uses.
Ready to operate
- One container image runs as the HTTP server, as a background worker, or as a one-off migration.
- The whole configuration comes from environment variables.
- Liveness and readiness probes answer on the main port; the management endpoints stay on an internal port that is never published.
- The image runs as a non-root user and pins its base images.