Users Page

Users

The Users page is your list of Admin Panel login accounts — the people who sign in with email and password to manage the shop. Each user has a name, an email, a role, an assigned User Group that controls what they can see, and (optionally) API keys for programmatic access.

Open it from the main sidebar (Users) or by navigating to /users.

Users vs Employees. A user is an account that logs into the Admin Panel — managers, planners, foremen, back-office. An employee is a shop-floor worker who taps a PIN on the Kiosk. They are two separate identities. See Users vs Employees below for how the two intersect.

---

Table of contents

1. What this page is for
2. Anatomy of the page
3. Reading the table
4. The three roles
5. Searching
6. Adding a user
7. Editing a user — the User panel
8. General tab
9. Workstations tab
10. API Keys tab
11. User Groups
12. Users vs Employees
13. Two-factor authentication
14. Deleting a user
15. Tips and best practices

---

What this page is for

The Users page is your roster of Admin Panel accounts. Use it to:

• Onboard new colleagues — create a login, pick a role, assign a User Group, hand over the password.
• Control access — User Groups (managed in App Settings → User Groups) decide which modules and which kanban views a person can see.
• Issue PINs for hybrid users — a planner who also clocks in on the floor can have both an email/password and a PIN.
• Manage API keys — for users who need to drive the API from a script or integration.
• Audit and rotate — see who has access, when they last verified email, and remove access cleanly when someone leaves.

Most shops keep this list short — typically the owner, one or two managers, a planner, and (sometimes) the supervisor. Shop-floor workers go on the Employees page instead.

---

Anatomy of the page

This page is admin-only — only users with the admin role see the search box, the Show N entries selector, the Add User button, and the pagination. Non-admin users see the table itself (so they can find their own row to edit their profile) but not the management controls.

For admins, from left to right across the top:

• Search box — search by name or email.
• Show N entries selector — 5 / 10 / 25 / 50 / 100 per page.
• Add User button (top-right).

Below the toolbar sits the users table, one row per user. Standard pagination underneath.

---

Reading the table

Column	What it shows
ID	Internal numeric ID.
Name	Full name.
Email	Login email (also the contact address).
Role	One of Admin, User, or Employee, shown as a colored pill. See The three roles.
Email Verified	Date the user clicked the verification link (or - if they haven’t).
Created	When the account was created.
Actions	Pencil — opens the edit panel.

---

The three roles

Every user has one of three roles, picked when the account is created and editable later:

Role	Use case
Admin	Full access. Can manage all users, all settings, all data. Typically the owner and one or two trusted seconds.
User	Standard Admin Panel account. Permissions are governed by the assigned User Group — they can see only the modules and kanban views the group allows. The role for most planners, managers, and back-office staff.
Employee	A user who also has Kiosk PIN access. Sees the Admin Panel only insofar as the User Group allows, and additionally has a PIN for clocking in on the floor. See Users vs Employees.

Role determines the maximum permissions; the User Group narrows them. An admin ignores the User Group (they can do anything anyway); a user or employee is constrained by it.

---

Searching

Type into the search box. The query matches Name and Email (case-insensitive, contains matching). The list refreshes about 300 ms after you stop typing.

---

Adding a user

Click Add User in the top-right. The User panel slides in from the right with an empty form.

At minimum:

• Name — full name.
• Email — login email. Must be unique.
• Password — temporary password the user will sign in with.
• Role — Admin, User, or Employee. See The three roles.

Optional:

• User Group — pick from the groups defined in App Settings → User Groups. Defaults to the group flagged as default.
• PIN — only for employee role. 4-to-8 digits, unique across employees.
• Workstations — only relevant when the user is an employee and will use the Kiosk.

Click Create. The user is created and can sign in immediately. There is no automatic email — you’ll need to share the password with them out-of-band. They can change it after first login via Settings → Password.

First admin? The very first user created during account setup is the initial admin. They can then create additional users, including more admins.

---

Editing a user — the User panel

Click the pencil icon on any row to open the panel in edit mode. The panel uses three tabs:

• General — name, email, role, User Group, password, PIN (when role is employee).
• Workstations — only relevant for employee role.
• API Keys — only available in edit mode (you need a saved user to attach keys to).

The header has two buttons:

• Save — applies your changes.
• Delete — removes the user. See Deleting a user.

---

General tab

Fields:

• Name (required).
• Email (required, unique).
• Role (required) — pick Admin, User, or Employee.
• User Group — pick from the configured groups. Hint text reminds you this controls module and view access.
• PIN (only for employee role) — 4-to-8 numeric digits, unique.
• Password / New Password — leave blank when editing to keep the existing one; type a value to change it. On a create form the field is required.

Below the form, in edit mode, you’ll find:

• Email Verified At — read-only timestamp.
• Created At / Updated At — read-only timestamps.

---

Workstations tab

Only relevant when the user’s Role is Employee. Identical to the Workstations tab on the Employees page — tick the stations this person is authorized to clock in to via the Kiosk.

For admin and user roles, this tab still appears but isn’t functional — those roles don’t have a Kiosk identity.

---

API Keys tab

Each user can issue personal API keys for programmatic access to the system — useful for integrations, scripts, and one-off automations.

The tab is only available in edit mode (you need a saved user to attach keys to). Here you can:

• Create New API Key — enter a friendly name (e.g., “Production server”, “Zapier”, “Inventory script”) and click Create.
• View / copy an existing key. Note that the full key is only shown once at creation — copy it then; you can re-view via the eye icon afterwards, but if you lose it entirely, create a new one and delete the old.
• See when each key was last used.
• Delete keys that are no longer needed.

API keys grant the same permissions as the user who created them (subject to the User Group). When that user is deleted, their keys go with them.

Treat API keys as passwords. Don’t commit them to git, don’t email them, don’t paste them in a public chat. If a key leaks, delete it from this tab — the old key stops working immediately.

For shop-level API keys not tied to a single human, use App Settings → API Keys instead.

---

User Groups

User Groups are defined in App Settings → User Groups and control:

• Module access — which top-level modules a member sees (CRM, Production, Configuration).
• View access — which kanban views and which devices (Desktop vs Mobile App).

Every user belongs to exactly one User Group (except admin users, who effectively bypass it). The Default group is what new users without a specified group are assigned to.

Common group setups:

• Planners — Production + Configuration access; all kanban views.
• Shop-floor leads — Production access only; one or two department-scoped kanban views.
• Back-office — CRM + Production; all desktop views; no mobile.
• Read-only managers — desktop access to relevant views, no edit-side modules.

Edit groups, not individual users, whenever you want to change a permission for a class of people.

---

Users vs Employees

This is the most common source of confusion in the system. The short version:

Identity	Logs in via…	Identifies via…	Used by…
User (Users)	Admin Panel email + password (+ optional 2FA)	Email + Password	Managers, planners, foremen, back-office
Employee (Employees)	Kiosk / mobile PIN modal	Numeric PIN	Shop-floor workers

They are entirely separate records by default — a User has no PIN, an Employee has no password.

To represent one person as both (e.g., a planner who occasionally works on the floor):

1. Create a User with role = Employee.
2. On the General tab, set a PIN.
3. On the Workstations tab, tick the stations they’re authorized for.

That single record now functions as both — they can sign in to the Admin Panel with email+password and clock in on the Kiosk with their PIN. Their time logs attribute to the same identity in both worlds.

For a person who is only on the shop floor (no Admin Panel access at all), prefer the Employees page over creating an employee-role User. It’s a simpler record and doesn’t take up a login seat.

---

Two-factor authentication

Two-factor authentication (TOTP / authenticator app) is managed per user via Settings → Two-Factor Auth (the user signs in and configures it themselves). It is not managed from this page — admins can’t enable 2FA on someone else’s behalf.

For shops with sensitive data (customer PII, financial info), strongly consider:

1. Requiring all admins to enable 2FA.
2. Documenting the recovery-code process so a lost authenticator doesn’t lock anyone out.

---

Deleting a user

Open the user in the panel → click the red Delete User button → confirm.

What happens:

• The login is removed — the user can no longer sign in.
• API keys belonging to the user are revoked immediately.
• Historical references (created jobs, time-log “edited by”, etc.) keep pointing to the now-deleted user id. They render as “Unknown” or blank in the UI.
• If the user was also an employee-role identity, their PIN is freed and active timers do not automatically close. Stop them first or let a Cron Job catch them.

There is no undo. For staff who leave, the safe alternative is to:

1. Change their password to something only you know.
2. Remove their User Group privileges.
3. Optionally rename their account “(Former) Jan Kowalski” so historical references stay attributable.

This preserves audit history while removing access.

---

Tips and best practices

• Use User Groups, not per-user permissions. Defining the permission once per group and then assigning users to groups is hugely less work than tuning each user.
• Have at least two Admin users. Single-admin shops get locked out when that one admin loses their device. Two trusted admins is the minimum bus-factor.
• Enable 2FA for every admin. The Admin Panel can edit anything; password-only auth is too thin a defense if your business depends on it.
• Roles vs Groups: roles set the maximum; groups narrow it. admin users ignore the group; user and employee are constrained by it.
• Reserve employee role for hybrid users. For a person who only does shop-floor work, use the Employees page — it’s the simpler record and doesn’t consume a login seat.
• Treat API keys as production secrets. Name them after the system that uses them, rotate them when that system changes hands, delete unused ones.
• Don’t share accounts. If two managers both manage Production, give them their own logins — audit trails are useless when “who did this?” answers “the shared account”.
• For departing staff, change password + remove from groups rather than deleting. Preserves audit history without leaving access open.
• Document the recovery flow. Lost-2FA, forgotten-password, departing-admin-with-the-only-key scenarios — write down the steps for your shop while everything is calm.
• Pair this with the Employees page for the full picture of who can do what in the system — admin via login on this page, shop-floor access on Employees, hybrid users in both.