Рейтинг: 3  
Новая
Предложил Малюгин Виктор 22.01.2019 18:45:26

Агрегирующие поля в объектах

Раньше чтоб получить, например, список групп пользователя я мог выполнить запрос
$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 прекрасно возвращается поле содержащее массив значений.
Идея: разрешить использование агрегирующих полей, либо доработать АПИ так, чтоб можно было получать нечто подобное без лишних запросов.
Рейтинг: 7.7074  
Новая
Предложил serginhold 04.09.2017 22:41:05

DataManager::getList разделить на два метода для возможности нормального наследования и расширения

В связи с тем что внутри метода getList создается новый Query и в итоге возвращается готовый sql запрос, есть невероятная проблема расширения параметров при наследовании DataManager.

Мне вот для sphinx потребовался новый параметр 'match', и чтобы мне туда его засунуть, мне нужно полностью переписать метод getList, т.е. скопипастить все что есть в исходниках этого метода и где-то в серединку добавить 'match'. А должно быть как-то так:

public static function getList(array $parameters = [])
{
    $query = parent::getList($parameters);

    if (isset($parameters['match']))
    {
        $query->setMatch($parameters['match']);
    }

    return $query;
}


С учетом того что эта функция должна возвращать Result, а не Query, нужно добавить внутри хотя бы один метод, вместо кучи кода обработки параметров, т.е. сделать хотя бы так:

public static function getList(array $parameters = [])
{
     return static::buildQuery($parameters)->exec();
}

public/*protected?*/ static function buildQuery(array $parameters = [])
{
    $query = static::query();
    // тут текущий код
    return $query;
}


Тогда в метод buildQuery можно будет без проблем добавить любой новый параметр.

А в данный момент нужно именно копипастить код, да и еще в 17 версии появился ключ 'cache', и вот допустим у меня старая версия ядра, и если мне нужен этот ключ 'cache' в моем DataManager для sphinx, уже после обновления, то мне надо опять скопипастить новые исходники.
Рейтинг: 6.3456  
Новая
Предложил Жиряков Дмитрий 11.05.2017 14:10:22

Добавлять NOT NULL только к полям с атрибутом "required"=true

Вся соль в том, что сейчас в методе compileDbTableStructureDump() ORM-сущностей "хардкодом" прописано добавление атрибута NOT NULL всем создаваемым полям.
Рейтинг: 0.2587  
На голосовании
Предложил Рубцов Дмитрий 19.03.2017 14:56:15

Флаг разрешения оплаты

Здравствуйте! То что появилось проверка заказа перед возможностью оплаты - очень здорово, но не хватает именно флага разрешения оплаты, помимо зависимости от статуса.

Бывает ситуация, когда заказ возвращается в более ранний статус чем тот что разрешает оплату, но после первой оплаты, возможность платить должна быть всегда.
Рейтинг: 0.4817  
Новая
Предложил Ульянов Владимир 12.02.2017 06:55:20

Партийный учет

Таблица b_catalog_store_product судя по описанию дает возможность учитывать несколько количеств одного товара на складе.

Добавьте пожалуйста возможность добавления к ней пользовательских полей.
Рейтинг: 1.7824  
Новая
Предложил Жиряков Дмитрий 07.02.2017 11:02:02

Аналог CIBlockParameters::AddPagerSettings() для D7

Необходим аналог метода CIBlockParameters::AddPagerSettings() для компонентов, в которых основная выборка идет с помощью ORM. Сейчас чтобы добавить в настройки компонента параметры для новой "постранички" приходится писать свой вспомогательный метод.
Рейтинг: 16.5172  
Новая
Предложил Николаев Андрей 09.01.2017 11:41:05

D7 ORM - ON DELETE CASCADE

Идея, которую хотелось бы тут изложить, не нова, но руки никак до нее не доходили.
Навеяна она сообщением на форуме: http://dev.1c-bitrix.ru/community/forums/forum6/topic92353/

В sql есть "каскадные операции" - удаление связанных записей или обновлние.
И хотя сейчас я слабо представляю каскадное обновление, но вот каскадное удаление или запрет на изменение/удаление уже отчетливо видно.
Прошу рассмотреть возможность реализации данной функциональности.
Рейтинг: 123.7305  
Новая
Предложил Николаев Андрей 08.11.2016 10:52:04

Расширение папки local на js

Для коробочной версии Битрикс24 жизненно необходимо иметь возможность изменять стандартные js (например в всплывающие карточки звонка добавить новое поле или вывести доп.информацию), однако все "зашивается" на папку /bitrix/js/, а так как не предусмотрен штатный механизм для расширения js, то может стоит добавить папку /local/js/ для приоритетного замещения /bitrix/js/

Например при подключении core.js (/bitrix/js/main/core/core.js) проверялось бы наличие файла /local/js/main/core/core.js и в случае его существования подключался именно он.

Может для редакции БУС это не так актуально как для КП, но в КП это просто необходимость для кастомизации crm (да и например BX.ShowWait() можно кастомизировать)
Рейтинг: 5.5324  
Новая
Предложил Николаев Андрей 09.10.2016 15:03:34

Развитие api для разделов инфоблоков

В версии инфоблоков 16.5.4 вышла прекрасная функциональность для работы с разделами на новом ядре D7.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:

1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;

Loader::IncludeModule('iblock');
$sSection = SectionFactory::compileEntityByIblock(1);
$oEntity = new $sSection;
var_dump($oEntity->getMap());

Против
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;

Loader::IncludeModule('iblock');
$oEntity = SectionFactory::compileEntityByIblock(1);
var_dump($oEntity->getMap());

Мне кажется решение под номером 2 выглядит практичнее.

2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.

Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
Рейтинг: 0  
Новая
Предложил Белоконь Дмитрий 07.09.2016 11:12:19

Дать возможность подключать эпилог компонента самостоятельно

Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=3053), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.  
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.  
Рейтинг: 1.4529  
Новая
Предложил Корепанов Денис 03.08.2016 19:21:00

Несколько предложений по d7.

Есть несколько предложений по d7. Возможно такие предложения уже звучали или даже уже в процессе внедрения,  но мне не удалось их найти.

1. Добавить метод update с поддержкой фильтра. Пример:
$connection->update($tableName, $data, $filter);
2. Добавить метод delete с поддержкой фильтра.
3. Добавить метод batchInsert. Позволит добавлять одним запросом несколько записей. Пример:

$connection->batchInsert(
   'book', 
   ['NAME', 'DESC'], 
   [
      ["Запись 1", "Текст"],
      ["Запись 2", "Еще текст"],
   ]
);