Security Reference Public

Administration

Administer the ERPat Security module — the single always-on module_security setting, the eight permission groups covering Device Management, Offsite Access, Locked Accounts, Active Sessions and Access Logs, the four-item Security menu, and audit logging of every sensitive action.

Guide version: r1 Module version: 1.1.0 Updated: 2026-08-28 Estimated time: 12 min 10 views 0% helpful
You are viewing version r1 of this guide. View the current version
Administration & Reference

Administration

How the module is enabled, which toggles control which menu items, who can do what, and how every sensitive action is recorded. This is the control panel for the whole Security section.

Enablement model

Security uses a three-level enablement model: one umbrella that is always on, and two legacy sub-toggles that individually gate two of the three tools.

SettingDefaultControlsCan turn off?
module_security umbrella On (seeded) Whether the Security module and its whole menu slice are available. Nocan_disable = false. It is listed in Manage Modules but has no disable switch, so the Security tools are always present.
module_offsite_access sub-toggle Per install The Offsite Access menu item and screen. Yes — turning it off hides Offsite Access without affecting the other tools.
module_access sub-toggle Per install The Access Logs (Access Device Logs) menu item and screen. Yes — turning it off hides Access Device Logs.
ℹ️
Locked Accounts has no sub-toggle. It is gated purely by the locked_accounts permission (and the umbrella). So the three menu items are gated as: Offsite Access = permission + module_offsite_access; Locked Accounts = permission only; Access Logs = permission + module_access.
????
Why the umbrella is locked. These are safety tools — unlocking a locked-out administrator, ending a rogue session, closing an offsite window. If the module could be switched off, those levers could vanish exactly when you need them. So module_security is seeded on and cannot be disabled.

The tooling / protection-layer boundary

This module is the admin tooling. The protection layer it operates on stays in ERPat core — do not expect to configure guards, middleware, or RBAC inside this module:

ControlWhere it livesThis module's relationship
Authentication guardsCore (application/guards/)Not owned here.
Request middleware (secure headers, input sanitization, CSRF, rate-limit, IP restriction, file security)Core (application/middleware/)The IP-restriction middleware reads this module's Offsite Access grants.
Roles / permissions RBAC editorCore (Settings → Roles)This module contributes its four permission groups into it.
System audit logCore (system_logs)This module writes to it on every sensitive action.
Office-IP whitelistCore IP-restriction settingsOffsite Access grants are time-boxed exceptions to it.

Permissions

While the module is active, the Roles editor gains four Security permission groups. The keys are unchanged from before modularization, so existing role grants keep working.

Group (Roles editor)KeysStyleGoverns
Security: Offsite Access offsite_access, offsite_access_create, offsite_access_update, offsite_access_delete Dropdown — All / Specific members Viewing and managing offsite grants; "Specific" scopes the list to allowed members.
Security: Locked Accounts locked_accounts Simple View (no children) Opening the Locked Accounts page and clearing failed attempts. The core staff_support permit also grants entry.
Security: Active Sessions active_sessions, active_sessions_create, active_sessions_update, active_sessions_delete Manage (module-level) Viewing and terminating live login sessions.
Security: Access Logs access_logs, access_logs_create, access_logs_update, access_logs_delete Enabled (module-level) The whole Access Device Logs page — Logs, Devices, and Categories tabs.
????
Least privilege. Give HR / support just Locked Accounts so they can rescue lockouts. Reserve Offsite Access, Active Sessions, and Access Logs for IT/admin roles. Set the Offsite Access permit to Specific when a manager should only manage grants for their own team.

The Security menu group

The module contributes a Security sidebar section with three items. Its header coalesces with the core Security group, which also carries the separate core Device Management feature — that item is not part of this module.

ItemIconURLGated by
Offsite Accessfa-globeoffsite_accessperm offsite_access + setting module_offsite_access
Locked Accountsfa-shieldLocked_Accountsperm locked_accounts
Access Logsfa-historyaccess_logsperm access_logs + setting module_access

Each item also ships a hover description (its nav_desc_* line) for the smart sidebar and the Left Menu Customization editor. "Restore to default" reproduces exactly this three-item slice under the Security header.

Audit logging

Every sensitive action in the module writes to the tenant's own system audit log, categorized Security. Nothing sensitive happens silently. The events, with their severities:

ActionSeverityLogged as
Offsite window granted / updated / revokedwarning"Offsite access window was granted / updated / revoked"
Account unlocked (attempts cleared)warning"Account was unlocked (failed login attempts cleared)"
All sessions terminated for a userwarning"All active sessions for a user were terminated"
Single session terminatedwarning"A single active session was terminated"
Access device registered / updatedinfo"Access device was registered / updated"
Access device deletedwarning"Access device was deleted"
Device API secret regeneratedcritical"Access device API secret was regenerated"
Device category created / updated / deletedinfo / warning"Access device category was created / updated / deleted"
Access log entry deletedwarning"Access log entry was deleted"
????
Secrets are never logged. When a device is created or its secret rotated, the API secret value is not written to the audit log — only the fact that it happened, and which device. Secrets are stored hashed at rest.

Next steps

Report a content problem