Пардон за большое "лирическое отступление" (или вступление? пусть не лирическое):
"Бизнес-процессы организации" - так в документации окрещён функционал, штатно располагающийся в разделе "Сервисы - Бизнес-процессы" в КП и реализованный с помощью комплексного компонента bitrix:bizproc.wizards (для краткости - БПО). Я пользуюсь в основном им.
Главное преимущество - гибкое управление правами просмотра элементов, как на группы, так и на конкретных пользователей (теперь несколько нивелированное появлением расширенных прав в инфоблоках. Отмечу, что на текущий момент бизнес-процессы не могут переопределять расширенные права элементов, только добавлять свои и только если они не совпадают с правами элемента!). Причём фишка появилась задолго до появления расширенных прав ИБ. Права на доступ к элементу можно выставлять динамически из бизнес-процесса, пользуясь параметрами, переменными, определять кодом, в зависимости от требований на доступ к документу во время маршрута. Кроме этого - возможность конструировать ИБ без админки, через интерфейс дизайнера БП. Также компонент не имеет формы редактирования элемента, поэтому все изменения в нём производятся только из БП, только те поля и свойства, которые мы определим в шаблоне БП. И ещё одна замечательная фишка, которая весной прошла неафишированной и незамеченной - возможность каждому шаблону БПО назначить шаблоны компонентов запроса параметров при запуске БП, списка бизнес-процессов и формы просмотра элемента. Отличная вещь, позволяющая привычным механизмом шаблонов компонентов делать формы или список с требуемым отображением и логикой именно для этого бизнес-процесса (там есть ошибка по подключению шаблона списка, но скоро, думаю, будет исправлена, тикет есть).
Итак, как уже описал, основное из преимуществ бизнес-процессов организации (БПО) - ограничение прав доступа к документу. Особенно актуально для какой-нибудь корпоративной информации с ограниченным доступом (например, согласование документов - ограничение списком утверждающих документ и исполнителем, регистрация корреспонденции - ограничение регистратором, адресатами, исполнителем и руководством).
Часто при использовании механизма БПО для ограничения доступа возникает следующая проблема - доступ к документу установлен, документ прошёл и завершил свой маршрут и... навсегда остаётся в системе с такими правами доступа, так как штатного механизма переопределить их в дальнейшем - увы, не предусмотрено. А потребность такая возникает довольно часто - уволился сотрудник, пришёл другой на замену, должен иметь доступ к этой информации. Ну или просто захотелось ознакомить кого-то ещё, кого не предусмотрели раньше.
Но всё не безнадёжно - такую фишку можно организовать штатными средствами бизнес-процессов - с помощью зацикленной "команды" и действий "Запрос дополнительной информации" и "Установка прав". Кроме того, факт выдачи кому-то прав таким образом будет зафиксирован в логе бизнес-процесса.
В шаблоне бизнес-процесса добавляем следующую последовательность действий:
Цикл делаем вечным
Настраиваем права доступа к команде
Запрашиваем информацию у пользователя. Обратите внимание на поле "Заполняют сотрудники", в нём вызываем диалог по кнопке, идём в "Дополнительные результаты" и выбираем "Пользователь, отправивший команду" (фишка появилась тоже относительно недавно, раньше это выполнялось через специальный алиас модуля, выбирающий текущего пользователя)
Ну и установка прав, не забываем снять крыжик "Перезаписать", иначе новые права будут не добавлены, а заменят старые
Вот, в общем, и всё. Мы легко сделали нужный функционал и получили вечный бизнес-процесс, в котором в любой момент пользователи с полномочиями выполнения созданной команды смогут добавить права на просмотр элемента какому-нибудь сотруднику и это отразится в логе БП. При необходимости можно добавить уведомления добавленным пользователям или таким же образом можно подцепить и другие команды в этот финальный цикл с помощью распараллеливания обработки.
Немного усложним задачу - допустим, мы хотим, чтобы пользователи, которым мы только что предоставили доступ, также в дальнейшем могли выполнять команду предоставления доступа.
Для этого заранее через интерфейс дизайнера БП создадим переменную, например, commandUsers, тип - привязка к пользователю, множественная. После чего в настройках действия "Команда" к списку тех, кто может выполнять команду, добавим эту переменную. А после действия "Установка прав" добавим действие "PHP-код" следующего содержания
Всё. Теперь при каждой итерации цикла в действии "Команда" у нас будет переменная с обновлённым списком пользователей, которым доступно выполнение команды.
Подход определения пользователей через переменную универсален, его можно использовать и во многих других случаях, например, динамически составлять список получателей уведомлений, пользователей для утверждения, ознакомления с документом, назначать права и т.п.
Для бизнес-процессов со статусами можно действовать по похожей схеме, но зацикливая сам статус. Установка прав будет производиться в этом случае не отдельным действием "Установка прав" (так как это бесполезно при зацикленном статусе - при возврате в статус каждый раз права будут переписаны правами этого статуса):
Справедливости ради отмечу, что описанный способ зацикливания команды в конце БП, тем не менее, не лишён недостатков - такой бизнес-процесс никогда не будет завершён, соответственно его рабочие данные не будут удалены из системы, запись со всеми данными БП будет висеть в базе. Также это плохо тем, что если вы запрашивали в бизнес-процессе какие-то файлы в параметрах или переменных - они тоже будут висеть вечно и занимать место на диске, так как сборщик мусора, уничтожающий временные данные по завершению процесса, запущен не будет.
PS. На самом деле, есть два метода, которые вызываются при завершении процесса и грохающие все связанные с параметрами и переменными БП файлы соответственно. Но это ковровое бомбометание, не всегда осознанное и безопасное, в дальнейшем обещают добавить методы, позволяющие точечно зачистить параметры и избавится от проблемы временных файлов.
PPS. Текущие методы это CBPActivity::ClearProperties() и CBPActivity::ClearVariables(), которые подчищают все файлы, связанные с параметрами и переменными соответственно. Можно использовать в действии PHP-код, как $this->ClearProperties() и $this->ClearVariables(), но используйте с осторожностью, если уверены, что эти файлы вам больше не понадобятся в процессе (уже сохранены в свойства инфоблока). Сами параметры и переменные при этом не пострадают, просто будут хранить айдишники уже несуществующих файлов.
UPD: добавил пример использования переменной для определения списка пользователей и её динамической сборки через действие "PHP-код"
UPD2: добавил краткое описание для бизнес-процесса со статусами.
UPD3: добавил методы для зачистки временных файлов.
"Бизнес-процессы организации" - так в документации окрещён функционал, штатно располагающийся в разделе "Сервисы - Бизнес-процессы" в КП и реализованный с помощью комплексного компонента bitrix:bizproc.wizards (для краткости - БПО). Я пользуюсь в основном им.
Главное преимущество - гибкое управление правами просмотра элементов, как на группы, так и на конкретных пользователей (теперь несколько нивелированное появлением расширенных прав в инфоблоках. Отмечу, что на текущий момент бизнес-процессы не могут переопределять расширенные права элементов, только добавлять свои и только если они не совпадают с правами элемента!). Причём фишка появилась задолго до появления расширенных прав ИБ. Права на доступ к элементу можно выставлять динамически из бизнес-процесса, пользуясь параметрами, переменными, определять кодом, в зависимости от требований на доступ к документу во время маршрута. Кроме этого - возможность конструировать ИБ без админки, через интерфейс дизайнера БП. Также компонент не имеет формы редактирования элемента, поэтому все изменения в нём производятся только из БП, только те поля и свойства, которые мы определим в шаблоне БП. И ещё одна замечательная фишка, которая весной прошла неафишированной и незамеченной - возможность каждому шаблону БПО назначить шаблоны компонентов запроса параметров при запуске БП, списка бизнес-процессов и формы просмотра элемента. Отличная вещь, позволяющая привычным механизмом шаблонов компонентов делать формы или список с требуемым отображением и логикой именно для этого бизнес-процесса (там есть ошибка по подключению шаблона списка, но скоро, думаю, будет исправлена, тикет есть).
Итак, как уже описал, основное из преимуществ бизнес-процессов организации (БПО) - ограничение прав доступа к документу. Особенно актуально для какой-нибудь корпоративной информации с ограниченным доступом (например, согласование документов - ограничение списком утверждающих документ и исполнителем, регистрация корреспонденции - ограничение регистратором, адресатами, исполнителем и руководством).
Часто при использовании механизма БПО для ограничения доступа возникает следующая проблема - доступ к документу установлен, документ прошёл и завершил свой маршрут и... навсегда остаётся в системе с такими правами доступа, так как штатного механизма переопределить их в дальнейшем - увы, не предусмотрено. А потребность такая возникает довольно часто - уволился сотрудник, пришёл другой на замену, должен иметь доступ к этой информации. Ну или просто захотелось ознакомить кого-то ещё, кого не предусмотрели раньше.
Но всё не безнадёжно - такую фишку можно организовать штатными средствами бизнес-процессов - с помощью зацикленной "команды" и действий "Запрос дополнительной информации" и "Установка прав". Кроме того, факт выдачи кому-то прав таким образом будет зафиксирован в логе бизнес-процесса.
В шаблоне бизнес-процесса добавляем следующую последовательность действий:
Цикл делаем вечным
Настраиваем права доступа к команде
Запрашиваем информацию у пользователя. Обратите внимание на поле "Заполняют сотрудники", в нём вызываем диалог по кнопке, идём в "Дополнительные результаты" и выбираем "Пользователь, отправивший команду" (фишка появилась тоже относительно недавно, раньше это выполнялось через специальный алиас модуля, выбирающий текущего пользователя)
Ну и установка прав, не забываем снять крыжик "Перезаписать", иначе новые права будут не добавлены, а заменят старые
Вот, в общем, и всё. Мы легко сделали нужный функционал и получили вечный бизнес-процесс, в котором в любой момент пользователи с полномочиями выполнения созданной команды смогут добавить права на просмотр элемента какому-нибудь сотруднику и это отразится в логе БП. При необходимости можно добавить уведомления добавленным пользователям или таким же образом можно подцепить и другие команды в этот финальный цикл с помощью распараллеливания обработки.
Немного усложним задачу - допустим, мы хотим, чтобы пользователи, которым мы только что предоставили доступ, также в дальнейшем могли выполнять команду предоставления доступа.
Для этого заранее через интерфейс дизайнера БП создадим переменную, например, commandUsers, тип - привязка к пользователю, множественная. После чего в настройках действия "Команда" к списку тех, кто может выполнять команду, добавим эту переменную. А после действия "Установка прав" добавим действие "PHP-код" следующего содержания
Всё. Теперь при каждой итерации цикла в действии "Команда" у нас будет переменная с обновлённым списком пользователей, которым доступно выполнение команды.
Подход определения пользователей через переменную универсален, его можно использовать и во многих других случаях, например, динамически составлять список получателей уведомлений, пользователей для утверждения, ознакомления с документом, назначать права и т.п.
Для бизнес-процессов со статусами можно действовать по похожей схеме, но зацикливая сам статус. Установка прав будет производиться в этом случае не отдельным действием "Установка прав" (так как это бесполезно при зацикленном статусе - при возврате в статус каждый раз права будут переписаны правами этого статуса):
- В финальном статусе в правах статуса устанавливаем переменную, которую будем в дальнейшем заполнять;
- Добавляем к статусу команду, переходим к редактированию её подпроцесса;
- Добавляем запрос дополнительной информации по пользователям, которым нужно предоставить доступ;
- Затем действие PHP-код, аналогичное приведённому выше, в котором склеиваем массив вновь запрошенных пользователей с переменной, которая указана в правах на статус;
- Затем действие "Установить статус", в котором выбираем этот же финальный статус, в котором сейчас находимся, чем его зацикливаем.
Справедливости ради отмечу, что описанный способ зацикливания команды в конце БП, тем не менее, не лишён недостатков - такой бизнес-процесс никогда не будет завершён, соответственно его рабочие данные не будут удалены из системы, запись со всеми данными БП будет висеть в базе. Также это плохо тем, что если вы запрашивали в бизнес-процессе какие-то файлы в параметрах или переменных - они тоже будут висеть вечно и занимать место на диске, так как сборщик мусора, уничтожающий временные данные по завершению процесса, запущен не будет.
PS. На самом деле, есть два метода, которые вызываются при завершении процесса и грохающие все связанные с параметрами и переменными БП файлы соответственно. Но это ковровое бомбометание, не всегда осознанное и безопасное, в дальнейшем обещают добавить методы, позволяющие точечно зачистить параметры и избавится от проблемы временных файлов.
PPS. Текущие методы это CBPActivity::ClearProperties() и CBPActivity::ClearVariables(), которые подчищают все файлы, связанные с параметрами и переменными соответственно. Можно использовать в действии PHP-код, как $this->ClearProperties() и $this->ClearVariables(), но используйте с осторожностью, если уверены, что эти файлы вам больше не понадобятся в процессе (уже сохранены в свойства инфоблока). Сами параметры и переменные при этом не пострадают, просто будут хранить айдишники уже несуществующих файлов.
UPD: добавил пример использования переменной для определения списка пользователей и её динамической сборки через действие "PHP-код"
UPD2: добавил краткое описание для бизнес-процесса со статусами.
UPD3: добавил методы для зачистки временных файлов.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
