Андрей Николаев

У вас есть как минимум 3 способа (а на самом деле еще больше):

Вариант 1: парсер

$companyId = $this->ParseValue('{'.'=Document:ID}');

Вариант 2: runtime свойство:

list($property, $companyId) = $this->getRuntimeProperty(
	\Bitrix\Bizproc\Workflow\Template\SourceType::DocumentField,
	'ID',
	$this
);

// $companyId - идентификатор сущности

Вариант 3: document service

$documentId = $this->getDocumentId();
$documentService = $this->workflow->getService('DocumentService');
$document = $documentService->getDocument($documentId);

$companyId = $document['ID'];

Как получить этот список?

REST метода на получения этой истории нет.

Единственный метод через который можно получить историю стадий это упомянутый crm.stagehistory.list

Если мы говорим про облачную версию - нельзя.

Если мы говорим про коробочную версию Битрикс24 и используя только штатные сдества, то нельзя.

Давайте начнем с простых вещей: опишем окно.
Предположим мы создали задачу и отобразили некоторое окно (может с полями для ввода). Что должно произойти если пользователь закроет свой браузер? Таким образом можно предположить что после создания задачи окно как бы и не появлялось, а тогда смысл в этом действии? А что если задача по шаблону будет поставлена через бизнес-процесс - у кого открывать окно? А если эта задача была поставлена с мобильного устройства?

Давайте предположим, что вы хотите отобразить некоторую текстовую информацию - мы не ждем ввода данных, просто оставим какое-то примечание какому-то сотруднику.
Как это можно сделать?
1. Сделать javascript код, который вызывает всплывающее окно и подключим его к сайту.
После этого вызвав функцию в консоли вы сможете получть свое окно - уже хорошее начало.

2. Затем нужно создать свое push-событие и сделать так, чтобы при выбрасывании вашего push сообщения всплывало ваше окно.
Здесь поможет статья разработчика (почти из документации): https://dev.1c-bitrix.ru/community/blogs/hazz/work...

3. Затем дело за малым - подписать на событие создания задачи, проверить из какого шаблона она создана и выкинуть событие.

А что же делать если нужны поля ввода?
Тогда придется определиться что нужно делать если полей нет.
Всего существует 2 стратегии: если поля не заполнены - не создавать задачу (стратегия А) и все равно создать задачу, но записать где-то (а возможно и когда-нибудь напомнить) (это стратегия Б).

В случае стратегии А мы не создаем задачу по шаблону руками.
Мы точно так же делаем всплывающее окно, но добавляем обработку формы. Т.е. задача создается по кастомной кнопке и только в случае если все заполнено.
Если что-то не заполнено - задачу по шаблону не создаем.
Минус конечно в том, что задача будет создаваться по кастомной кнопке, а если ее создать стандартными средствами то увы этот механизм не отработает.

В случае стратерии Б мы делаем почти то же самое, однако нам нужно еще создать промежуточное хранилище с указанием - заполнили ли по задаче Х поля и выбрасывая форму создавать запись в этом хранилище.

Это не сложно: нужно всего-лишь довести дату до формата "d.m.Y", затем пройти через explode и результат скормить итератору. Тогда по ключам вы сможете определить (0 - дата, 1 - месяц, 2 - год).

Не могу понять почему происходит удаление

Это происходит потому что процесс создания задачи не заканчивается на создании записи о задаче.

Добавление задачи из публичной части сводится к методу: `Bitrix\Tasks\Manager\Task::add`, где вначале происходит создание записи и инициирование события (строчка 139), а затем объединение чек-листов (строчка 177). Таким образом получается что изначально при создании задачи передается пустой набор чек-листов, потом вы создаете элементы чек-листов, а затем merge производит удаление существующих чек-листов, которые не были переданы в изначальном запросе, а так как их не было - просто удаляет ваши созданные чек-листы.

Как можно избежать этой ситуации?

1. Наилучшим вариантом будет попробовать использовать другое событие: before.
Т.е. не создавать элементы чек-листов, а дополнить исходный массив данных структурой, которая будет создавать чек-листы.
Попробуйте отловить прочку событий before с чек-листами чтобы понять что нужно делать

2. Удовлетворительным вариантом будет так же создание агента, который добавит чек-листы.
Однако тут будут свои тонкости, поскольку агенты могут исполняться значительно позже чем хотелось бы.

3. Так же, неплохим хаком будет являться использование background job - т.к. он выполняется в конце страницы уже после выполнения всех правок.

Обращу ваше внимание - событие является независимым от контекста, поэтому вполне может быть такая ситуация, что при создании задачи на агентах (или консольном скрипте) у вас `$USER` будет null, таким образом ваш скрипт упадет с фатальной ошибкой. Но наличие `$USER` еще не являетися поводом для радости, сам GetId может вернуть `null`, таким образом фатальная ошибка прилетит уже от контроллера прав.
Рекомендую использовать выполнить проверки и сделать fallback механим - подставить ID = 1 (или самому бросить фатальную ошибку) в случае непредвиденной ситуации

В Битрикс24 нет метода который бы прошелся по списку и вернул наборы сущностей "которые он посчитал дубликатами".
Есть метод на объединение уже известных и на изменение поиска (добавление в дубликаты своих полей).

Здесь работают 2 других механизма:
1. Автоматический поиск и объединение. Включается в настройках CRM, после чего сам проверяет актуальность.
2. Ручной поиск через `crm.duplicate.findbycomm` или `crm.*.list`.

Метод скорее выдан не для регулярного использования, а для точечного, когда например есть какие-то косвенные признаки (например приложение добавляет какой-нибудь уникальный ключ и потом в фоне по нему делает склейки).

Я умею это делать через батч, но в данном случае нужен обычный метод, как такое сделать?

В формулировке "одного стандартного метода" никак.
Вы путаете интерфейсные возможности с возможностями REST, а это не одно и то же. Собсвтенно говоря в самом битриксе это тоже не один механизм - сначала выполняются задания контроллеров (т.е. создание контакта), а потом уже основное действие (создание сделки).

Битрикс в плане api досаточно примитивная система: при создании сделки вы создаете только сделку, а при создании контакта только контакт.

Таким образом есть 2 варианта как это можно сделать:
- Через батч (создать контакт, создать сделку указав CONTACT_ID)
- Через бизнес-процессы. Т.е. создать Н доп.полей в сделке и БП запускаемый при создании, который получит поля, создаст контакт и изменит сделку

Как уже сказали в предыдущем комментарии от SHADRIN можно воспользоваться API, но есть другой путь: если у вас есть маркет, то можно использовать чат-бот Многоцелевой и telegram (телеграм) бот , который это умеет и еще много всего другого.

В курсе Bitrix Framework есть глава по работе с языковыми фразами и там есть раздел посвященный этому - "Замена фраз в продукте".

Соответственно принцип такой:
1. Сначала ищем языковую фразу. В Битриксе много однотипных фраз в разных компонентах системы, поэтому задача будет не самой простой. Для этого проще всего воспользоваться средством поиска языковых фраз из модуля Переводы (дописать к адресу страницы "show_lang_files=Y" и после обновления будет специальный дополнительный диалог поиска языковых фраз).
2. Затем через механизм user_lang изменяем нужную фразу.
3. Повторяем шаги 1 и 2 для всех фраз.

Однозначного ответа на ваш вопрос не будет.

Во-первых, непонятно что именно вы подразумеваете под "функционалом документооборта". Просто централизованное хранилище документов с простым согласованием между отделами? Или сложное типиированного согласование с использованием ЭДО? Какой именно "функционал" вам требуется? Какое представление?

Во-вторых, можно воспользоваться универсальным ответом - "Посмотрите что есть из доступного и если вас не устроит - делайте свое приложение".

Начните с простых шагов:
1. Определите что вы вкладываете в понятие документооборот. Какая цель стоит перед этой системой. Что самое важное (хранение, согласование или что-то другое)
2. Распределите все фичи по уровням важности и сравните с тем что есть в наборе Битрикс24. Обратите внимание на смарт-процессы и универсальные списки в Битрикс24.
3. Попробуйте собрать тестовую схему, потом попробуйте расширить ее.

Как только вы проделаете эти шаги, то у вас сложится представление о возможностях системы.

Готового модуля нет.
Для облачного Битрикс24 такое можно сделать только через браузерный плагин.
Для коробки можете попытаться разработать свое, но будет не просто

Технически благодарности это не просто записи инфоблока "Доска почета" в типе "Орг.структура", но и пост в ленту.

Для того чтобы получить их - достаточно обратиться к соответствующему инфоблоку, однако создать их через код намного сложнее.

Что касается таблицы, то это таблица элементов (b_iblock_element), но это не все - часть данных находятся в таблице свойств (b_iblock_element_property).

В предыдущем сообщении есть указание на `iblock_id = 2`, однако это не совсем верно. Идентификатор этого инфоблока находится в b_option (MODULE_ID: `intranet`, NAME: `iblock_honour`). В реальности там может быть и 2 и 4 и любое другое число.

Нет, не имеется.
В данном контексте понимается что вы можете создать свой набор элементов из своего источника. В данном случае этим источником может выступать что угодно, а прослойка между источником и тем что пользователи будут видеть и называется сущность.

Пользовательские поля вы можете получить через любой REST метод на получение пользователей, если у вас выбран scope "user.userfield" и если код поля начинается с UF_USR_

Например, если вы создали поле UF_MONDAY и назначили его пользователю, то получить его через REST по работе с пользователем будет нельзя*.

* - вы можете попробовать подменить класс Bitrix\Rest\Api\User или перекрыть пользовательский scope, но это очень трудоемкий процесс

Дело в том, что строка представляет из себя последовательность символов, а поля типа Список, Привязка к * это комплексные поля, которые хранят в себе идентификатор элемента.
Таким образом, вы пытаетесь записать строку в поле, которое ожидает число.

Для того чтобы ваша задумка заработала вам нужно промежуточное звено: некоторый скрипт, который примет от вас строку, поищете среди сущности элемент с таким названием и вернет его ID (либо создаст новый элемент и вернет его ID) и далее уже нужно использовать именно этот ID.
Вы можете воспользоваться как API, который предложил belc, вы так же можете составить ручной маппинг (через блоки "Условия", если список не большой).