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

Есть большая необходимость открытия БП в новом окне, а не в живой ленте.

Пример: много кастомных активити, для которых надо применять сложную js логику - очень не хочется, чтобы это конфликтовало с чем-то в ЖЛ.
Также всевозможные подключаемые в активити css скрипты, которые могут конфликтовать с битриксовыми и едет верстка у половины портала
Если это неприемлемо в визуальном интерфейсе - добавьте параметр к CBPActivity, чтобы его можно было изменить программно для кастомных активити.
Сейчас же в коде шаблона жестко прописано открывать только 2 типа активити в новом окне - RequestInformationActivity и RequestInformationOptionalActivity.
Очень не хочется лезть в битриксовые компоненты и шаблоны, т.к. они постоянно подвергаются изменениям и эти изменения очень сложно отслеживать.

Имеется огромная необходимость в отладчике бизнес-процессов.
Вот несколько проблем, которые решит отладчик:

• Возможность прогнать (читай исполнить) бизнес-процесс в коде не запуская его на выполнение в рабочем процессе
• возможность отловить ошибки при переносе с тестового на боевой (отмечу что сейчас при переносе неправильно записываются некоторые действия из раздела Дополнительные результаты)
• Возможность тестирования БП при доработке функционала (сейчас если что-то изменил при доработке, то отследить, где именно в какой активити "php-код" использовался доработанный код не представляется возможным)
• Тестирование
  

и.т.д.

Разработчики, пожалуйста, услышьте, это действительно надо. Есть БП, в которых участвуют 10 лиц и более, это невозможно  невыносимо тестировать такие большие процессы "в живую".  

Сейчас запускать бизнес-процессы автоматически можно только в 2х случаях:

• при создании
• при изменении
  

Было бы шикарно закончить логически событийную обработку запуска бизнес-процессов и сделать возможным их запуск при удалении элемента.

На мой взгляд это бы сильно облегчило жизнь разработчикам, т.к. не пришлось бы писать каждый раз обработчики удаления элементов инфоблоков, crm сущностей и прочего, а просто можно было бы сделать БП, поставить его запуск при удалении элементов и реализовать в нем любую логику, вплоть до отмены удаления.  

При обновлении 15.0.2 модуля "Универсальные списки" внедрили следующее:[*]Теперь нельзя изменить тип поля после его добавления.

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

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


Вижу варианты решение проблемы:
1. В настройках модуля "Универсальные списки" поставить галочку "Позволять пользователям редактировать типы полей после создания" - простой вариант
2. В настройках модуля "Универсальные списки" полная настройка доступа  Пользователь/группа/отдел  -  список  -  доступ (позволять редактировать типы полей при создании/не позволять) - лучший вариант

Добавить событие удаления пользователя из учебной группы - OnBeforeLearningGroupMemberDelete для класса CLearningGroupMember.

Добавить функционал в модуль обучение:

1. Добавить возможность автоматической проверки вопросов типа "Текстовый вопрос" с механизмом множественного ввода ответов (например ответы 5,5,5.5,5.50 и 5,50 считать одинаковыми); предусмотрть проверку по словам (например когда пользовательский ответ состоит из нескольких слов - его разбивать и сверять с эталонным по словам, удаляя ненужные пробелы и знаки препинания)
2. Добавить возможность вывода статистики сдачи тестов по каждому курсу/главе/уроку в графическом виде с возможностью экспорта в excel, а также статистики каждого пользователя.
   

Исправить:

1. Возможность выбора родителя при создании курса/главы/урока (а не только при его редактировании).
2. Убрать неудобный функционал перенаправления в раздел "все уроки" при создании урока в администраторской части сайта, и перенаправление на вновь созданной урок в публичной части сайта (или сделать чекбокс вида "открыть урок после создания").