Accounts and access#
How somebody gets into JMXPress, what they can do once they are in, and how teams are kept apart.
Getting an account#
There are two routes, and which one applies depends on how your installation is set up.
- An administrator creates it. They set the role and how long access runs for, and hand over a temporary password that must be changed on first sign-in.
- You register and wait. The sign-in page offers Register for access. That creates a request rather than an account; an administrator approves it, and you are told when it is done.
Note There is no billing in JMXPress. Access is granted by an administrator rather than bought, and trial and renewal windows are configuration on each installation.
Roles#
What somebody may do is decided by capabilities, not by one blunt "user" or "admin" switch. The capabilities are:
| Capability | What it allows |
|---|---|
record | Start and manage recording sessions |
edit | Change test plans in the editor |
report | Generate and read reports |
convert | Use the converters and script generators |
analyse | Use the analysers and collect diagnostics |
project | Create and manage projects |
administer | Administration pages |
manage_users | Create, edit and remove accounts |
invite | Invite people without full administration |
Roles are bundles of these. A tester can record, convert, run and report; a viewer can read; an administrator can do everything on their own installation.
Access windows#
An account's access can be open-ended or can end on a date.
- Extend moves the end date out.
- Set an end date puts a date on an account that had none.
- Lifetime removes the end date.
- Suspend stops access without removing the account.
- Withdraw ends access.
All of these are on the Admin page, on the row for that person. Everything beyond Edit and the one action that account's state suggests lives behind the three-dot menu on that row.
Careful A protected account is deliberately offered fewer of these. Every one of them ends in nobody being able to sign in and put things right, so the routes refuse them for protected accounts and the buttons are not drawn.
Organisations#
An installation can hold more than one team, and they do not see each other's work.
This is enforced by the database rather than by the application remembering to ask. Every tenant-owned table carries an organisation and is covered by a row-level security policy in PostgreSQL, so a query that forgets to scope itself returns nothing rather than returning somebody else's data.
When an organisation is removed, its projects, recordings, results, schedules and monitoring go with it. The people do not: they are moved to the default organisation, because an organisation ending is not the end of the accounts in it.
Passwords#
The policy is set per installation and is shown on the password page. The rule that catches people out is that a password may not contain your own email address — neither the part before the @ nor your domain.
So for admin@jmxpress.in:
| Password | |
|---|---|
Jmxpressadmin@494 | Refused — contains admin |
Jmxpress#2026Run | Refused — contains jmxpress |
Thunder#Valley2026 | Accepted |
Capitals make no difference to that check.