Добавить возможность выгружать личный календарь обычным пользователем в excel (или другие файлы)

На данный момент в CRM Битрикс24 создать почтовый шаблон, доступный всем пользователям CRM, может только администратор портала. И нет отдельной настройки в правах доступа к CRM, которая бы позволяла выдать некоторым пользователям CRM такую возможность:

https://XXX.bitrix24.ru/crm/configs/perms/XXX/edit/

То есть, сейчас получается, что, например, начальник отдела продаж (который, по-хорошему, утверждает шаблоны писем, которые отправляются клиентам по заказам и счетам), не может самостоятельно создать шаблон письма для всех своих подчинённых.

Обходных путей сейчас три:

- сделать начальника отдела продаж (администратора CRM) одновременно и администратором всего портала (что может не соответствовать его реальным полномочиям в организации).

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

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

Исходя из этого, было бы гораздо удобнее и правильнее, если бы можно было дать определённой роли в CRM возможность создавать "глобальные" для всех пользователей CRM почтовые шаблоны.

Компонент профиль пользователя (main.profile) всегда обновляет пользователя целиком. Он каждый раз ожидает, что в $_REQUEST к нему придут EMAIL, LOGIN, NAME и все остальные обычные поля.

Получается, если мы хотим дать пользователю редактировать только, например, пароль, то все остальные поля нужно выводить в hidden-инпутах. Это неудобно и небезопасно - пользователь может подделать значения hidden полей и всё-таки обновить скрытые поля (поля обычно скрыты если не используются или содержат служебную информацию).

Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.

Если сложная иерархия компании и сложная система прав, приходится создавать большое количество "плоских" групп и потом просто путаешься, где какие права даны и не пересекаются ли они.

1. Необходимо сделать, чтобы группы прав могли строиться по иерархическому принципу. Тогда включение сотрудника в одну из нижних групп позволит получить в наследовании всю необходимую цепочку прав.
2. Необходимо позволить включать одну группу в другую и наоборот, как это сделано в MS AD.
3. Должна быть кнопка отчета на сотрудника или группу, которая позволяет наглядно выводить информацию по всем текущим правам и запретам и откуда эти права и запреты возникли.
   

Здравствуйте.
Столкнулся с такой ситуацией:

Создал форум для своего интернет магазина. Перейдя на него в разделе "Пользователи"сразу же после создания увидел множество якобы зарегистрированных пользователей.

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

В моем случае оказалось, что туда попали все пользователи, которые были созданы мною из админпанели (сам я в тот момент был авторизован как администратор).

В связи с чем возникает вопрос - для чего это сделано? В Техподдержке посоветовали написать здесь.

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

Сделать возможность ограничивать доступ к счетам пользователя

Концепция многосайтовости подразумевает, что в одной БУС находятся пользователи нескольких сайтов. Для их разделения обычно используются группы. Приходится вручную добавлять пользователя в конкретную группу после регистрации на конкретном сайте. А нужно всего лишь добавить в стандартный компонент bitrix:main.register список множественного выбора с группами, в которые помещать пользователя после регистрации. Реализуется очень просто, а пользы много =)

При сдаче проекта имеем много тестовых данных, которые подчищаем: пользователи, заказы, эл-ты инфоблоков. После подчистки, ID сущностей, разумеется, не сбрасываются, а продолжаются. Один раз клиент спросил меня о возможности сброса номеров заказа. Может заведем кнопку "Обнулить счетчики"? С подтверждением действия. В MySQL такая возможность есть:

Разумеется, нужно чтобы человек понимал что делал. Как вариант - сделать эту кнопку в тех местах, где она будет востребована (например в самих заказах). Насколько подсказывает логика, кнопка может быть активной только тогда, когда в соответствующей таблице в БД нет строк (удалены все заказы, эл-ты инфоблоков и т.д.)

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

UPD: сейчас выполнил запрос на сброс первичного ключа при заполненной таблице b_iblock_element. Добавил новый элемент в инфоблок через админку. Новый ID продолжился.

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

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

Часто возникает необходимость посмотреть сайт по умолчанию для пользователей, чтобы выполнить над ними какие-то действия, ведь пользователи с разных сайтов - это зачастую совсем разные люди с разными задачами. Но такой возможности вообще нет. Нет даже возможности узнать этот "сайт по умолчанию", не заходя на страницу редактирования пользователя.

Нужны фильтр и столбец для сортировки.