Reference

Administration & 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.

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, all shipping in the base-install schema and re-created idempotently by the module migrations (tracked in migrations_security). 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 core Users_model::authenticate() runs on every sign-in attempt, 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. Every one is an idempotent guard: the tables already ship in the base-install schema, so on an existing database each migration is a no-op (table_exists() → return, then CREATE TABLE IF NOT EXISTS). They exist so the module is self-contained for fresh installs and newly provisioned tenants. All are reversible.

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