szdl-utils-kit 0.3.24 → 0.3.28

package/Readme.md

@@ -97,11 +97,9 @@ const deals = await bx.batch({
 -   `appOption(key, value?)` – чтение/запись пользовательских настроек
 -   `call({ method, params, updateList })` – одиночный REST-вызов
 -   `batch(commandList, progressCall?, options?)` – пакетные вызовы с обновлениями/логом
--   `errorCall(errors)` – вызывается после выполнения всего батча, получает объект с ключами запросов и списком ошибок Bitrix24
--   `updateList` – массив описаний изменений для логера (`method`, `name`, `list[{ id, fields }]`), отображается в истории операций
+    -   `errorCall(errors)` – вызывается после выполнения всего батча, получает объект с ключами запросов и списком ошибок Bitrix24
+    -   `updateList` – массив описаний изменений для логера (`method`, `name`, `list[{ id, fields }]`), отображается в истории операций
 -   `batchTotalCount(commandList, progressCall?, options?)` – подсчет элементов в пакетном режиме
--   `errorCall(errors)` – вызывается после выполнения всего батча, получает объект с ключами запросов и списком ошибок Bitrix24
--   `updateList` – массив описаний изменений для логера (`method`, `name`, `list[{ id, fields }]`), отображается в истории операций
 -   `timeLimit` – глобальный статус лимита выполнения (`{ limit, date }`), можно напрямую читать в компонентах (например, в лоадере)
 -   `placementBind(place, userId?)`, `placementUnBind(...)`, `placementCheck()` – работа с встройками (кроме `PAGE_BACKGROUND_WORKER`, их ведёт `BackgroundWorker`)
 -   `getBotList()`, `regBot()`, `unRegBot()` – управление чат-ботом
@@ -187,9 +185,10 @@ await worker.init();
 -   `bx` – инициализированный экземпляр `BxBoot`, используемый для работы с REST;
 -   `appFunc` – функция, которая должна выполниться в «активном» табе;
 -   `users` – подготовленные данные (если не переданы, будут запрошены через REST);
--   `continueBackground` – опциональная функция-условие (`(worker) => boolean | Promise<boolean)`), которая определяет, можно ли запускать воркер. Должна вернуть `true`, чтобы продолжить цикл. По умолчанию всегда возвращает `true`;
+-   `continueBackground` – опциональная функция-условие, которая определяет, можно ли запускать воркер. Должна вернуть `true`, чтобы продолжить цикл. По умолчанию всегда возвращает `true`; см. пример ниже.
 -   `timing` – объект с таймингами poll-цикла, подтверждения лидерства и разнесённого старта приложений (см. [Тайминги](#тайминги-timing)). Можно передать только нужные поля — остальные возьмутся из `DEFAULT_BACKGROUND_WORKER_TIMING`;
 -   `coordinationScope` – область координации лидера и пула вкладок (см. [Область координации](#область-координации-coordinationscope)). По умолчанию `'user'`.
+-   `bindGeneralPlacement` – привязывать общую встройку `PAGE_BACKGROUND_WORKER` без `USER_ID`. По умолчанию `true`. При `false` — только персональные встройки для админов (до 10); существующая общая отвязывается. Сочетается с `coordinationScope: 'portal'` (один лидер на портал + персональные встройки у админов для перепривязки).
 
 ```ts
 const worker = new BackgroundWorker({
@@ -222,7 +221,8 @@ const worker = new BackgroundWorker({
 - В режиме `'user'` записи в entity хранятся с `NAME = userId`, Web Lock тоже per-user.
 - В режиме `'portal'` все вкладки пишутся с общим ключом `NAME = {appCodeName}:portal`, Web Lock — per-portal (per-app).
 - В данных вкладки всегда сохраняется `userId` — в portal-режиме видно, у кого открыта вкладка, хотя `appFunc` выполняется только у лидера.
-- `setBackgroundWorkerAll` в portal-режиме привязывает только общую встройку `PAGE_BACKGROUND_WORKER` и отвязывает персональные (`USER_ID=…`).
+- Персональные встройки (`USER_ID=…`) для админов создаются в обоих режимах — это «крючки» для перепривязки и фоновых вкладок у админов. В `'portal'` они не конкурируют за отдельные задачи: все вкладки (и общая, и персональные) участвуют в **одном** пуле лидерства на портал.
+- При `bindGeneralPlacement: false` общая встройка не нужна даже в `'portal'` — достаточно персональных у админов.
 
 ```ts
 const worker = new BackgroundWorker({