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

возможно ли редактировать, модифицировать сайт путем изменения программного кода сайта

Нет.
Но при разработке собственных блоков вы имеете полный доступ к файлам вашего блока.

возможно ли получить доступ к панели администратора

Нет

1. Сделайте файл с css, который будет скрывать `span[data-bx-id="task-edit-toggler"][data-target="accomplice"]`
Рекомендую сделать через Extension: https://dev.1c-bitrix.ru/learning/course/index.php...

2. На события onEpilog добавьте свой css-файл (или extension) в код страницы.
Подробнее про события: https://dev.1c-bitrix.ru/learning/course/index.php...

Вы неправильно используете параметры ajax метода - все что вы отправляете через ajax должно быть в `data` ключе.

Т.е. ваш код должен быть таким:

$.ajax({
	url: apiUrl,
	method: 'POST',
	data: {
		fields: fields
		params: {
			REGISTER_SONET_EVENT: "Y",
		}
	},
	success: function(response) {
	    console.log('Lead created successfully');
	},
	error: function(error) {
	    console.error('Error creating lead:', error);
	}
});

Ну и соотстветно:
1. Ключи в fields лучше передавать как в Битрикс24 - в верхнем регистре
2. Смотрите корректные названия для UTM меток в документации

Чтобы посчитать количество символов в строке используйте функцию бизнес-процессов "strlen".
Подробнее об этом указано в документации.

Т.е. приводим к строке и используем strlen

Таких настроек нет.

У вас есть как минимум 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)
- Через бизнес-процессы. Т.е. создать Н доп.полей в сделке и БП запускаемый при создании, который получит поля, создаст контакт и изменит сделку