Reference

Reference

The data-and-screen reference for the Security module's four admin tools — controllers, routes, models, views, migrations, tables, permission keys, menu entries, and audit-log events. Everything here is drawn from the live module source; see Research for the exact files.

Controllers

All seven extend App_Controller (staff, session-authenticated). Every constructor opens with the module's single always-on guard with_module('security') — there are no per-tool module_* sub-toggles left — and then applies its own permission: Device Management on device_management; its Groups tab on device_management_groups; Offsite Access on offsite_access; all three Access Device controllers on access_logs; Locked Accounts on locked_accounts (or the core staff_support).

Per-action gates sit on the individual methods: block_device on ban_device_modal_form + ban_device, and unblock_device on restore_device_modal_form + restore_device. The row builder (make_row) checks the same two keys, so a user without them sees the row but no action button.

Routes

Declared in modules/Security/config/routes.php (mixed-case/underscore controllers need explicit lowercase routes). The (:any) catch-alls map to controller methods.

Models

Six models, all extending Crud_model and living in modules/Security/models/. All SQL lives here — never in a controller or view.

Sign-in check registration

Declared in modules/Security/config/auth_checks.php. Core Users_model::authenticate() calls erpat_run_auth_checks() (in application/helpers/module_compatibility_helper.php), which reads every module's config/auth_checks.php, resolves each declaration and runs it in priority order. This module declares exactly one entry.

pre_auth_check() returns nothing to allow the sign-in, or a verdict to deny it. Its denial code device_banned is one core routes verbatim, so authenticate() returns the same literal sentinel it always did and nothing a user sees has changed: the sign-in form still shows "Access from this device is restricted." and still writes a banned_device_attempt activity-log row. A code core does not route is downgraded to a plain authentication failure. If the banned_devices table is missing — a database that never ran php erpat migrate:modules — the check logs that and denies, rather than failing open or fataling.

Views

19 view files under modules/Security/views/, namespaced one directory deep so the loader cascade cannot collide with another module.

Database tables

Six tables, created only by this module's own idempotent migrations (tracked in migrations_security) — none of them ships in the base-install schema. All carry the standard updated_at + deleted audit columns.

banned_devices

One row per active ban — a person plus the browser (user agent) they may no longer sign in from. Restoring a device soft-deletes its row.

Indexed (user_id, http_agent(191), deleted) — that exact triple is the lookup Banned_devices_model::pre_auth_check() runs on every sign-in attempt (core reaches it through the sign-in check declaration), so it carries a covering index.

device_management_groups

Named user-agent groups used to label and filter the Entries list. A group grants nothing and blocks nothing.

Indexed on (status, deleted) and on user_agent(191), which is joined against system_logs.http_agent to bucket sign-in devices.

offsite_access

access_device_categories

access_devices

access_logs

Migrations

Six module migrations in modules/Security/migrations/, run by php erpat migrate:modules against the per-module migrations_security version table. They are the only source of these six tables — nothing here ships in the base-install schema — and every one is written as an idempotent guard (table_exists() → return, then CREATE TABLE IF NOT EXISTS), so re-running them against a database that already has the tables is a no-op. All are reversible. A database that has never run migrate:modules therefore has no banned_devices table, and the sign-in check treats that as a reason to deny — see Sign-in check registration.

Retirement migrations live in CORE (they touch the shared settings table, so they belong in application/migrations/, not here): 20260730213157_retire_device_management_setting.php carries any module_device_management = 1 forward onto module_security and then drops the orphaned row; 20260730204800_retire_core_submodule_settings.php did the same for module_offsite_access and module_access in the previous release. Nothing is lost — the tools simply stop having their own on/off rows.

Permission keys

Keys are unchanged from the core declaration. device_management_groups, block_device and unblock_device keep the exact key names, categories and actions they had as core rows, so serialized grants already stored in users.permissions / roles.permissions keep resolving with no data migration. The legacy rows were deleted from application/helpers/permission_catalog_helper.php in the same change — a core row shadows a module declaration, so leaving them would have kept the module's block inert. Admins bypass every permission check.

Not owned here: staff_support (Staffing) and api_clients (Security: API Clients) remain core-owned; the core IP-restriction block event offsite_access:ip_security is emitted by core middleware, not this module.

Settings & menu

Menu entries (config/menu.php), in rendered order: Device Management (fa-mobile, position 160) · Offsite Access (fa-globe, 161) · Locked Accounts (fa-shield, 162) · Access Logs (fa-history, 163). Since Device Management moved in, this module owns the whole Security sidebar section — the core slice in application/config/left_menu.php was emptied and removed, so there is no longer a core group to coalesce with (default_menu.php, position 160).

Audit-log events

Keyed action:component in config/system_logs.php, merged into the core audit-log config. Written on every sensitive mutation.

Next steps