Users

The users of BPMS are the users of BPMS 3.x: the same accounts, with the same roles and tenants. The operations below work on the users of your tenant only, and require the BPMS 3.x authorities of the user administration.

Roles are assigned to users and removed from them on Roles and authorities.

List the usersCopy Anchor Link

curl -sS -H "Authorization: Bearer $TOKEN" "$BPMS_URL/api/v1/access/users?page=0&size=20&sort=userName"

page starts at 0, size is 20 by default and at most 100, and sort is userName (the default) or id. Disabled users are listed; deleted users are not. The answer is one page:

{
  "items": [
    {"id": 7, "userName": "jdoe", "name": "Jane", "lastName": "Doe", "identification": "1020304050",
     "email": "jdoe@example.com", "enabled": true, "locked": false, "passwordChangeRequired": false}
  ],
  "page": 0, "size": 20, "totalElements": 1, "totalPages": 1
}

Read a userCopy Anchor Link

curl -sS -H "Authorization: Bearer $TOKEN" "$BPMS_URL/api/v1/access/users/7"

It answers 200 with the same fields as an item of the list.

Create a userCopy Anchor Link

Put the new user in a user.json file kept out of version control, so the password stays out of your shell history:

{"userName": "jdoe", "name": "Jane", "lastName": "Doe", "identification": "1020304050",
 "email": "jdoe@example.com", "password": "<password>", "roleIds": [3]}

curl -sS -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  "$BPMS_URL/api/v1/access/users" -d @user.json

It answers 201 with the new user and its address in the Location header.

Unless the tenant has unlimited users, its BPMS 3.x license caps the number of enabled users. When the tenant has no free place, an enabled user is refused with access.user-capacity-reached; a user created disabled takes no place.

Update a userCopy Anchor Link

curl -sS -X PATCH -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  "$BPMS_URL/api/v1/access/users/7" -d '{"lastName": "Smith"}'

The body carries any of userName, name, lastName, identification, and email, with the rules of creating a user; a field left out keeps its value, and an empty email removes it unless the installation requires it. It answers 200 with the user. Roles, password, and status have their own operations. A user may update itself.

Disable, enable, and delete a userCopy Anchor Link

curl -sS -X POST -H "Authorization: Bearer $TOKEN" "$BPMS_URL/api/v1/access/users/7/disable"
curl -sS -X POST -H "Authorization: Bearer $TOKEN" "$BPMS_URL/api/v1/access/users/7/enable"
curl -sS -X DELETE -H "Authorization: Bearer $TOKEN" "$BPMS_URL/api/v1/access/users/7"

Each answers 204, also when nothing changes.

• Disabling and deleting close at once all the user's sessions, including those of AI agents. Enabling the user again does not reopen them.
• Enabling needs a free place in the tenant's license.
• Deleting keeps the user in the database, marked as deleted, as BPMS 3.x does; the user is no longer listed and answers 404 from then on.
• You cannot disable or delete yourself.

Reset a user's passwordCopy Anchor Link

Put the new password in a password.json file kept out of version control:

{"password": "<new password>", "mustChangePassword": true}

curl -sS -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  "$BPMS_URL/api/v1/access/users/7/password" -d @password.json

It answers 204. The administrator chooses the new password; BPMS neither generates nor returns one.

• mustChangePassword is true by default, so the user must change the password at the next sign-in; false lets the user sign in normally.
• It closes all the user's sessions, including those of AI agents.
• It does not unlock a locked user.
• You cannot reset your own password; change it as described in Authentication.

Password policyCopy Anchor Link

Every new password, set when creating a user, resetting one, or changing your own, follows the installation's policy. Its defaults are the BPMS 3.x rule:

A line break is always refused. A password that breaks the policy answers 400 with one error per broken rule.

Rules and errorsCopy Anchor Link

Every change, and every refusal for a missing authority, is recorded in the audit log. A refused request changes nothing.

In the OpenAPI document, the operations are listUsers, getUser, createUser, updateUser, disableUser, enableUser, deleteUser, and resetUserPassword, under the access tag.