Field Management¶
Under Administration > Fields (/v2/admin/fields), the dynamic field configuration is managed. Fields determine which data fields are displayed in forms and lists.
Concept¶
calServer uses a dynamic field system with metrology codes:
| Table | Field Prefix | Examples |
|---|---|---|
| Inventory | I42xx | I4201 (Asset Number), I4202 (Manufacturer), I4203 (Model), I4206 (Serial Number) |
| Calibration | C23xx | C2301 (Calibration Date), C2303 (Next Calibration), C2323 (Result) |
| Customers | K46xx | K4601 (Customer Number), K4602 (Name), K4603 (Street) |
Each code is mapped to an API name through the field registry (field_definitions) (e.g. I4201 → asset_number); the V1 code remains a valid field identifier alongside it (see V1 field names).
Field Configuration¶
The following properties can be configured for each field:
| Property | Description |
|---|---|
| Visible | Whether the field is displayed in forms and lists |
| Required | Whether the field must be filled in |
| Read-only | Whether the field is read-only |
| Default Value | Pre-filled value for new records |
| Order | Position in the form |
| API Name | Descriptive name for the REST API |
| Change protection | Warning or prohibition when the value is changed (see below) |
| Message text | Wording of the warning or prohibition |
Field Name and Translations¶
As in V1, a field's name comes from the translation management as soon as a
translation string exists for it (category fields, key
{table}.{api_name}, e.g. inventory.serial_number). All factory fields have
one from delivery. The label is then locked in field management and marked with
a language icon; the link "In der Sprachverwaltung ändern" opens the
translation editor on that key, where the name is maintained per language.
Custom fields without a translation string keep their label from field management until somebody translates them.
Change Protection¶
Some fields should not be changed in passing — an asset number appears on certificates and labels, and a contractually fixed value must not move at all. Three levels are available per field:
| Level | Effect |
|---|---|
| No protection | The field behaves like any other (default) |
| Warning | The mask asks before applying the change. "Cancel" restores the original value; after confirmation the record saves normally |
| Prohibition | The field is locked in the mask, and the server rejects a change with an error — over the REST API and during Excel import as well |
The message text is free-form. If left empty, a default wording is used. Three placeholders are available:
| Placeholder | Replaced by |
|---|---|
{field} |
The field's label |
{old} |
Previous value |
{new} |
New value |
What the protection does not prevent
Both levels concern changing an existing value. Creating a record and filling a so-far empty field for the first time stays possible — otherwise migrated records could never be completed.
MET/TEAM sync exception
The MET/TEAM pull mirrors the state of the foreign system and therefore bypasses the prohibition. Without that exception the sync would stall permanently on a field changed in MET/TEAM and locked in calServer.
Protected out of the box: the asset number (I4201) is set to warning. It is the identifier certificates, labels and connected systems use to find the device. Set the field to no protection in field management if you do not want this.
Changing the Order¶
Form order and grid order are stored separately:
- Form order (
display_order) — position in the create, edit and detail form. Changed right in the field list of the area tab: drag a row by the handle on the left, or use the arrows in the row. Every move is saved immediately and assigns sequential positions (1..N). - Grid order (
display_order_grid) — default column order in tables. Use Reihenfolge anpassen in the tab toolbar and switch to "Grid-Reihenfolge".
List sorting
Reordering requires the field list to be sorted ascending by the Order column — only then does the displayed sequence match the form order. Under any other sort the handle and arrows are disabled.
Additional Fields¶
Through Additional Fields, field configurations can be overridden per category or status:
- A field can be visible for Category A but hidden for Category B
- Required status can vary depending on the status
- This enables flexible forms without code changes
Export/Import¶
Field configurations can be exported and imported:
- Export — Saves the current configuration as JSON
- Import — Applies a saved configuration
Field changes
Changes to the field configuration take effect immediately for all users. Test changes with a test user first.