Assets Reference Public

Permissions & Roles

Process & Reference Permissions & Roles The complete access-control reference for the Assets (Safekeep) module — where permissions are granted, every permission key the module…

Guide version: r1 Module version: 1.0.0 Updated: 2026-07-22 Estimated time: 11 min 1 views
Process & Reference

Permissions & Roles

The complete access-control reference for the Assets (Safekeep) module — where permissions are granted, every permission key the module publishes with exactly what it gates, the actions that are gated by identity instead of a key, and five ready-made role presets you can copy into your own Role editor.

????
Who this is for. This page is for an administrator deciding who gets to see and do what in Safekeep. If the module is not enabled yet, start with Getting Started — permission categories only exist in the Role editor while the module is switched on.

How access control works

Safekeep uses ERPat's standard role-based access control. Two independent switches must line up before a user can reach a feature:

????
The module toggle

The tenant-wide switch module_assets, set in Settings → Manage Modules (the module is listed under the Safekeep category). While it is off, the entire Safekeep sidebar group is hidden for everyone — including administrators — and the module's permission categories do not appear in the Role editor.

????
Per-role permissions

Granted in Settings → Roles, per role. The module publishes its permission keys into the Role editor automatically — but only while module_assets is enabled. They appear grouped under four categories, all prefixed "Safekeep:".

ℹ️
Administrators bypass permission checks. An admin user can reach every Safekeep screen and action as long as module_assets is on. The keys below matter only for non-admin roles. One action (Clone) is also reserved for admins outright — see identity-gated actions.
asset is the master key to the whole Safekeep menu. The sidebar group "Safekeep" and five of its six menu items (Assets, Depreciations, Custom Fields, Maintenance, Asset Reports) are gated on the single base permit asset (label "Assets: Entries") — as are the Models tab of the Assets page and the Status Labels tab of the Categories page (the Categories menu item itself additionally needs asset_category). A role without asset sees no Safekeep menu at all, cannot open ams/assets (the controller redirects), and does not get the "Assets assigned to me" dashboard widget. Grant asset first — every other key in this module is meaningless without it.

SOP — granting access in the right order

????
Purpose: give a role working Safekeep access. Who: an administrator. Preconditions: module migrations have run and module_assets can be enabled (see Getting Started).
  1. Enable the module

    In Settings → Manage Modules, enable Assets (category Safekeep). This sets module_assets and makes the four "Safekeep:" permission categories appear in the Role editor.

  2. Open the role

    Go to Settings → Roles and open the role you want to change. Scroll to the categories Safekeep: Assets, Safekeep: Categories, Safekeep: Locations and Safekeep: Groups.

  3. Grant the base permit first

    Tick asset ("Assets: Entries"). This alone surfaces the whole Safekeep sidebar group and read access to the registry, catalogs and reports.

  4. Add action permits where needed

    Tick the specific keys for what the role should do: create/update/delete assets, checkout, audit, maintenance, import, export, comments, labels. For the Location tab on the Assets index, the Safekeep → Categories page and its Groups tab, grant their own category's base key (location / asset_category / asset_groups) — the tab or page is hidden without it.

  5. Save and verify

    Save the role, then sign in as (or ask) an affected user: the Safekeep group should appear in the sidebar and the granted buttons should show on ams/assets.


Permission reference

Everything the module publishes into the Role editor, grouped exactly the way the editor groups it. In each table, the key is the stored permission string, the label is what the Role editor shows, and Gates is what holding it unlocks.

Module-level parents and their children

Each of the four categories has one module-level parent permit (declared default_level => 'module'): asset, asset_category, location and asset_groups. In the Role editor the parent automatically groups its _create / _update / _delete children beneath it. The parent is the view/access grant; the children add write actions. There are no dropdown-style "specific" sub-permissions in this module — grouping is purely parent + CRUD children.

Safekeep: Assets (12 permits)

Permission keyLabel in Role editorGates
asset Assets: Entries Base access permit for the entire module (module-level parent). Surfaces the Safekeep sidebar group and its menu items (Categories additionally needs asset_category); grants read access to the asset registry, the asset detail page, Models, Status Labels, Depreciations, Custom Fields & Fieldsets, the Maintenance screen and all four Asset Reports; also required for the "Assets assigned to me" / "Assets needing attention" dashboard widgets. The key is asset (singular) — preserved from the legacy permission block so grants made before modularization keep working; it deliberately does not match the module slug.
asset_createCreate AssetThe "Add entry" toolbar button and creating assets via the add modal.
asset_updateUpdate AssetThe "Edit" row action and Edit on the detail page — including the only UI where photo, cost, order number and custom-field values can be changed. (Condition is also updatable through the Check-in and Audit modals, gated by their own keys.)
asset_deleteDelete AssetThe "Delete" row action (soft delete).
asset_manage_labelsAsset Entries: Manage LabelsThe "Manage labels" toolbar button, the Labels field in the asset form, label chips in the list, and the Label filter dropdown.
asset_commentAssets: Entry CommentsThe comment composer on the asset detail page ("Write a comment...", "Post Comment", file attach).
delete_asset_commentAssets: Delete Entry CommentsThe Delete action on comments. Comments can be deleted but never edited; static entries (the pinned description and change log) cannot be deleted at all.
asset_checkoutAssets: Checkout / EndorseBoth "Check out asset" and "Check in asset" on the detail page — the whole endorse lifecycle except the assignee-side actions (see identity-gated actions below).
asset_auditAssets: AuditThe "Audit asset" action and recording audits ("Record audit").
asset_maintenanceAssets: MaintenanceAdd / Edit / Delete on the Maintenance screen. Opening the screen itself needs only asset; the write actions need this dedicated key.
asset_importAssets: ImportThe "Import Assets" toolbar button and the whole CSV/XLSX import flow (including the template download).
asset_exportAssets: ExportBoth the "Export Assets" XLSX export and the "Print asset labels" QR/barcode PDF flow.
⚠️
The base asset permit is broader than read-only. The catalog screens Models, Status Labels, Depreciations, Custom Fields and Fieldsets gate their add / edit / delete actions on the same asset key — they have no dedicated create/update/delete permits. Anyone you grant asset can therefore also modify those catalogs. Only Assets (entries), Categories, Locations, Groups and Maintenance have finer-grained write permits.

Safekeep: Categories (4 permits)

Categories are a sidebar item of their own (Safekeep → Categories, ams/categories), directly below Assets; the page also hosts the Groups and Status Labels tabs. The sidebar entry and page appear only for holders of the base key.

Permission keyLabel in Role editorGates
asset_categoryAssets: CategoriesBase access (module-level parent): the Safekeep → Categories page and the category list.
asset_category_createCreate CategoryAdding categories.
asset_category_updateUpdate CategoryEditing categories (title, description, parent, fieldset binding).
asset_category_deleteDelete CategoryDeleting categories.

Safekeep: Locations (4 permits)

Locations are likewise an in-page tab (ams/assets"Location" tab); see Locations.

Permission keyLabel in Role editorGates
locationAssets: LocationsBase access (module-level parent): the "Location" tab and the location list.
location_createCreate LocationAdding locations.
location_updateUpdate LocationEditing locations.
location_deleteDelete LocationDeleting locations.
⚠️
Watch the bare key name. The Locations base permit is just location — no asset_ prefix — and its children follow suit (location_create, location_update, location_delete). When auditing a role's stored permissions, don't overlook it because it doesn't sort next to the other Safekeep keys.

Safekeep: Groups (5 permits)

Groups are an in-page tab of the Categories page (ams/categories"Groups" tab); see Asset Groups.

Permission keyLabel in Role editorGates
asset_groupsAssets: GroupsBase access (module-level parent): the "Groups" tab and the group list.
asset_groups_createCreate GroupAdding groups.
asset_groups_updateUpdate GroupEditing groups.
asset_groups_deleteDelete GroupDeleting groups.
asset_groups_manage_labelsAsset Groups: Manage LabelsManaging labels on asset groups (the Groups tab's own label tooling — separate from asset_manage_labels on entries).

Actions gated by identity, not by a permission key

Three actions have no permission checkbox in the Role editor. They are decided by who the logged-in user is:

ActionWhereWho may do it
"Confirm receipt" (acknowledge) Asset detail page → Actions The current assignee (the user the asset is endorsed to) or an admin. Anyone else is refused. See Checkout & Check-in.
"Request return" Asset detail page → Actions The current assignee or an admin — same identity rule as Confirm receipt.
"Clone" Asset registry → row actions Admins only. No permission key grants Clone to a non-admin role — the menu item simply never appears. Clone supports a "Duplicate" count to create several copies at once; see Adding & Editing Assets.
ℹ️
Identity-gated does not mean permit-free. To press "Confirm receipt" or "Request return", the assignee still has to reach the asset detail page — and the whole ams/assets controller requires the base asset permit. So an employee who receives equipment needs asset (and nothing else) to acknowledge it. The same base permit is what makes the "Assets assigned to me" dashboard widget render (see Widgets, Reminders & Settings).

Shared masters: Vendors and Brands

Suppliers/Vendors and Manufacturers/Brands are not owned by this module — they are shared core masters (vendors and brands tables) reachable at ams/vendors and ams/brands. Their permits, vendor and brand, live in the core Role editor blocks, not in any "Safekeep:" category. A user who should manage suppliers or manufacturers referenced by assets needs those core permits in addition to the Safekeep keys above.


Suggested role presets

These five presets are conventions, not shipped roles — ERPat does not create them for you. They map cleanly onto how most organizations split asset work; copy the checkbox pattern from the table below into your own roles in Settings → Roles. The Workflows & SOPs page uses the same role names.

IT Asset Administrator IT Technician Auditor Finance Employee
????️
IT Asset Administrator

Owns the registry and every catalog. Gets every Safekeep permit (all 25 keys across the four categories) plus the core vendor and brand permits. If this person is a true ERPat admin, no keys are needed at all — admins bypass permission checks.

????
IT Technician

Deploys, services and recovers hardware: edits assets, runs checkout/check-in, records audits and maintenance, comments on work done. No create/delete, no import/export, no catalog tabs.

????
Auditor

Verifies physical existence and condition: reads everything, records audits, exports evidence to XLSX. Cannot change assets or the lifecycle.

????
Finance

Watches cost and book value: reads the registry, the Depreciations catalog and the Depreciation schedule report (all covered by the base asset permit — they have no keys of their own), and exports XLSX for the books.

????
Employee

Receives equipment. Needs only the base asset permit — that renders the "Assets assigned to me" widget and lets them open their asset's page to "Confirm receipt" and "Request return" (both identity-gated to the assignee). No other Safekeep keys.

⚠️
The Employee preset is not fully private. Because the whole module shares the one base permit, an Employee holding asset can browse the entire asset registry and reports — and, per the caveat above, could technically edit the Models / Status Labels / Depreciations / Custom Fields catalogs, which gate their write actions on asset alone. If that is unacceptable for your organization, keep rank-and-file staff without any Safekeep permits: they lose the widget and the self-service Confirm receipt / Request return buttons, and an asset_checkout holder records handovers on their behalf instead.

Preset → permit checkbox map

✓ = tick the key for that role; · = leave it off. The core vendor / brand permits are listed last for completeness even though they appear in the core sections of the Role editor, not under "Safekeep:".

Permission key IT Asset Administrator IT Technician Auditor Finance Employee
asset — Assets: Entries (base)
asset_create····
asset_update···
asset_delete····
asset_manage_labels····
asset_comment···
delete_asset_comment····
asset_checkout···
asset_audit··
asset_maintenance···
asset_import····
asset_export··
asset_category (base)····
asset_category_create····
asset_category_update····
asset_category_delete····
location (base)····
location_create····
location_update····
location_delete····
asset_groups (base)····
asset_groups_create····
asset_groups_update····
asset_groups_delete····
asset_groups_manage_labels····
vendor (core, shared)····
brand (core, shared)····
????
How to read the table. Depreciations, Asset Reports, Models, Status Labels, Custom Fields and Fieldsets never appear as rows because they have no keys of their own — the base asset ✓ already covers them (read and, for the catalogs, write). Give asset_comment to any role that should leave notes on assets — the Technician gets it here because service work is usually documented in comments. Adjust freely: these are starting points, not rules.

Next steps

Was this guide helpful?

Report a content problem