Идеи пользователя

Раньше чтоб получить, например, список групп пользователя я мог выполнить запрос
$arUser = \Bitrix\Main\UserTable::getList([
  'select' => ['ID', 'LOGIN', 'GROUP_LIST'],
  'runtime' => [
      new \Bitrix\Main\Entity\ReferenceField(
          'GROUP_REF',
          \Bitrix\Main\UserGroupTable::getEntity(),
          [
              '=this.ID' => 'ref.USER_ID'
          ]
      ),
      new \Bitrix\Main\Entity\ExpressionField(
          'GROUP_LIST',
          'GROUP_CONCAT(DISTINCT %s SEPARATOR "[#]")',
          'GROUP_REF.GROUP_ID',
          [
              'fetch_data_modification' => function () {
                  return [
                      function ($val) {
                          if (empty($val)) {
                              return [];
                          }

                          return explode("[#]", $val);
                      }
                  ];
              }
          ]
      )
  ]
])->fetch();

и в $arUser['GROUP_LIST'] был список идентификаторов групп.
В парадигме объектов агрегирующие поля запрещены - при fetchObject бросается исключение "Result of query with aggregation could not be fetched as an object". Хотя если в файле bitrix/modules/main/lib/orm/query/result.php в методе initializeFetchObject закомментировать проверку на наличие в запросе агрегирующих полей [if (!empty($this->query->getGroupChains()))] и ExpressionField'у задать тип ArrayField, то в результате fetchObject прекрасно возвращается поле содержащее массив значений.
Идея: разрешить использование агрегирующих полей, либо доработать АПИ так, чтоб можно было получать нечто подобное без лишних запросов.

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

Добрый день!
Предложение заключается в опциональной (!) возможности отслеживать веб-хуки, которые не сработали.
Хотелось бы понимать, какие веб-хуки не "дошли" до сервера и, в следствии, не были обработаны.
Так же, хотелось бы получить возможность повторно отправлять не обработанные веб-хуки вручную, автоматически и программно

Схематично обрисую реализацию, которую я вижу:
1. Создается исходящий веб-хук, ставится галочка [ ] Отслеживать
2. После срабатывания события происходит запрос на сервер
3. ID веб-хука и запрос добавляются в некий список вебхуков
4. Сервер обратным (входящим) веб-хуком информирует о получении данных (напр. отсылает ID получившего веб-хука)
5а. Обработанный исходящий веб-хук удаляется из списка
5б. Нет ответа от сервера - оставить в списке / повторно отправить через N минут

Реализовать можно по разному, но суть остается той же - хочется понимать, что все запросы получены и обработаны.  

Сделайте приложение для интеграции с банком Тинькофф для автоматизации процесса работы со счетами. По аналогии с приложением банка Точка.
Документация по API есть у них в личном кабинете.
Спасибо!

Добрый день. Добавьте пожалуйста в API метод для создания ответственного по событию, потому что сейчас в документации его нет. Спасибо!

В методе CTicket::Set() добавить обработку возвращаемого значение от события OnBeforeTicketUpdate на false. Так же как сделано это с OnBeforeTicketAdd.

Сделать настройку, чтобы часть компонентов, для которых автоматический сброс кэша  включен, продолжал бы работать при включенном автокешировании, а для  части компонентов сделать так, чтобы они кешировались  строго на определенное время и не сбрасывались бы до его истечения ни при каких условиях.

При создании полей списка добавить тип свойства словарь (highloadblock).  

Полноэкранный режим вашей десктоп-версии Б24 "глушит" всплывание панели задач в Вин 10.
Ерунда получается. Это трудновыполнимая опция ? А если купить полную версию Б24 - там этот баг "пропадет"?