На данный момент в CRM Битрикс24 создать почтовый шаблон, доступный всем пользователям CRM, может только администратор портала. И нет отдельной настройки в правах доступа к CRM, которая бы позволяла выдать некоторым пользователям CRM такую возможность:
То есть, сейчас получается, что, например, начальник отдела продаж (который, по-хорошему, утверждает шаблоны писем, которые отправляются клиентам по заказам и счетам), не может самостоятельно создать шаблон письма для всех своих подчинённых.
Обходных путей сейчас три:
- сделать начальника отдела продаж (администратора CRM) одновременно и администратором всего портала (что может не соответствовать его реальным полномочиям в организации).
- создавать шаблоны писем от имени одного из администраторов портала, и за каждым изменением дёргать этого администратора (что в условиях, например, тестирования реакции клиентов на разные формулировки в письмах, может происходить очень часто - и неудобно ни продажникам, ни администратору портала).
- каждому сотруднику отдела продаж создавать копию шаблона у себя (что создаёт дополнительные накладные расходы по поддержанию шаблонов в актуальном состоянии у всех сотрудников, и создаёт простор для ошибок - опечаток и неточностей у каждого отдельного сотрудника).
Исходя из этого, было бы гораздо удобнее и правильнее, если бы можно было дать определённой роли в CRM возможность создавать "глобальные" для всех пользователей CRM почтовые шаблоны.
Компонент профиль пользователя (main.profile) всегда обновляет пользователя целиком. Он каждый раз ожидает, что в $_REQUEST к нему придут EMAIL, LOGIN, NAME и все остальные обычные поля.
Получается, если мы хотим дать пользователю редактировать только, например, пароль, то все остальные поля нужно выводить в hidden-инпутах. Это неудобно и небезопасно - пользователь может подделать значения hidden полей и всё-таки обновить скрытые поля (поля обычно скрыты если не используются или содержат служебную информацию).
Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.
Если сложная иерархия компании и сложная система прав, приходится создавать большое количество "плоских" групп и потом просто путаешься, где какие права даны и не пересекаются ли они.
Необходимо сделать, чтобы группы прав могли строиться по иерархическому принципу. Тогда включение сотрудника в одну из нижних групп позволит получить в наследовании всю необходимую цепочку прав.
Необходимо позволить включать одну группу в другую и наоборот, как это сделано в MS AD.
Должна быть кнопка отчета на сотрудника или группу, которая позволяет наглядно выводить информацию по всем текущим правам и запретам и откуда эти права и запреты возникли.
Создал форум для своего интернет магазина. Перейдя на него в разделе "Пользователи"сразу же после создания увидел множество якобы зарегистрированных пользователей.
После обращения в ТП Битрикс выяснилось, что туда попадают те зарегистрированные пользователи сайта, кто хоть раз переходил на форум.
В моем случае оказалось, что туда попали все пользователи, которые были созданы мною из админпанели (сам я в тот момент был авторизован как администратор).
В связи с чем возникает вопрос - для чего это сделано? В Техподдержке посоветовали написать здесь.
На форум попали даже пользователи, созданные для интеграции с 1С и Битрикс 24. Также там отображаются учетные записи пользователей сайта, которые не желают, чтоб их данные были общедоступными. Убрать их со списка я не могу. Прокомментируйте пожалуйста. А еще лучше устраните попадание описанных выше пользователей в список пользователей форума.
Концепция многосайтовости подразумевает, что в одной БУС находятся пользователи нескольких сайтов. Для их разделения обычно используются группы. Приходится вручную добавлять пользователя в конкретную группу после регистрации на конкретном сайте. А нужно всего лишь добавить в стандартный компонент bitrix:main.register список множественного выбора с группами, в которые помещать пользователя после регистрации. Реализуется очень просто, а пользы много =)
При сдаче проекта имеем много тестовых данных, которые подчищаем: пользователи, заказы, эл-ты инфоблоков. После подчистки, ID сущностей, разумеется, не сбрасываются, а продолжаются. Один раз клиент спросил меня о возможности сброса номеров заказа. Может заведем кнопку "Обнулить счетчики"? С подтверждением действия. В MySQL такая возможность есть:
ALT ER TABLE имя_таблицы AUTO_INCREMENT = 1;
/*правда ни разу не выполнял на таблицах Битрикса, да и вообще */
Разумеется, нужно чтобы человек понимал что делал. Как вариант - сделать эту кнопку в тех местах, где она будет востребована (например в самих заказах). Насколько подсказывает логика, кнопка может быть активной только тогда, когда в соответствующей таблице в БД нет строк (удалены все заказы, эл-ты инфоблоков и т.д.)
Конечно, тут разработчикам нужно внимательно проследить, не будет ли нарушения целостности данных.
UPD: сейчас выполнил запрос на сброс первичного ключа при заполненной таблице b_iblock_element. Добавил новый элемент в инфоблок через админку. Новый ID продолжился.
Удалил все строки из таблицы и еще раз выполнил предложенный выше запрос на сброс первичного ключа. Добавил эл-т в инфоблок через админку. ID эл-та присвоилось значение "1". Следующему - "2". Что и хотелось видеть. Как и думал, сброс первичного ключа работает при очищенных записях в таблице.
В таблице со списком пользователей не хватает поля "Кем изменен". На портале бывают проблемы, когда пользователь жалуется, что у него появляются неверные данные в профиле. Проверяем 1С ЗУП, все нормально, там данные правильные. Получается, что либо пользователь сам ошибся при изменении данных профиля (что бывает чаще всего), либо кто-то из администраторов правил пользователя, либо какая то ошибка в выгрузке 1С на момент обновления. Найти концы и избежать таких проблем в будущем без такого поля весьма сложно.
Часто возникает необходимость посмотреть сайт по умолчанию для пользователей, чтобы выполнить над ними какие-то действия, ведь пользователи с разных сайтов - это зачастую совсем разные люди с разными задачами. Но такой возможности вообще нет. Нет даже возможности узнать этот "сайт по умолчанию", не заходя на страницу редактирования пользователя.