apps/panel 0.81.1

English · Русский

Released on 15 September 2026. Previous release: 0.81.0.

What changed

List and operation screens

• The list screen of the operator terminal shows search, filters, operation cards and the command rail. The operation header and the sectioned footer appear only when the operator opens an operation, and Back to list removes them again. Previously the header appeared as soon as a card was selected, and the footer stayed on the list screen, showing dashes until a card was selected.
• Exit is shown only on the list screen, with or without a selected card, and, as before, next to configuration errors. On the operation screen the command rail shows Back to list in its place. Previously both buttons were always visible, and Back to list stayed disabled until a card was selected.
• Cards take less vertical space.
• In a wide footer, the production counts take only the width they need, and the operation details get the rest of the row.
• The Operation tasks heading above the task list has been removed. A normally running timer no longer shows the Remaining time caption under its ring; screen readers still announce the value as remaining time. The paused, warning and overdue captions remain.

Card subtitle

• The new optional terminalConfig.cardSubtitle setting adds one muted line under the card title, before the field rows. It has the same structure as cardTitle: ordered parts with text, attribute or context, and an optional color, without label or colSpan. Text longer than one line is cut with an ellipsis, and the full value appears in a tooltip, as for other cut card text. Without the setting, cards have no subtitle line.
• The configuration check applies the cardTitle rules to cardSubtitle before the terminal reads operations. An invalid value is listed with its path, for example panel.terminalConfig.cardSubtitle.parts, and no operations are read. As in the title, { "context": "materialInstance" } always shows — on cards.

Reading operations from the configured source

• With metaTypeName, the terminal requests 20 objects with POST /Object/find when the panel opens and on every page change, and takes the number of matching objects from pagination.totalRecordCount in the response. The Operations count, the Page indicator and Next therefore cover all matching objects. Previously the terminal counted only the objects of the current page: it showed Page 1 / 1, Next stayed disabled, and objects after the first 20 could not be opened.
• If that response has no numeric pagination.totalRecordCount, the terminal shows the read error Terminal list request requires a total record count instead of guessing the page count. A retry succeeds only after the API returns the total.
• With customRequest, the terminal builds display attributes from each original response row. It uses the row's fAttributes array when there is one; otherwise every field of the row becomes an attribute, including fields named objectGuid, type, linkedObject, fAttributes and attributesMap. Previously a row without its own type or objectGuid field showed the panel's internal values customObject and custom-<n> for these attributes, a row with a linkedObject field stopped the read, and a field named attributesMap could make the card show wrong values or dashes.
• Each row of a customRequest response still needs a unique identifier in the field named by customRequest.idField, id by default. The terminal now checks the whole response array: if two rows share an identifier, even on different pages, it stops the read with the error Custom terminal rows require unique identifiers. Correct the source data before retrying. Previously such rows were accepted, and opening one of them could open the other.

Failed reads, paging and forms

• The page number changes only after the new page has been read. Previously a failed read already showed the new page number while the cards of the previous page stayed on screen.
• Refresh state in the error message and Refresh in the command rail repeat the read that failed. After a failed attempt to select or open an operation, they read that operation again and, if it was being opened, reopen it. Previously they read the operation list again and returned to it.
• Cancel closes a command form and discards its draft without requesting the instruction again. Previously, in the demonstration, it could also start a new instruction read.
• If the focused button disappears when the terminal switches between the list and an operation or opens or closes a form, keyboard focus moves to the terminal's work area. Previously it fell back to the page itself.

Planned start

• The Planned start value on cards uses the panel's shared date parser. Values in the DD.MM.YYYY HH:mm:ss format are read as day, month and year; previously such a value could appear as a dash or with the day and month swapped. Values with Z or an offset are shown in the device's time zone, and values without a time zone keep their calendar date and time.

Demonstration

• Every demonstration operation shows the same sample engineering drawing (JPEG) as its document instead of the generated PNG sheet. The drawing is not production documentation.
• Card titles show only the operation name. The demonstration configuration puts the operation code into cardSubtitle, so the first card shows ОП-001 under Сборка корпуса; the footer still shows the code.
• ОП-002 has a long name, order, workplace and material. Its card shows how long values are cut, and its operation screen shows how they wrap.
• When NUXT_PUBLIC_API_PREFIX ends in /local-api, for example /base/local-api, the demonstration terminal runs in training mode and sends operation reads, instruction reads and commands under that prefix. A trailing slash is ignored. The deployment must serve the demonstration API at that path. Previously training mode required exactly /local-api, and with any other prefix the demonstration terminal opened read-only.

Configuration

cardSubtitle is optional, and existing configurations need no change. To show the operation code under the card title, add terminalConfig.cardSubtitle to the terminal panel. In this example, operations-read is an example panel ID, and code is the operation-code attribute path from the guide's WorkOrderOperation example; use the attribute names of the WorkOrderOperation contract in your environment. List the attribute in attributeList so that the terminal requests it:

{
  "version": "1.0.0",
  "panel": {
    "id": "operations-read",
    "type": "operatorTerminal",
    "request": {
      "metaTypeName": "WorkOrderOperation",
      "attributeList": ["name", "code"]
    },
    "terminalConfig": {
      "cardSubtitle": {
        "parts": [{ "attribute": "code" }]
      }
    }
  }
}

Settings omitted from terminalConfig keep their built-in values, so the title still shows name. The built-in card rows read workOrder, selectedWorkUnit.name and materialDefinition; add them to attributeList as well, or those rows show dashes. The card subtitle section of the guide describes color and the check rules.

Known limitations

• The start-time plate on a card still reads values without a time zone with the browser's own date parser. For a DD.MM.YYYY HH:mm:ss value it can show a dash or count down to a different date than Planned start. The demonstration returns dates with an explicit time zone and is not affected.
• A configured WorkOrderOperation source remains read-only: documents, tasks, commands and the timer work only in the demonstration, and the terminal is not connected to SignalR.

Updated documentation

• The operator terminal guide describes the separate list and operation screens, where Exit and Back to list appear, and how paging, Refresh state and Cancel behave after a failed read.
• The operation source section states the pagination-total requirement for metaTypeName and the attribute and identifier rules for customRequest. The display parts section explains that a plain nested JSON value in a custom row shows a dash and gives the fAttributes format that the terminal can read.
• The card subtitle section describes the new setting and the demonstration's title and subtitle. The footer and countdown section covers planned-start dates and the timer caption, and the minimal demo configuration lists the API prefixes that enable training mode.