Идеи пользователя
Нашел баг в коде модуля блога, который приводит к вылету.
Проблема в том, что при удалении пользователя, который оставлял комментарий, список комментриев не загружается, так как процес попадает в бесконечную рекурсию.
В файле /bitrix/modules/blog/lib/bloguser.php ксть функция addNotExistingUsers , так вот если в неё приходит хоть один ИД удаленного пользователя (не с таблицы блога с именно с b_users) то она попадает в бесконечный цикл добавления несуществующего пользователя в таблицу блога, который не добавится, так как он не выбирается с таблицы пользователей. Я добавил пару строк чтобы обойти эту проблему но, полагаю, что нужно доделать анонимного пользователя, который приймет на себя роль коментатора, чтобы не было пустых значений имени.
Проблема в том, что при удалении пользователя, который оставлял комментарий, список комментриев не загружается, так как процес попадает в бесконечную рекурсию.
В файле /bitrix/modules/blog/lib/bloguser.php ксть функция addNotExistingUsers , так вот если в неё приходит хоть один ИД удаленного пользователя (не с таблицы блога с именно с b_users) то она попадает в бесконечный цикл добавления несуществующего пользователя в таблицу блога, который не добавится, так как он не выбирается с таблицы пользователей. Я добавил пару строк чтобы обойти эту проблему но, полагаю, что нужно доделать анонимного пользователя, который приймет на себя роль коментатора, чтобы не было пустых значений имени.
Экспорт, импорт сущностей смарт-процессов
Для основных сущностей (контакт, компания и т.п.) CRM наблюдаем следующую картину (на примере контакта показываю):
- Есть метод crm.*.fields который возвращает описания полей
- Есть метод crm.*.userfield.list который возвращает описание пользовательских полей.
В ответ на crm.*.fields для UF_* полей возвращается описание:
В нем вы видим важные параметры:
В нем мы НЕ видим:
В ответ на crm.*.userfield.list возвращается описание:
В нем мы видим важные параметры:
В нем мы НЕ видим:
Имя 2 запроса можно предположить что настройки для пользовательских полей возвращаются отдельно, однако: если обратиться к полю с типом enumeration, то в fields-запросе вернется:
Т.е. дополнительный ключ items, который показывает что можно выбрать.
Суть предложения: провести унификацию методов, чтобы crm.*.fields возвращает достаточную информацию для отображения поля.
Возвращать дополнительный ключ parameters внутри которого возвращать данные из ID поля, SETTINGS (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
- Есть метод crm.*.fields который возвращает описания полей
- Есть метод crm.*.userfield.list который возвращает описание пользовательских полей.
В ответ на crm.*.fields для UF_* полей возвращается описание:
{
"UF_CRM_1603091288": {
"type": "crm",
"isRequired": false,
"isReadOnly": false,
"isImmutable": false,
"isMultiple": false,
"isDynamic": true,
"title": "UF_CRM_1603091288",
"listLabel": "Привяка к компаниям",
"formLabel": "Привяка к компаниям",
"filterLabel": "Привяка к компаниям"
}
} |
В нем вы видим важные параметры:
- Технические характеристики (обязательность, множественность, динамичность и т.п.)
- Его тип (привязка к CRM)
- Отображаемые названия
В нем мы НЕ видим:
- Параметров, которые необходимы для показа значения
В ответ на crm.*.userfield.list возвращается описание:
{
"5": {
"ID": "114",
"ENTITY_ID": "CRM_CONTACT",
"FIELD_NAME": "UF_CRM_1603091288",
"USER_TYPE_ID": "crm",
"XML_ID": null,
"SORT": "100",
"MULTIPLE": "N",
"MANDATORY": "N",
"SHOW_FILTER": "I",
"SHOW_IN_LIST": "N",
"EDIT_IN_LIST": "Y",
"IS_SEARCHABLE": "N",
"SETTINGS": {
"LEAD": "N",
"CONTACT": "N",
"COMPANY": "Y",
"DEAL": "N",
"ORDER": "N"
}
}
} |
В нем мы видим важные параметры:
- Технические характеристики (обязательность, множественность, динамичность и т.п.)
- Его тип (привязка к CRM)
- Настройки (SETTINGS)
В нем мы НЕ видим:
- Отображаемых названий
Имя 2 запроса можно предположить что настройки для пользовательских полей возвращаются отдельно, однако: если обратиться к полю с типом enumeration, то в fields-запросе вернется:
{
"UF_CRM_1603091201384": {
"type": "enumeration",
"isRequired": false,
"isReadOnly": false,
"isImmutable": false,
"isMultiple": false,
"isDynamic": true,
"items": [
{
"ID": "26",
"VALUE": "Значение 1"
},
{
"ID": "27",
"VALUE": "Значение 2"
}
],
"title": "UF_CRM_1603091201384",
"listLabel": "Список из двух значений",
"formLabel": "Список из двух значений",
"filterLabel": "Список из двух значений"
}
} |
Т.е. дополнительный ключ items, который показывает что можно выбрать.
Суть предложения: провести унификацию методов, чтобы crm.*.fields возвращает достаточную информацию для отображения поля.
Возвращать дополнительный ключ parameters внутри которого возвращать данные из ID поля, SETTINGS (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
Ответил 
Антон Горбылев 14.09.2021 12:09:12
Антон Горбылев 14.09.2021 12:09:12
Выйдет в районе crm 21.1100.0
Предлагаю расширить список действий, которые можно совершать с свойствами в списке свойств. Сейчас доступно только 2 опции - активировать и деактивировать:
Было бы очень здорово добавить сюда:
1. Массовое проставление галочки (показывать в списке)
2. Массовое проставление галочки (показывать в детальном просмотре)
3. Привязать свойство к разделу (выбор раздела) - ОЧЕНЬ нужная вещь. Особенно когда свойств под 800-900 штук и чтобы привязать свойство к разделу, нужно в огромном списке без поиска его найти.
4. Галочка "Показывать на странице редактирования элемента"
Было бы очень здорово добавить сюда:
1. Массовое проставление галочки (показывать в списке)
2. Массовое проставление галочки (показывать в детальном просмотре)
3. Привязать свойство к разделу (выбор раздела) - ОЧЕНЬ нужная вещь. Особенно когда свойств под 800-900 штук и чтобы привязать свойство к разделу, нужно в огромном списке без поиска его найти.
4. Галочка "Показывать на странице редактирования элемента"
В штатном активити "Создать документ CRM" нет возможности выбрать нашу компанию, реквизиты которой будут в документ подставлены по шаблону.
Неудобно
Неудобно
Ответил
Антон Горбылев 19.05.2020 13:52:49
Антон Горбылев 19.05.2020 13:52:49
Выйдет в одном из ближайших обновлений
С переходом на новый вид списка инфоблоков, пропала и никак не появляется возможность управлять картинками в списке у элементов инфоблока:
-Детальная картинка
-Картинка анонса
-Свойство типа файл
-Детальная картинка
-Картинка анонса
-Свойство типа файл
Если в списках при создании элемента нажать n раз на кнопку "сохранить", то мы получим n элементов. Это в корне неправильно!
У нас более 600 сотрудников и множество форм заявок реализованным на списках.
И всегда находятся ̶н̶е̶люди, которые нажмут несколько раз (доходило до 6) на кнопку "сохранить", в результате получаем дубли, много дублей!
Реализуйте, пожалуйста, блокер на кнопку "сохранить" (после нажатия) или хотя бы анимацию выполнения действия.
У нас более 600 сотрудников и множество форм заявок реализованным на списках.
И всегда находятся ̶н̶е̶люди, которые нажмут несколько раз (доходило до 6) на кнопку "сохранить", в результате получаем дубли, много дублей!
Реализуйте, пожалуйста, блокер на кнопку "сохранить" (после нажатия) или хотя бы анимацию выполнения действия.
Было бы здорово иметь возможность фильтровать товары в торговых каталогах по ценам из админки. Скрин:
Идея предложена на основании обращения в техподдержку №2300013 от 27.03.2019
Идея предложена на основании обращения в техподдержку №2300013 от 27.03.2019
Реализовать возможность ограничения по категориям или другим условиям для накопительных скидок. Условно говоря человек накопил скидку 10%, но для некоторых категорий она может быть максимально возможной - 7%, в правиле работы с корзиной в таком случае это непонятно как выставлять, да и возможно ли вообще.
Речь идет именно о накопительной системе, в самих категориях с такими ограничениями товары могут быть и со скидками 10-20-30%.
Речь идет именно о накопительной системе, в самих категориях с такими ограничениями товары могут быть и со скидками 10-20-30%.
Предлагаю реализовать в маркетинговых акциях такую возможность. Если человек оплачивает заказ в течение заданного количества минут - то стоимость заказа уменьшается на % или конкретное число. Или стоимость доставки. Не важно. Как еще один стимул оплатить заказ.
Товары имеют разные типы цен (и разные валюты)
Можно настроить, чтобы все учетные цены конвертировались на сайте в одну - это хорошо.
В умном фильтре все равно показано несколько цен, в разных валютах.
Изменения в параметрах не работают - это плохо.
Давайте сделаем, чтобы в умном фильтре все цены тоже могли конвертироваться в одну нужную.
Можно настроить, чтобы все учетные цены конвертировались на сайте в одну - это хорошо.
В умном фильтре все равно показано несколько цен, в разных валютах.
Изменения в параметрах не работают - это плохо.
Давайте сделаем, чтобы в умном фильтре все цены тоже могли конвертироваться в одну нужную.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
