Users and Roles

Access to the WMS is controlled through a role-based access control (RBAC) system. Users are assigned roles, and roles are granted specific permissions.

---

Concepts

Permissions

A permission is a specific action on a specific resource, written as action:resource. For example:

• create:inbound-order — can create inbound orders
• read:audit-log — can view the audit log
• *:* — superuser access (all actions on all resources)

Access checks match the required permission exactly, or fall back to the single super-permission *:*. There is no manage shortcut that expands to create/read/update/delete, and no partial wildcards like read:* or *:warehouse. To grant broad access you either list each create/read/update/delete permission explicitly, or assign *:*. See the Permissions Reference for the full list of what is actually enforced.

Roles

A role is a named collection of permissions. You assign roles to users instead of assigning permissions directly. This makes it easy to manage access for groups of users with the same responsibilities.

Roles are custom — the system does not ship with pre-built roles. You create roles that match your team structure.

Users

A user is a person who logs in to the WMS. Each user is assigned exactly one role, and that role’s permissions are their effective permissions. Each user also belongs to a single warehouse. (To give someone a different mix of permissions, change their role or adjust the role’s permissions — you cannot stack multiple roles on one user.)

---

Setting up roles

User, role, and permission management all live under Admin → Users & Roles in the sidebar — a section visible only to users whose role name is admin or superadmin.

Creating a role

1. From the Admin area, open the Create Role form
2. Enter a name (e.g., Warehouse Operator, Receiving Team, Manager)
3. Save the role

Assigning permissions to a role

Permissions are granted on the role-permissions screen, where you grant or revoke individual permissions for the selected role.

1. Select the role
2. Grant each action:resource permission the role should have, and revoke any it shouldn’t (remember: grant the concrete actions — manage:* and read:* do nothing; see below)

Repeat until the role has the permissions needed for that job function.

Example role configurations

Because there is no manage shortcut and no wildcards (other than *:*), grant each concrete permission you need.

Receiving Operator — can work with inbound orders only:

• create:inbound-order, read:inbound-order, update:inbound-order
• read:warehouse-item, read:bin, read:lot

(There is no separate inbound-line permission — lines are managed through the order, and update:inbound-order covers start-receiving, recording receipts, and completing.)

Warehouse Operator — full day-to-day warehouse operations:

• create:inbound-order, read:inbound-order, update:inbound-order
• create:outbound-order, read:outbound-order, update:outbound-order
• create:transfer-order, read:transfer-order, update:transfer-order
• create:stock-count, read:stock-count, update:stock-count
• read:warehouse-item, read:bin, read:lot, read:zone, read:aisle, read:rack, read:shelf

(Stock adjustments are not permission-guarded, so no permission is needed — or available — to post them.)

Warehouse Manager — full operational access plus configuration. List the locations/catalog actions explicitly:

• Everything the Warehouse Operator has, plus:
• create:warehouse-item, read:warehouse-item, update:warehouse-item
• create:category, read:category, update:category, delete:category
• read:inventory-transaction, read:audit-log
• For each of zone, aisle, rack, shelf, bin: create, read, update, delete

System Administrator — full access:

• *:*

---

Managing users

Creating a user

1. In the sidebar, open Admin → Users & Roles
2. Add a new user and enter their details
3. Save

Assigning a role to a user

1. On the Users & Roles screen, find the user
2. Set their role (selected from the roles you created)
3. Save

A user’s effective permissions come from their assigned role.

Removing access

To restrict a user, reassign them to a role with fewer (or no) permissions. To permanently remove access, delete the user record.

---

Audit trail

Key actions performed by users (creating and modifying records) are recorded in the Audit Log. Each entry records:

• The user who performed the action
• The action type (create, read, update, delete)
• The resource affected and its before/after state
• The user’s IP address and browser
• The timestamp

The audit log is read-only. Use it to investigate discrepancies or review who changed what.

To view the audit log, open History → Audit Log in the sidebar. You need the read:audit-log permission.