FAQ

By design. The umbrella setting module_security is seeded on and locked (can_disable = false), so the safety tools — banning a device, unlocking accounts, ending sessions, closing offsite windows — are always available. There are no per-tool on/off switches: the module has exactly one setting, and who sees each of the four tools is purely a permissions decision in Settings → Roles. See Administration → Enablement.

No — it's the tooling on top of the protection. The actual protection (authentication guards, the request middleware pipeline, the Roles/permissions RBAC editor, and the audit log) lives in ERPat core and runs whether or not you ever open these screens. This module gives you the admin levers those controls need. See the boundary table on Home.

Yes. All four tools were relocated from core into this module with their permission keys unchanged, and the six tables already ship in the base install, so no data migration was needed. Existing grants keep resolving and every web address is the same as before. One thing to do after upgrading to 3.0.0: opening Device Management now requires the new device_management permission, so grant it to the roles that should keep using that screen. Administrators bypass permission checks and are unaffected.

That browser has been banned for them. Go to Security → Device Management, pick the person in the filter, switch the Status filter to Banned, find the row, and use the history action to restore it. Confirm, and they can sign in from that browser again. A ban only ever covers one person on one browser — which is exactly why their other devices still work.

Check these three, in order: (1) you must pick a person or a team in the filter first — the Entries list stays empty until you do, because it is scoped to whoever you asked about; (2) a device only appears once it has been used to sign in, so a brand-new laptop shows up after its first successful login, not before; (3) the Status filter defaults to Active, so already-banned devices stay hidden until you switch it to Banned.

No. A ban blocks one person on one browser — that combination and nothing else. Their account stays active, their password is untouched, and they can still sign in from any other browser or device. If you need to stop someone signing in everywhere, that's a different job: use Locked Accounts & Active Sessions to end their live sessions, and disable the account itself.

Banning and lifting a ban are separate permissions, so you can hand out looking and acting independently: device_management opens the page, block_device allows banning a device, and unblock_device allows restoring one. Someone holding only device_management can review the list but not act on it. The Groups tab is governed separately by device_management_groups (with its own create / update / delete). Administrators bypass every one of these checks.

It was retired in 3.0.0. Device Management now belongs to the Security module, which is always on, so it no longer has its own row in Settings → Manage Modules. Visibility is purely a permission decision now — grant device_management to the roles that should see it. In practice a fresh install behaves as it always did: the page is visible to administrators, and to nobody else until you grant it.

Labelling, and nothing more. A group puts a friendly name (say Company Chromebooks) on a browser/user-agent string so you can filter the Entries list by it. A group grants nothing and blocks nothing — putting a device in one neither allows nor prevents a sign-in. Only a ban does that.

Check three things: (1) the grant's date window covers today; (2) you granted it to the right person (the save creates one row per selected user); (3) an office-IP restriction is actually being enforced — an offsite grant is an exception to the core IP whitelist, so if no restriction is configured there's nothing to relax. Also confirm the grant wasn't revoked.

Many — one grant row per staff member resolved from your selection. Editing a grant, by contrast, changes a single row. Revoke each row individually when the need ends (or set a short end date so they lapse on their own).

It's a permission, not a toggle. Grant the offsite_access permission in Settings → Roles and the item appears. There is no module_offsite_access sub-toggle any more — the Security module has a single, always-on setting, so nothing in Manage Modules can hide this item.

Security → Locked Accounts, find the person on the Browse tab, and choose Clear Attempts from the row actions. That resets the failed-attempt counter and re-enables login immediately. Use Reset Password too if they've forgotten it.

On the Active Sessions tab, find the user and choose Logout All Devices. That terminates every live session at once. To end just one specific session, use View Sessions and terminate the individual entry.

The Locked Accounts page opens for holders of either the locked_accounts permission or the core staff_support permit — so a support role can rescue lockouts without being granted the other Security tools.

ERPat generates them automatically when you save a new device — an API key (UUID) and a hashed API secret. View the key via the key icon on the device row; rotate the secret with Generate new secret. The secret is stored hashed and is never shown or logged in clear text.

Rotate the secret immediately (Generate new secret) or delete the device. Rotation is recorded as a critical audit event and invalidates the old secret, so update the physical device with the new value afterwards.

The staff members allowed through that device — stored on the device record. The device row shows a count of passes; open it to see the members list.

It's a permission, not a toggle. Grant the access_logs permission in Settings → Roles — that one permission governs the whole page (Logs, Devices and Categories). There is no module_access sub-toggle any more; the Security module has a single, always-on setting.

Yes — every device ban and restore, every grant/revoke, unlock, session termination, and device add/rotate/delete writes a row to the tenant's own system audit log under the Security category. Banning and restoring a device were not recorded before 3.0.0; they are now, along with any change to a device group. See the full event list on Reference → Audit-log events.

No. Creating a device or rotating its secret logs the event and which device, but never the secret value itself.