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

Для описания в языковых файлах предлагаю
1. Использовать сами идентификаторы описываемых событий, то есть например:
без добавления дополнительных идентификаторов, типа "mymodul_" и т.д., так как по заданному стандарту предполагается присутствие всех нужных партнерских идентификаторов в имени идентификатора события.
2. Описывать событие в неопределенной форме, кратко, то есть "Добавление раздела инфоблока" можно использовать такое описание в любом месте, а вот "Событие вызываемое при добавлении раздела информационного блока", или "Вызывается при создании раздела", или "Позволяет изменить данные созданного раздела" и т.д. не универсально.
3. Описывать только стабильные события, то есть те, которые можно смело использовать, не боясь, что они будут переименованы, удалены и т.д.

Наличие языковых файлов позволит разработчикам, использующих события:
1. Упростить поиск доступных и стабильных событий.
2. Упростит получение списка событий в человекопонятном виде, а значит уменьшит время на формирование функционала, и исключит не нужны прослойки.
3. Упростит жизнь тем, кто активно работает с событиями, освободив массу времени от задач по постоянному добавлению новых событий, удалению убитых и т.д.

Ну реально наболело и отнимает слишком много времени на актуализацию и очеловечивание списка событий, особенно в части партнерских модулей!

ВАЖНО: ключи в массиве языковых значений должны полностью соответствовать символьному представлению события в коде включая РЕГИСТР, это значительно упростит написание кода, это позволит получать символьное представление событий для динамической вставки в код, равно как позволит получать человекопонятное описание события для последующей динамической вставки и вывода и т.д.

Модуль безопасности дает возможность блокировать на заданное время IP при превышении заданного количества хитов в заданный промежуток времени, но нет возможности блокировать IP на заданное время в случаях:
- заданного количества несовпадений пары логин/пароль
- заданного количества неверно набранного слова для защиты от автоматической регистрации

Жаль нет возможности загружать файлы к идее, а так загрузил бы журнал в Excel весом в 5,2 MЬ, каждая строка которого содержит инфу о неверно набранном слове для защиты или несовпадении пары логин/пароль. Весь этот журнал был собран журналом событий в течение суток, и в нем всего два IP-адреса, то есть был тупо перебор, с одного IP была попытка подбора пароля к логину admin (которого на проекте нет ), со второго IP был перебор для обхода каптчи. ЭТОТ БАЛАГАН НАДО ПРЕКРАЩАТЬ, и не силами модулей партнеров, а системно!

Десктопное приложение одно на уже 4 облачных порталах! Выход с последующей авторизацией - не умно! Хочу поддержку множества порталов в одном десктопном приложении!!!

1. Важно - MODUL_ID, для привязки вновь созданного файла к иному модулю, ибо сейчас при копировании файлов, с целью их сохранения и дальнейшего использования в другом модуле, в случае удаления первичного "модуля-автора" происходит удаление всех файлов, включая вновь созданные копии. А это не есть ГУД. Когда модули взаимосвязаны, но при этом могут работать как самостоятельные приходится держать столько копий файлов, сколько модулей ими пользуется, о вынужденных извращениях для поддержки актуальности ВСЕХ копий промолчу.
2. Не часто, но требуется - ORIGINAL_NAME - для задания нового имени вновь создаваемой копии.

Можно оба параметра массивом!

А именно добавить в настройках курсов возможность:
- "Запрещать переход к следующему уроку, если промежуточный тест для самопроверки не пройден"
- "Запрещать прохождение итогового теста, если не пройден хотя бы один промежуточный тест для самопроверки"
- "Разрешить повторное прохождение итогового теста только после повторного ознакомления с мат.частью" - то есть если не прошёл итоговый тест, то повторно его пройти можно будет только после прохождения всех промежуточных тестов для самопроверки, что вынудит тестируемого повторно ознакомиться с мат.частью, и как следствие повысит его знания.

Так вот хотят два клиента из 5-ти, использующих модуль обучения. Мотивируют это тем, что такая возможность уменьшит риск прохождения итогового теста с использованием шпаргалок и наугад, так как чтобы добраться до итогового теста придётся постараться, и мат.часть учить всё же придётся! Клиентам важна не только успешная сдача итогового теста, но и обязательное ознакомление с мат.частью

Подобно свойству СПИСОК расширить свойство привязки к элементам ИБ, а именно - добавить возможность определять по какому полю таблицы осуществляется привязка.

Сейчас привязка осуществляется по ID элемента, к которому привязываем, очень не хватает возможности привязывать не по ID, а например по имени элемента, или по значению свойства элемента.

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

Так же это позволит сохранить связи между элементами разных ИБ при экспорте/импорте всего объёма данных встроенными средствами. Сейчас после импорта/экспорта (csv и xml) данных нескольких ИБ, имеющих взаимосвязи приходится вручную восстанавливать связи между ИБ, а если это 12 ИБ, и в каждом более 1000 элементов, труд получается ёмким!

До сих пор решали задачу добавлением свойства, в значение которого через init.php вписывали ID элемента, а компоненты отдавали элементы не по ID, а по значению нужного свойства, но с ростом проектов растут init.php, и нагрузка соответственно.

Опытным путём выяснил, что для очистки кэш компонентов ИБ БУС берёт путь из настроек инфоблока (путь к индексной странице, к разделу и к элементу).
При использовании ИБ на разных URL-ах очистка кэш происходит только по одному адресу, согласно настроек ИБ, что лишает возможности использования режима автокэширования компонентов, обрабатывающих URL-ы отличные от настроек ИБ.


1. В режиме НЕ кэшировать - нагрузка вырастает в 10-ки раз
2. В режиме автокэширования, но без очистки кэш всех работающих с ИБ компонентов - неактуальная информация, ошибки в обработке данных, которые меняются достаточно динамично.
3. init.php используемый для очистки кэш остальных компонентов по событиям - на большим проектах слишком быстро растёт, а вместе с ним растёт и нагрузка.

Как путь решения - добавить в настройках ИБ возможность добавлять дополнительные пути к файлам с компонентами, кэш которых необходимо очистить, и очищать кэш по заданным URL-ам, но не включать их в SiteMap.

Сортировка по ИМЕНИ, если имя является числом, в общем-то в любом софте, работает в порядке:
0
...
9
10
...
19
20
...
29
и т.д.
В БУС сортировка по имени работает
1
10
11
12
...
2
20
21
и т.д.

Проблематично, когда имя элемента или раздела это число, или начинается с числа.
1. Неудобно когда необходимо сформировать и не дай Бог выгрузить список в файл.
2. Препятствует при реализации на базе БУС многих задач, особенно задач связанных с автоматизацией, а так же при интеграции с иным софтом или оборудованием.

Возникают трудности при указании в полях:
сайта 1: mart72.ru
сайта 2: tdmart72.ru
или
сайта 1: dom-pechati.ru
сайта 2: forum.dom-pechati.ru

Трудности:
1. Дизайн-шаблоны подключаются как хотят.
2. Навигация (меню) включаются как хотят.
3. Sitemap - генерятся как хотят.
4. При создании страницы на сайте 1 страница может создаться файловой структуре сайта 2 и наоборот, а может и на своем месте создаваться, то есть опять же как попало.
и т.д.

Если в случае с сайтом и форумом dom-pechati.ru я еще хоть как-то могу понять, то с доменами mart72.ru и tdmart72.ru это уже ошибка, ибо оба домена второго уровня и они все-таки разные!

Идея: определять текущий сайт по 100%-му совпадению текущего домена с одним из доменов из поля
Поисковые роботы в обоих случаях считают сайты разными и не "склеивают" их.

Добавить в форме редактирования меню поле "title", чтобы больше не кастомить компоненты меню.

P.S. - в SEO очень важное значение имеет наличие "title"  в ссылках.

1. Надо дополнить список категорий всеми существующими модулями, т.к. все они могут быть улучшены.
2. Надо сделать выбор категорий множественным, так как многие идеи относятся и к БУС и к КП!

Есть предопределенный набор справочников (Категории, Критичности, Статусы, Оценки ответов, Частые ответы, Источники, Сложность). Можно использовать мастер, и через ИБ увеличить количество входных параметров, но увы использование ИБ в этом случае не позволяет использовать входные параметры для фильтрации обращений и формирования достойного и внятного отчета.

Надо добавить в модуль ТП возможность добавления собственных справочников!

P.S. - Почему при создании добавлении идеи нельзя выбрать более одной категории? Почему в списке категорий нет модуля ТП и других модулей? Кто считает, что отсутствующие в списке категорий модули идеальны и не требуют улучшения?