Security Reference Public

Getting Started

Enable the ERPat Security module, run its migrations, confirm the always-on umbrella setting, and grant the Device Management, Offsite Access, Locked Accounts, Active Sessions, and Access Logs permissions so administrators can start using all four tools.

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

Getting Started

The Security module is always available — but the individual tools and who can use them still need a little setup. This page takes an administrator from a fresh install to a working Offsite Access, Locked Accounts / Active Sessions, and Access Device Logs.

????
Who this is for. An administrator who can reach Settings → Manage Modules and the Roles editor. Day-to-day operators can jump straight to Daily Operations once the steps below are done.

Prerequisites

  • PHP ≥ 8.2 and ERPat core ≥ 1.10.0 — required by the module manifest.
  • Admin access to the Roles editor (Settings → Roles) for granting permissions.
  • Staff users must already exist — Offsite Access windows and access-device passes are assigned to active staff members.
  • Your office IP whitelist should be configured (a core setting) for Offsite Access to be meaningful — a grant is an exception to that whitelist. If no IP restriction is enforced, an offsite grant simply has nothing to relax.

The module is on by default

Unlike most modules, Security cannot be turned off. Its umbrella setting module_security is seeded on and locked — it is listed in Settings → Manage Modules under the Security category but has no disable switch (can_disable = false). That guarantees the Security tools are always reachable. See Administration for the full toggle map.

????
Upgrading from the old in-app screens? Nothing is lost. Offsite Access, Locked Accounts / Active Sessions, and Access Device Logs previously lived in core; they were relocated into this module with their permission keys unchanged, so existing role grants keep working with no data migration. The four backing tables already ship in the base install, so the module's migrations are guarded no-ops on your database.

Activation — two steps

  1. Run the module migrations

    From the project root. The migrations are idempotent (CREATE-IF-NOT-EXISTS) and are tracked in the module's own migrations_security table. On an existing database they do nothing; on a fresh install or a newly provisioned tenant they create the four tables.

    php erpat migrate:modules
    # (or) php erpat migrate:latest
  2. Grant permissions in Roles

    Go to Settings → Roles and give the right roles the four Security permission groups (below). Administrators see everything by default. That's it — there is no module to "switch on".


What the migrations create

Four tables, one per feature area. All four already exist in the base-install schema, so on an existing tenant these run as no-ops:

TableFeatureHolds
offsite_accessOffsite AccessOne row per grant — user, start date, end date.
access_device_categoriesAccess Device LogsDevice category — title, detail, status.
access_devicesAccess Device LogsEach device — name, category, API key/secret, its "passes" (allowed staff), status.
access_logsAccess Device LogsEach access event — device, user, remark, timestamp.

Locked Accounts & Active Sessions has no table of its own — it reads existing columns on the users table (failed-attempt counters) and the core session store (ci_sessions). Full schema on the Reference page.


Granting access in Roles

While the module is active, four Security permission groups appear in the Roles editor. Grant them to the roles that need each tool:

Roles-editor groupBase keyStyleUnlocks
Security: Offsite Access offsite_access (+ _create / _update / _delete) Dropdown — All / Specific members The Security → Offsite Access page and the grant/edit/revoke actions.
Security: Locked Accounts locked_accounts Simple View The Security → Locked Accounts page (its Browse tab) and the "Clear Attempts" unlock action. (Holders of the core staff_support permit can also reach it.)
Security: Active Sessions active_sessions (+ _create / _update / _delete) Manage (module-level) The session-management capability on the Active Sessions tab — view, terminate a single session, log a user out of all devices.
Security: Access Logs access_logs (+ _create / _update / _delete) Enabled (module-level) The whole Access Device Logs page — all three tabs (Logs, Devices, Categories).
ℹ️
Permission keys are frozen. The keys above are exactly the ones the features used before modularization, so any grants you already have keep resolving. The full key list and how each maps to a screen is on Reference → Permissions.

With the permissions granted, a Security section appears in the left sidebar. This module contributes three items (a fourth, Device Management, is a separate core feature that shares the same "Security" header):

Menu itemOpensShown when
Offsite AccessThe Offsite Access grants page.offsite_access permission and the module_offsite_access sub-toggle is on.
Locked AccountsThe two-tab Locked Accounts / Active Sessions page.locked_accounts permission (no sub-toggle).
Access LogsThe three-tab Access Device Logs page.access_logs permission and the module_access sub-toggle is on.

First-run checklist

????
Purpose: go from a fresh install to a usable Security section.
Who: an administrator.
Preconditions: migrations run, at least one active staff user.
  1. Run the migrations

    php erpat migrate:modules — confirms the four tables exist.

  2. Grant the four permission groups

    In Roles, give IT/admin roles Offsite Access, Locked Accounts, Active Sessions, and Access Logs. Give HR/support at least Locked Accounts.

  3. Confirm the sidebar

    Reload and check the Security group shows Offsite Access, Locked Accounts, and Access Logs. If one is missing, check its sub-toggle (Administration page).

  4. Seed your access-device categories

    Only if you use door/access devices: open Access Logs → Categories and add a category or two before registering devices.

  5. Try one action end-to-end

    Follow a procedure on Daily Operations — e.g. grant a short offsite window to yourself — and confirm it appears in the tenant's audit log.

Next steps

Report a content problem