Daily Operations

Using Security

Daily Operations

The click-by-click procedures for the four Security tools. Each one is a short, repeatable task an administrator or support user performs — and each sensitive action leaves a row in your audit log.

Tool 1 — Device Management

What it is. A view of the browsers and devices your people sign in from, and a switch to ban one of them. A ban blocks a single person + browser pair: that staff member can no longer sign in from that browser, while their account and their other devices keep working normally. The page has two tabs — Entries and Groups.

Where. Security → Device Management (the first item in the Security menu)  ·  Permission: device_management to open the page, block_device to ban a device, unblock_device to lift a ban, and device_management_groups (with _create / _update / _delete) for the Groups tab.

Find a person's devices

1. Open the page

   Go to Security → Device Management. It opens on the Entries tab.

2. Pick a person or a team first

   The list stays empty until you choose someone. Use the user filter in the toolbar and select a staff member — the picker also accepts a whole team. The table fills in as soon as you do.

3. Read the rows

   Each row is the most recent sign-in for one person on one device (one browser / user agent), showing Session ID, User, Remarks, IP Address, User Agent, Last Online and Status — either Active (green) or Banned (red).

4. Narrow it down

   Two extra filters help on busy accounts: Status (Active or Banned — it defaults to Active) and Device Group (see below).

Ban a device

1. Find the row

   Pick the person as above, then locate the device you want to stop. It has to be Active — a device already banned shows the restore action instead.

2. Click the ban action

   In that row, click the ! action button to open the short ban form. Needs block_device.

3. Type a reason — it is required

   Fill in Remarks explaining why you are banning it, e.g. "Laptop reported stolen, ticket #4821". The form will not save without it, and the reason is what future readers of the row (and of the audit log) will see.

4. Save

   The row turns Banned (red). From that moment, when that person tries to sign in from that browser the sign-in check turns them away. The ban is written to your audit log with your name and your remarks.

Restore (unban) a device

1. Show the banned rows

   Pick the person, then set the Status filter to Banned. The list defaults to Active, so a banned device stays hidden until you switch the filter — this is the usual reason a ban "disappears".

2. Click the restore action

   On the banned row, click the history action button. Needs unblock_device.

3. Confirm

   Confirm the restore. The row returns to Active and the person can sign in from that browser again straight away. The lift is recorded in your audit log as well.

Create and use a Device Group

A Device Group is a friendly name for a kind of device — "Company Chromebooks", "Warehouse tablets" — so you can filter the Entries list instead of reading raw user-agent text.

1. Open the Groups tab

   On Security → Device Management, switch to Groups. Needs device_management_groups.

2. Add a group

   Click Add and fill in a Title, the User Agent text that identifies those devices, and a Status of Active or Inactive. Save. Edit or delete it later from the row actions.

3. Use it as a filter

   Go back to Entries, pick your person, then choose the group in the Device Group filter to see only that kind of device.

---

Tool 2 — Offsite Access

What it is. Some tenants restrict sign-in to a whitelist of office IP addresses. An Offsite Access grant is a time-boxed exception: it lets a named staff member sign in from anywhere between a start date and an end date. ERPat's core IP-restriction middleware reads these grants on every request, so the exception applies automatically while the window is open and stops the moment it ends.

Where. Security → Offsite Access  ·  Permission: offsite_access (with _create / _update / _delete for the actions).

Grant an offsite window

1. Open the page

   Go to Security → Offsite Access. The table lists current grants with their start/end dates, the employee (ID number, name, job title, department), who created it, and when.

2. Add a grant

   Click Add to open the form. Pick one or more staff members (the picker accepts individual people and whole teams), then set the Start date and End date of the window.

3. Save

   Saving creates one grant row per selected staff member. An audit-log entry "Offsite access window was granted" is written. Those users can now sign in from off-network until the end date passes.

Edit or revoke a grant

• Edit (pencil icon, needs offsite_access_update) — change the employee or the start/end dates on an existing grant. Logs "Offsite access window was updated".
• Revoke (✕ icon, needs offsite_access_delete) — a confirmation prompt, then the grant is removed. Logs "Offsite access window was revoked". The person immediately loses the exception (subject to the whitelist again).

---

Tool 3 — Locked Accounts & Active Sessions

What it is. One page, two tabs. Locked Accounts is where you rescue someone locked out after too many wrong passwords. Active Sessions is where you see and end people's live logins.

Where. Security → Locked Accounts  ·  Permission: locked_accounts for the page (holders of the core staff_support permit can also reach it); active_sessions governs session management.

Unlock a locked account

1. Open the Browse tab

   Security → Locked Accounts opens on the Browse tab, which lists staff whose accounts are currently locked — with their login-attempt count and the time of the last attempt. Filter by department, establishment, or label.

2. Clear the attempts

   In the row's action menu choose Clear Attempts. This resets the failed-attempt counter to zero, clears the last-attempt timestamp, and re-enables login — the account is unlocked immediately.

3. (Optional) Reset the password

   The same action menu offers Reset Password if the user also needs new credentials. An audit entry "Account was unlocked (failed login attempts cleared)" is recorded, and the unlocked user is notified.

View & end active sessions

1. Open the Active Sessions tab

   Switch to the Active Sessions tab. It lists staff users who currently have live logins, each showing a count of active sessions.

2. Inspect a user's sessions

   Choose View Sessions to open a modal listing that user's individual sessions with session ID and last-activity time.

3. Terminate one session

   Inside the modal, Terminate Session ends a single login (e.g. a forgotten sign-in on a shared PC). Logs "A single active session was terminated".

4. Or log the user out everywhere

   From the row's action menu, Logout All Devices ends every session for that user at once — the go-to response for a lost device or a compromised account. Logs "All active sessions for a user were terminated".

---

Tool 4 — Access Device Logs

What it is. A register of your physical door/access devices and a history of the access events they record. The page has three tabs — Logs · Devices · Categories. Each device holds an API key and API secret that the physical device uses to identify itself when it reports an access event. (Not to be confused with Device Management, which covers the browsers people sign in from.)

Where. Security → Access Logs  ·  Permission: access_logs (governs the whole page and all three tabs).

Set up categories first

1. Open the Categories tab

   On Security → Access Logs, switch to Categories. Categories group your devices (e.g. "Main entrance", "Server room", "Parking gate").

2. Add a category

   Click Add, give it a Title and an optional Detail, and save. Logs "Access device category was created". Edit or delete from the row actions later.

Register a device

1. Open the Devices tab

   Switch to Devices. Click Add.

2. Fill the device in

   Give it a Device name, pick its Category, add optional Remarks, and choose the passes — the staff members allowed through this device.

3. Save — credentials are generated

   On save, ERPat generates the device's API key and a hashed API secret automatically. Logs "Access device was registered". The device is enabled by default.

View or rotate a device's credentials

1. Open the credential dialog

   In the device's row, click the key icon (Show Secret) to view the API key the physical device needs.

2. Rotate the secret

   Use Generate new secret to regenerate the API secret — the new value is hashed at rest and the old one stops working. This is logged as a critical event, "Access device API secret was regenerated" (the secret value itself is never written to the log). Update the physical device with the new secret.

Review the access history

1. Open the Logs tab

   Security → Access Logs opens on the Logs tab — the history of access events: which device, which person, an optional remark (e.g. entry / exit), and the timestamp (shown in your local time).

2. Filter

   Narrow by device and by a date range to investigate a specific door or window of time.

3. Remove a bad entry

   If an event was recorded in error, delete it (needs access_logs access). Logs "Access log entry was deleted".

---

Everything you do here is audited

Each sensitive action above writes a row to the tenant's own system audit log, tagged to the Security category. That trail is your evidence of who banned or restored a sign-in device, granted an exception, unlocked an account, ended a session, or touched an access device — review it in the audit-log screens. The exact event names and severities are listed on Reference → Audit-log events.

Next steps