Несколько сотен пользователей, десятки отделов... Я задолбаюсь вручную всех раскидывать
Тогда используйте php api, с которым вы будете разбираться не меньше чем с REST. Быстрее будет ручками установить их (можно закинуть в головное подразделение и поручить это HRу)
Если хотите попробовать через SQL, то стоит сделать бекап базы данных.
Для данной задачи нам потребуется:
- Иметь 2 списка: "Пользователь -> Подразделение" и "Подразделение - Руководитель подразделения"
- Узнать ID пользователей которых нужно смаппить
- Узнать ID подразделений
- Установить подразделение пользователю
- Установить руководителя к подразделению
Как узнать ID пользователя?
Все пользователи хранятся в таблице b_user.
Туда можно отправить SQL запрос и по ФИО/Логину/email найти нужны пользователей
Как найти все существующие подразделения?
Узнаем ID инфоблока подразделений.
Он хранится в таблице b_option. MODULE_ID = intranet, NAME = iblock_structure в VALUE будет идентификатор инфоблока (далее #IBLOCK_ID#)
Получаем список существующих подразделений.
Подразделение - раздел информационного блока "Орг.структура".
Все разедлы хранятся в таблице b_iblock_section где по IBLOCK_ID = #IBLOCK_ID# можно найти все существующие подразделения.
Нас интересуюет ключ ID из этой таблицы
Как установить подразделение пользователю?
За привязку подразделения к пользователю отвечает поле UF_DEPARTMENT.
Это пользовательское поле (т.е. не хранится в таблице пользователей) множественное (хранится в табилце множественных значений) типа число.
Сначала узнаем идентификатор пользовательского поля. Мета-информация обо всех пользовательских полях хранится в таблице b_user_field
ENTITY_ID - мнемонический код сущности для поля (в данном случае USER)
FIELD_NAME - код поля (в нашем случае UF_DEPARTMENT)
После выполнения запроса мы получи ID поля UF_DEPARTMENT для пользователей.
Значения множественных пользовательских полей для сотрудников хранятся в таблице b_utm_user
VALUE_ID - идентификатор пользователя
FIELD_ID - идентификатор пользовательского поля (см выше)
Нас интересует VALUE_INT, туда и нужно заносить значения. Ко скольким подразделениям принадлежит пользователь, столько записей и получиться.
Как установить руководителя к подразделению?
Руководитель подразделение это свойство подразделения, а не пользователя.
Сначала находим идентификатор инфоблока подразделения (см выше).
Поле UF_HEAD (руководитель) не является множественным, поэтому его установить проще.
Нас интересует таблица b_uts_iblock_666_section, где 666 - идентификатор инфоблока (помнишь мы нашли выше из b_option?)
Для каждого пользователя есть строка VALUE_ID - идентификатор ПОДРАЗДЕЛЕНИЯ, UF_HEAD - идентификатор руководителя (пользователя).
Но помни - там могут быть и другие поля, которые обязательны к заполнению из-за чего у пользователей могут возникнуть различные ошибки.
Нет, не всех. Элемент инфоблока состоит из двух групп "Поля элемента" и "Свойства элемента". Если не указано иное, то по-умолчанию запрашиваются ВСЕ значения из группы "Поля элемента".
В моем фрагменте кода я запросил часть полей из группы "Поля элемента" (ID, IBLOCK_ID) и два интересующих вас поля из группы "Свойства элемента". Так что нет, дамп всех значений мы не получим.
А чтобы вывести значение мы пишем:
Нет, не пишем. $resElement объект класс CIblockResult и у него нет свойств и тем более к нему нельзя обратиться как к массиву. Поэтому и есть конструкция $element = $resElement->getNext()
для начала не светите $queryUrl. Я знаю токен, пользователя и мог бы скачать все данные с вашего битрикс24.
Что касается остальных вопросов: не вы же явно их не передаете сами.
tokmaganbet, для благодарностей есть кнопочка "Отметить решением".
Что касается можно ли его передавать "и директору и менеджеру":
1) Это другой вопрос (лучше не смешивать)
2) Нет, это 2 лида. У лида может быть только один ответственный.
1) В вызове REST метода передавать явно кому вы хотите направить лид (ответственного сотрудника)
2) Сделать бизнес-процесс при создании лида, в нем проверять автора и если это директор (можно прописать и другие условия) переназначать на кого-нибудь.
3) Создать веб-хук от пользователя, на которого должны падать лиды
4) Поменять ролевую систему так, чтобы менеджеры видели свои + все открытые и создавать лид с параметром "доступен для всех"
Очевидно же - в количестве свойств.
Пересматривайте обмен (пишите кастомный) чтобы все это складировать не в один инфоблок, а в разные. Заодно и производительность повысится
Александр Маджугин, давайте разберемся. Вы говорите о "дисковом буфере в оперативной памяти", я смею предположить, что вы говорите о DRAM. Так вот он есть не у всех SSD накопителей и его размер много меньше оперативной памяти и он не хранит в себе контент файлов. К тому же вы приводите синтетический тест, так как он полностью игнорирует вытеснение информации (у вас же в реальном проекте читается не только этот файл, но и. сотня файлов битрикса + upload).
Надежда Головина, новый пользователь ("сотрудник") только для обмена. Заводится в Битрикс24. Он конечно кушает дополнительную лицензию, но такова цена за безгеморройность и безопасность
Александр Маджугин, почему вы так считаете? Если сравнить файловый кеш на SSD диске и существующий ключ в оперативной памяти redis, то из redis данные прочитаются значительно быстрее.
Другое дело, что разница может быть не такой существенной на малых обьемах
Алексей Павлов, тогда только REST приложение, причем очень своеобразное - вам на своей стороне придется хранить список задач в которые пользователь добавлен наблюдателем.
Т.е. получается приложение на своем сервере с хранением oauth авторизации
Алексей Павлов, наиболее эффективное решение вашей задачи зависит от совокупности факторов:
- какая версия (облачная или коробочная) и если облачная - какой тариф
- должны ли новому "дизайнеру" быть доступны задачи с тегом "дизайн" созданные до момента его включения в этот список?
- должна ли задача быть доступной дизайнеру после исключения его из этого списка?
В коробочной версии это можно гнуть с любой стороны (там более обширное api), что касается облака то там сильно завязано на права.
