Configure actions

Actions let users mutate objects, call methods, refresh data, control a schedule, or open file workflows. The same action name can be meaningful on one surface and ignored on another, so choose the execution context before choosing the method.

Every action has a stable id, method, and localized label. Optional icon, labelToggleOn, and parent decorate or specialize particular methods.

Execution contexts

Context	Available input	Main supported families
Panel actions	panel ID and panel selection	create/update/delete, methods, HTTP, reload, schedule, file upload/current preview
Table row actions	clicked row/object selector	update/delete, select, nested events, open schedule, method, HTTP
Tree node actions	clicked node and tree hierarchy	create/delete link, method, reload
Attributes actions	one event-selected object	read/update/delete/runMethod subset
File row/preview actions	dataset/current preview	delete, edit metadata, replace, unlink
Event actions	event occurrence, source selection, variables	event-action enum plus selectObject compatibility branch
Response actions	successful runMethod plus BPMN update/delete integrations	shared processor currently handles reloadEntities and showNotification; HTTP does not execute configured response actions

Do not infer universal availability from the 32-value ItemActionMethod enum.

Complete method catalog

Object, link, and method actions

Method	Purpose	Important requirement
create	create object/link through an editor	complete editor and resolvable endpoints
update	edit selected object	selection; editor behavior depends on surface
delete	Attributes-specific deletion	selected Attributes object
deleteObject	delete selected/clicked object	object selector
deleteLink	delete relationship entity	linked selector, often idSource: "link"
runMethod	call /MetaMethods/Run	parent, method name, object endpoints
http	call custom HTTP endpoint	method and URL; optional editor or confirmation
read	Attributes/editor read mode	not handled by generic panel dispatcher
selectObject	select a row/object	Table or event context
selectRoot	choose a Tree root	Tree-compatible panel

Coordination and feedback

Method	Purpose	Context
actions	run nested actions as onButtonClick event actions	panel/Table item surface
reloadEntities	invalidate/refetch objects, tree nodes, or panels	panel, Tree, response processor
showNotification	show toast or modal feedback	response processor

Schedule actions

getSchedule, createSchedule, openSchedule, deleteSchedule, saveSchedule, generateSchedule, propagateSchedule, showUnscheduledOperations, toggleEmptyOperations, toggleSecondaryConstraints, toggleLayerOrCalendar, updateSchedule, changeLockStatus, and unscheduleOperations depend on Gantt/schedule stores. They are not general object actions. Some require an active schedule or selected operations; destructive unschedule variants open confirmation.

File actions

uploadFile resolves the panel's event-selected object. deleteFile, editDatasetMeta, replaceDatasetFile, and unlinkDataset act on the current preview or file-row dataset. Upload belongs to the panel action surface; the other four belong to existing datasets.

Schedule action parameters

Schedule action fields are meaningful only in the schedule execution context. They do not create a Gantt or selected-operation state when copied to an unrelated panel.

Field	Current consumer behavior	Required context, precedence, and limits
createSchedule.areasAggregationMetaTypeName	Selects the MetaType queried by the Area picker in the Create Schedule modal.	The panel action opens the modal for the current panel. A missing or empty value falls back to Area; it does not change any other schedule field.
openSchedule.setVisibilityVariable.*	Writes every configured key/value pair to the event-variable store before loading /Schedule/OpenSchedule, and retains the same map with the active schedule.	openSchedule first resolves the schedule GUID from the clicked row or the current panel selection. A missing GUID or missing variable map aborts the action instead of opening the schedule.
showUnscheduledOperations.drawer.position	Declared on the action type but not read by the current dispatcher.	It does not move the drawer. The Gantt adapter owns the current lower Splitter layout.
showUnscheduledOperations.drawer.header	Declared but not read by the current dispatcher.	It does not replace the Schedule Operations panel's own header/close UI.
showUnscheduledOperations.drawer.width	Declared but not read by the current dispatcher.	It does not size the drawer. Current Gantt Splitter state owns the visible share.
showUnscheduledOperations.panel	Supplies the nested scheduleOperations configuration copied into the singleton schedule store. Invoking the action toggles that panel.	This is the effective configuration payload; it takes practical precedence over the ignored drawer.* declarations and requires an active Gantt schedule to provide rows.
changeLockStatus.locked	Sends the configured Boolean with the currently selected Gantt operation GUIDs, then replaces the schedule with the returned full response.	At least one operation must be selected. With none selected, the handler warns and sends no request.
unscheduleOperations.variant	Chooses the request scope: all, allAfterTerminator, selectedAndNext, selectedAndPrevious, selectedOnly, or wholeSequence.	selectedOnly, both selected-and-direction variants, and wholeSequence require selected operations. All variants except selectedOnly are confirmed when the current destructive list marks them destructive; allAfterTerminator also uses the current chart terminator. The runtime falls back to selectedOnly if the field is absent even though the typed action requires it. A successful response replaces the schedule and clears operation selection.

Action groups

Panel actions accept either a legacy flat array or groups:

{
  "panelActions": [
    {
      "id": "order-actions",
      "label": { "en": "Order", "ru": "Заказ" },
      "renderType": "dropdown",
      "position": "right",
      "actions": [
        {
          "id": "create-order",
          "method": "create",
          "label": { "en": "Create", "ru": "Создать" },
          "icon": "plus",
          "editor": {
            "mode": "modal",
            "entityType": {
              "object": { "metaTypeName": "ProductionOrder" }
            },
            "fields": [{ "attribute": "name", "label": "Name" }]
          }
        }
      ]
    }
  ]
}

renderType defaults to inline_buttons. Supported values are inline_buttons and dropdown. position is left or right. A legacy flat array is normalized to one dropdown group.

ActionsGroup.actions[] is the list of visible action controls in that group. It is different from the action whose own method is actions: that generic action dispatches its nested actions[] as ordered onButtonClick event actions with the current panel context (and the clicked row context on Table). Use the group field to organize controls; use the nested-action method only when the intended event actions are implemented for that surface.

Run a MetaMethod

{
  "id": "release-order",
  "method": "runMethod",
  "label": { "en": "Release", "ru": "Запустить" },
  "request": {
    "parent": "ProductionOrder",
    "methodName": "release",
    "objects": [{ "getFromItem": true }]
  },
  "editor": {
    "mode": "modal",
    "fields": [
      {
        "attribute": "comment",
        "type": "Text",
        "label": "Comment"
      }
    ]
  },
  "response": {
    "actions": [
      {
        "id": "refresh-orders",
        "method": "reloadEntities",
        "label": "",
        "panels": [{ "panelId": "orders" }]
      },
      {
        "id": "released",
        "method": "showNotification",
        "label": "",
        "mode": "toast",
        "severity": "success",
        "message": {
          "en": "Order released",
          "ru": "Заказ запущен"
        }
      }
    ]
  }
}

The MetaMethod controls accepted objects, params, and any actions returned by the server. After a successful runMethod, the runtime processes both supported server-returned actions and the configured client-side runMethod.response.actions[]. The current shared processor recognizes reloadEntities and showNotification; other response methods can fall through as unhandled. BPMN update/delete integrations also pass their configured response actions to this processor. This is not generic HTTP-action behavior.

Custom HTTP action

{
  "id": "archive-order",
  "method": "http",
  "label": "Archive",
  "request": {
    "method": "POST",
    "url": "/orders/{objectGuid}/archive",
    "body": { "source": "configurator" }
  },
  "confirm": {
    "title": "Archive order?",
    "message": "The order will leave the active queue."
  }
}

The URL may contain item-field placeholders. The configured body is sent as-is; body placeholder substitution is not implemented. On success the current HTTP executor shows a success toast and invalidates the current panel queries.

When a modal editor with fields is configured, its submitted form data replaces the configured body. The editor branch runs before confirmation, so combining a modal editor and confirm does not currently show confirmation. Although response.actions[] is declared, this executor does not process it. The endpoint, payload, authorization, and response are external contracts.

Reload targets

The current reloadEntities processor implements:

• treeNodes[] from the current item or an event, with reloadSelf, reloadChildren, and/or reloadParent;
• panels[].panelId;
• a fallback reload of the current panel when no concrete panel target exists.

The declared objects[] targets are not processed. Tree-node objectId and getFromCreatedObject are TODO paths, and panels[].getPanelForEventId is skipped with a warning. Prefer an explicit panelId unless a Tree item/event reload is the exact required target.

Notification behavior

showNotification supports:

• mode: toast (default behavior in the notification processor) or modal;
• severity: success, info, warn, or error;
• localized summary and required message;
• toast life;
• modal closeLabel.

Defaults are mode: "toast", severity: "info", toast life: 5000, and a localized Close label for the modal.

Open checked-in method-response toast and modal notification journeys

Minimal valid action

This is structurally minimal but only meaningful on a surface that implements selectObject.

{
  "id": "select-row",
  "method": "selectObject",
  "label": "Select"
}

Prefer a complete method-specific example for production configuration.

Create, then refresh

{
  "id": "create-order",
  "method": "create",
  "label": "Create order",
  "editor": {
    "mode": "modal",
    "entityType": {
      "object": { "metaTypeName": "ProductionOrder" }
    },
    "fields": [
      { "attribute": "code", "type": "String", "label": "Code" },
      { "attribute": "name", "type": "String", "label": "Name" }
    ]
  }
}

The checked-in Object contract fixture demonstrates create and update against a local API and refreshes the visible object chain:

Open the create, update, linked-read, and detail journey

Defaults, precedence, and interactions

• Flat panel actions become one legacy dropdown group; explicit groups default to inline buttons.
• Toggle methods can show labelToggleOn when their schedule state is active.
• runMethod gathers selected panel objects and configured endpoint objects.
• A successful runMethod runs supported server-returned and configured response actions in order. BPMN update/delete integrations can do the same with their configured response actions.
• A successful http action does not execute configured http.response.actions[]; it shows its own success notification and invalidates only the current panel's queries.
• Destructive schedule variants and several delete/file actions require confirmation at their owning surface.
• Editors and endpoints follow the rules in editors and object endpoints.

Limits and current drift

• The action union contains a broad ItemActionBase, so TypeScript acceptance alone does not prove method-specific required fields.
• Context handlers implement different method subsets.
• Base parent is declared, while active method flows use their nested request parent. Do not use the base field as a substitute.
• showNotification and reloadEntities are the only methods in the small shared response-action processor.
• HTTP response.actions[] is declared but ignored by the current HTTP executor; its own success path invalidates the current panel.
• A modal HTTP editor takes precedence over confirm, and configured body placeholders are not expanded.
• Schedule and file actions depend on live stores and selected/current entities; copying them to an unrelated panel does not create that state.
• showUnscheduledOperations supplies a nested schedule-operations panel; that variant is not a reliable standalone application panel.
• HTTP and MetaMethod payloads remain external API contracts.

Exact property reference

Common action fields:

• Action.id
• Action.method
• Action.label
• Action.labelToggleOn
• Action.icon
• Action.parent

Method-specific fields:

• {create|update|http}.editor
• update.modal
• actions.actions[]
• createSchedule.areasAggregationMetaTypeName
• openSchedule.setVisibilityVariable.*
• showUnscheduledOperations.drawer.position
• showUnscheduledOperations.drawer.header
• showUnscheduledOperations.drawer.width
• showUnscheduledOperations.panel
• changeLockStatus.locked
• unscheduleOperations.variant

Run a MetaMethod:

• runMethod.request.parent
• runMethod.request.methodName
• runMethod.request.objects[]
• runMethod.editor
• runMethod.response.actions[]

Reload targets:

• reloadEntities.{objects[]|treeNodes[]}.objectId
• reloadEntities.{objects[]|treeNodes[]}.getFromItem
• reloadEntities.{objects[]|treeNodes[]}.getFromCreatedObject
• reloadEntities.{objects[]|treeNodes[]}.getSelectedObjectForEventId
• reloadEntities.treeNodes[].reloadSelf
• reloadEntities.treeNodes[].reloadChildren
• reloadEntities.treeNodes[].reloadParent
• reloadEntities.panels[].panelId
• reloadEntities.panels[].getPanelForEventId

Notification behavior:

• showNotification.mode
• showNotification.severity
• showNotification.summary
• showNotification.message
• showNotification.life
• showNotification.closeLabel

Custom HTTP action:

• http.request.method
• http.request.url
• http.request.body
• http.confirm.title
• http.confirm.message
• http.response.actions[]

Action groups:

• ActionsGroup.id
• ActionsGroup.label
• ActionsGroup.renderType
• ActionsGroup.actions[]
• ActionsGroup.position

Next tasks

• Build the action editor and endpoints
• Publish selection through an event
• Choose a panel variant action surface
• Follow the create, edit, and refresh journey