Custom Fields & Fieldsets

Custom Fields & Fieldsets

Custom Fields let you record data ERPat's built-in asset form doesn't have a box for — serial-adjacent details like IMEI, MAC address, OS version, or BIR property sticker number. Fields are defined once as a global catalog, bundled into Fieldsets, and a Category binds one fieldset — every asset in that category then shows those fields as an "Additional fields" section on its add/edit form.

Who can use this

Both screens are gated on the Assets module being enabled plus the single base permission asset ("Assets: Entries"). There are no separate create / update / delete permits here: anyone who can open Custom Fields or Fieldsets can also add, edit, and delete records. Plan role assignments accordingly — see Permissions & Roles.

How a custom field reaches an asset

Fields never attach to an asset directly. The chain is:

On every save the system compiles the fieldset into a cached schema on the category, so the asset form (and the mobile API) always reads an up-to-date field list. An Asset Model can also carry a fieldset reference, but it is the category's bound fieldset that drives the "Additional fields" section on the asset form.

The values a user types are stored inside the asset record's meta JSON, keyed by each field's Field Key — see Adding & Editing Assets.

Part 1 — Custom Fields (Browse tab)

The Browse tab is the global catalog of reusable field definitions. It is a searchable DataTable with a refresh button and XLS export, sorted ascending by Name. The header button — labeled simply "Custom Field" (plus-circle icon; note it's the noun, not "Add Custom Field") — opens the add modal.

List columns

The Custom Field form

Add and edit share one modal (posts to ams/custom_fields/save) with a single footer Save button. On success you'll see the toast "The record has been saved."

The 8 field types

The Options flags — which ones actually do something

Validation on the asset form

When an asset is saved, each custom field is validated against its compiled definition. The exact error messages, with %s replaced by the field's name:

Those two checks — required and numeric — are the only runtime validations. The Format / Validation rule (NUMERIC | DATE | EMAIL | URL | regex:/.../) is stored with the field but not applied when an asset is saved today.

Behind the scenes, every save or delete of a custom field immediately re-syncs the compiled schema of every category using it, so asset forms never show a stale field definition.

Part 2 — Fieldsets

A fieldset is an ordered, required-aware bundle of custom fields — think of it as the template of extra fields for one kind of asset (e.g. a "Laptops" fieldset with IMEI-style identifiers, OS version, and RAM). You reach it via the Fieldsets tab on the Custom Fields page (which loads ams/fieldsets into the tab).

List columns

The header button — labeled "Fieldset" (plus-circle icon) — opens a large modal.

The Fieldset form (with the field builder)

1. Name the fieldset

   Name is the only required field (client- and server-side). Notes is an optional textarea.

2. Build the field list

   The Custom Fields builder table has columns "Custom Field" | "Required" | (remove). Click "Add" (plus-circle) to append a row: a dropdown of every custom field shown as Name (field_key) with a "-" blank option, a per-row Required checkbox, and a red × to remove the row. Blank rows are skipped on save.

3. Order the rows

   Row order is the display order on the asset form. The help text under the table says it all: "Bind custom fields to this fieldset; row order sets the display order. Categories using this fieldset are recompiled automatically."

4. Save

   Click Save. The system replaces the fieldset's bindings with exactly the rows you submitted and immediately recompiles the cached schema of every category bound to this fieldset — the asset form picks up the change on its next open.

Attaching a fieldset to a category

Open Categories (Safekeep → Categories), edit a category, and pick the fieldset in its "Fieldset" dropdown. From then on, every asset in that category shows the fieldset's fields under the "Additional fields" heading on the add/edit asset modal, in row order, with the per-fieldset Required flags enforced.

What the compiled schema keeps per field: key, label, type, required, primary, options, help, and format. Element types are simplified for rendering — text/textarea stay text-like, number and date stay themselves, and select/checkbox/radio all render from the options list; the format rule is included only when it isn't ANY.

Deleting fields and fieldsets

There are no in-use protections on either screen — every delete is an immediate soft delete after the confirmation prompt, and it always succeeds with the toast "The record has been deleted." (The message "The record is in use, you can't delete the record!" exists in the code but is effectively never shown here.)

See also