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

Насколько мне известно единой функции для вычисления рабочих дней нет.

Как сделать чтобы почта проверялась не зависимо от того есть сотрудник на портале или нет?

Синхронизация почты работает в двух вариантах - на агенте (Bitrix\Mail\Helper::syncMailboxAgent(***);) и на таймере (напрямую через \Bitrix\Mail\Helper\Mailbox\MailboxSyncManager).

В агенты штатно вынесен только syncMailboxAgent (с периодом в 1 сутки), но он имеет ограничения на запуск поэтому при большом количестве почтовых ящиков и длительных ответах начинаются тормоза.

Никакой инструкции нет, поэтому сначала можно попробовать уменьшить период запуска (скажем каждые несколько часов).

Проблема что товары интегрируются не со всеми параметрами, нету вкладки свойвст товаров.

Обратитесь к разработчикам приложения

Если мы имеете ввиду выкинуть ошибку на событии перед изменением (before), то для этого нужно сделать 2 действия:

1. В событие по ссылке передается набор изменяемых полей (&$arFields обычно называется).
Нужно записать ему в ключ `RESULT_MESSAGE` строковое сообщение.

2. Нужно дополнительно выбросить битриксовы экспешен:

global $APPLICATION;
$APPLICATION->ThrowException("Error text here");

3. Вернуть в обработчике `false`.

Таким образом на эране будет отображена строковая ошибка.

Для возврата чего-то более интересного придется задействовать технологию push'n'pull, но это уже совсем другая история.

Есть ли быстрый способ решить эту проблему?

Чтобы был "быстрый" способ, нужно хотя бы иметь "2 способа" решения, а вы даже проблему (т.е. собственно почему происходит деактивация) не локализовали.

Как посмотреть пользователей которые пришли во время обмена с AD?

Таких логов не ведется, но можно подписаться на событие OnLdapUserFields модуля ldap и посмотреть какие приходят данные во время обмена.

Как записать в лог всех пользователей которые есть в xml с 1с?

Если мы говорим про штатный импорт, то файл последнего импорта находится в `/upload/1c_intranet/`
Судя по тому что вы привели код - у вас кастомный импорт и здесь вам нужно обратиться к разработчикам.

Что касается вашей проблемы, я кажется знаю ее корень: изменение пользователей из 1С.
В механизме сихнронизации битрикса происходит оперирование тремя датами:
- Дата последней синхронизации в Битрикс24
- Дата последнего изменения сотрудника в Битрикс24
- Дата последнего изменения учетки в AD

Синхронизация происходит при трех ключевых условиях:
1. LDAP Query вернул учетку.
2. Изменение учетке в AD (либо в Б24) произошли ПОСЛЕ последней успешной синхронизации.
3. Учетка не должна входить в "неимпортируемые группы"

Соответственно типовые ошибки:
1. Рассинхрон времени (например по какой-то причине время на сервере Б24 бежит впереди времени AD).
2. Шаманство с датами (иногда учетки отключают задним числом)
3. Неправильные условия (ldap query с активностью)
4. После увольнению учетку добавляют в группу, которая в Б24 помечена как несинхронизируемая

Скорее всего не реализована подобная интерактивность на стороне страницы "Мой план".
По факту "Мой план" - это исключительно ваши стадии и ваши индивидуальные настройки.

Попробуйте написать в техническую поддержку с вашим кейсом.

Штатно такой возможности нет.

Самый простой способ это реализовать:
- Создает свое pull-событие (См. документацию: https://dev.1c-bitrix.ru/community/blogs/hazz/work...)
- Подписаться на событие создание сделки (см. документацию: https://dev.1c-bitrix.ru/learning/course/index.php...)
- Поставить ловушку на страницу канбака (см пункт 1)
- Обновить канбан ( код обновления канбана: window.Kanban.reload() )

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

и т.п.

Запрос идёт сразу в на URL вашего обработчика

Нет, не сразу.
Формируется специальное сообщение и отправляется на oauth.bitrix.info, там оно попадает в очередь и один из воркеров отправляет его на адрес вебхука.

Таким образом: если у вас закрытый контур или не оплачена лицензия исходящие вебхуки не работают.

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

Но насколько я знаю можно попробовать выполнить код в php-консоли (в админке)

CBXFeatures::ModifyFeaturesSettings([], ["Workgroups" => true]);

Как в битриксе придумать псевдослучайный порядок вывод элементов?

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

1. Вы можете использовать `rand` ключ сортировки из `CIblockElement::GetList` - это позволит выбирать псевдослучайные записи в количестве которые вы укажие в navParams.
В случае такой задачи это будет наиболее правильное решение.

2. Если такой вариант не подходит, то можете сделать многоуровневое кеширование.
Т.е. отдельный кеш идентификаторов элементов и (можете, но не обязательно) отдельный кеш под каждый элемент.
Соответственно получаете все ID (запросом или из кеша), перемешиваете и делаете ЛИБО получение через GetList скармливая в order порядок элементов либо обращение к своему методу и забор кеша (то самое многоуровневое кеширование).

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

2. В данном случае эффективнее кешировать не конкретные элементы, а вывод всей страницы. Т.е. делаете запросы, рендерите вывод и его кешируете. Следюущий запрос просто достанет кеш. В противном случае мало того что придется доставать кеширование данные, так вам еще придется тратить ресурсы на их рендер (а в большинстве случаев он будет одинаковый).

Еще увидел у вас в комментариях ваше предложение:

в result_modifier.php передать данные в component_epilog.php, получить ITEMS в component_epilog.php, рандомно сортировать этот массив, перенести содержимое template.php в component_epilog.php и выводить. Данные будут браться из кэша и при этом каждый раз сортироваться. Норм?))

Оно бессмысленное потому что передавать данные можно только в одном порядке: component -> result_modifier -> template -> component_epilog.
Т.е. дойдя до component_epilog вернуть в сам template (если только это не отложенная функция, но в таком случае профита нет никакого).