Несколько сотен пользователей, десятки отделов... Я задолбаюсь вручную всех раскидывать
Тогда используйте 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 данные прочитаются значительно быстрее.
Другое дело, что разница может быть не такой существенной на малых обьемах
