Display-layout groups
Remove a display-layout group
/a/LayoutGroup_deleteData
Remove selected display-layout headers and their exact child rows
When to use this endpoint
Delete obsolete display configurations. The dashboard supplies one id; native ID arrays and other mapped filters can select a set. The same locked selected header IDs now drive child cleanup, so nonmatching extra filters cannot remove unrelated child rows.
Authentication and permissions
Authenticate with signed API-key fields or a logged-in CRM session. Mutations require the client-administrator bit checked by Core_isClientAdmin (including the tenant-owner fallback), not merely access to the Display Layout Dashboard screen. The handlers also require login; create/update/delete check administrator status before their login guard, while copy checks login first.
Groups belong to the authenticated tenant. No per-group ownership, userID, department or page-role restriction is added. userID is a stored field, not an authorization boundary. No tenant feature toggle is consulted by these handlers.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
id | Scalar or request array | Or another mapped filter | IDs are integer-converted by the generic helper; native arrays use IN. No reference/dependency validation is performed. An ID combined with other filters must satisfy all supplied predicates. |
Other mapped fields | Legacy filter controls | No | The generic helper also recognizes userID, name, tableName, createdate, lastEdited, metaModalSize, meta and metaType. Scalar filters use equality and arrays use IN, combining keys with AND. There must be at least one mapped filter. This is not the substring search used by table reads. Prefer explicit IDs for deliberate selection. Metadata-path aliases are legacy filters and can cause a query error rather than behaving like JSON-key selectors. |
Example request
$result = FM_api('LayoutGroup_deleteData', ['id' => '1042']);Example response
{"ok":1}Errors and unusual responses
| Response | Condition |
|---|---|
{"error":"not logged in"} | No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs. |
{"error":"you are not admin"} | Not a client administrator; this message intentionally differs from the other group mutations. |
{"error":"Unable to complete layout group operation. Check the saved state before retrying."} | A transaction/read/write/commit failure prevents confirmed completion; inspect saved state before retrying an uncertain response. |
{"error":"missing or invalid filter"} | No mapped deletion filter supplied. |
{"error":"Could not read records for deletion. Please retry."} | Header pre-read fails. |
{"error":"Could not delete records. Please retry."} | Header deletion returns false. |
{"error":"Could not record deletion audit."} | Deletion-log write fails; the operation rolls back its header/audit changes. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- The shared helper locks the matched headers, returns their exact IDs to the wrapper, removes them and records deletion audit/history. Child cleanup uses only that returned ID set.
- Header removal, deletion audit and checked child cleanup run in one tenant transaction/savepoint. A child-write failure rolls back the selected headers and audit from this operation. The existing physical-deletion retention behavior is unchanged.
- No matching header is treated as success. No page_settings or other screen/default references are removed, and there is no automatic replacement layout selection. No child DELETE runs for an empty selected header set.
- No direct mobile-app or m-service caller for this family was found. These groups configure CRM display layouts; they are not reusable document presets, form definitions, or a tenant-wide change to existing business-object data.
Side effects
- Removes tenant layout_groups headers and separately layouts field rows; invalidates both caches. Selected header IDs receive deletes-log entries (row metadata through the API audit helper) and a Core_log delete entry. Child rows have no separate per-row deletion audit here. No notification or background cleanup is scheduled.
See it in Fieldmotion
CRM1
No production CRM1 caller for this layout-group family was found in client source. The administration workflow described here is CRM2; API tests and fixture setup are not evidence of a CRM1 screen.
CRM2
Open CRM2 Settings → Display Layout Dashboard (pageSettingsDisplayLayouts). Its create/edit/delete helpers resolve the layoutGroup map to the corresponding LayoutGroup route; filter browser developer tools for that exact function name. Screen visibility is not a substitute for the API administrator check. Use a card’s Delete action: the caller sends one id. Page/default selections may still point at the removed group; the handler does not repair them.
Related endpoints
- LayoutGroups_getList discovers IDs and metadata for layout selectors.
- LayoutGroup_createData creates a header only; LayoutGroup_copy also copies the existing field tree.
- LayoutGroup_updateData changes several header fields; LayoutGroup_updateField changes one mapped field across IDs.
- LayoutGroup_deleteData removes a group and performs separate field-row cleanup.