Решение простенькой задачи
Поступает, значит, запрос:
- Сделать раздел в библиотеке, где какие-то документики будут согласовываться, старт процесса при загрузке документа, условие - чужие документы видеть не должны. Сделаешь?
- Лехкотня! (у нас же есть расширенные права!)
Приступаю. Создал раздел, прикрутил процесс при запуске, осталось только настроить права и вперде!
Это легко: дать операцию на добавление элемента, чтение папок, чтобы видел, куда кидать и запуск бп. Чтение элементов не дадим, чтобы чужое не смотрел, а чтобы со своим мог работать - дадим права на изменение автору!
Логично, блин.
Небольшое , кому лень смотреть, краткое содержание серии:
Но задачу-то надо решать и сейчас. Менять логику на более логичную штатного компонента или модуля, смотря где такое поведение - как-то неохота, опять потом следить за изменениями и мёржить ручками при апдейтах, это засада. Решаю устанавливать права через бизнес-процесс, раз он всё равно будет использоваться, да там вроде как и было бы неплохо автору запретить изменение документа при согласовании, чтобы у него не было соблазна подменять уже согласованный документ (никто же не заметит) и разрешить при возврате на доработку.
Тут, правда, есть нюанс - бизнес-процессы так и не научились работать с объектами из расширенных прав, типа оргструктуры, поэтому придётся создавать новую группу под сотрудников, которым надо дать доступ к этому функционалу. А потом добавлять в неё новых сотрудников, удалять старых при кадровых перестановках, в общем, админить, вместо того, чтобы дать права отделу один раз и забыть... Удовольствие, мягко, скажем, сомнительное. Про удобство вообще молчу. Но зато не забуду случайно и при апдейте не отвалится...
Второй нюанс - бизнес-процессы не могут переопределять внешние права
Но на этот случай у меня уже давно сделан хак, так как я с этим столкнулся при попытке в прошлый раз организовать функционал на вебдаве + бп. Описывал я это (ну да, с тех пор вроде ничего не изменилось по обоим пунктам).
В общем, решаю пересмотреть построение схемы, будет она такой:
Мда. Форму прав читабельной особо не назовёшь, раньше она выглядела лучше, насколько я помню, переопределяемые права прятали исходные, зачем-то переделали, хз. Хоть бы блин зачёркивали переопределённые права, чтоб понятней было! А то так можно и в ступор впасть, особенно с учётом
Цитата из доков. Выходит, что несмотря на мои переопределённые права на элемент, приоритет будут иметь разрешающие на директорию??? 
Проверил на сотруднике, поставив автору запрет доступа к элементу - тот пропал из видимости сотрудника. Фух, вроде хоть тут прокатило.
Вот вроде бы и всё, задача решена? Добавил ещё там прав человекам, которые могут создавать директории и рулить документами без ограничений, боссы, короче. Отдал в тестовую эксплуатацию. Вроде бы всё?
Как бы не так!
Функционал эксплуатируется некоторое время, накидано уже порядочно документов. В какой-то момент мне говорят, что форма с правами какая-то неудобная, не читается (а я же говорил!), ну и вообще, с правами что-то не так похоже.
Ладно, иду посмотреть.
Заглянув ещё раз в эту форму, я решаю, что хоть автора пришибить из настроек прав директории, чтобы он потом отнаследованный не смущал взоры контролирующих сотрудников. В общем, в задумчивости я немного поклацал по правам на директорию (а может поклацали ещё до меня, просто я не успел посмотреть, что было). Для пущей понятности, я записал сие с примерной демонстрацией действий и последствий.
Вкратце - изменение прав на директорию грохнуло все переопределённые права для этих же объектов на элементах! Крутотенюшка!!!
Кстати, при установке прав на элемент может возникнуть схожая ситуация - переопределённые права могут просто исчезнуть при сохранении!
К нам пришёл пушной зверёк, товарищи. Напомню, что документов уже накидали порядочно и у них у всех теперь порушились права, которые надо восстанавливать. Развлечение задарма, налетай!
Тут я, конечно, "сердечно" поблагодарил разработчиков за нереализацию такой бесполезной штуки, как установка прав в групповых операциях над документами - ...
Ну что делать. Права, я конечно, повосстанавливал на документы, а куда деваться? Но вся эта нервотрёпка (которая может и повториться при неудачном посещении кем-нибудь формы настроек прав) для решения простейшей задачи меня так достала, что я пошёл и как обычно сделал очередной хак в компоненте, чтобы бизнес-процесс запускался логично, без необходимости прав на чтение элементов и реализовал всё по первоначально планируемой схеме.
Вот такая вот "лехкотня" получилась. Иногда настолько очевидные и банальные вещи приходится делать через какое-то место.
Поступает, значит, запрос:
- Сделать раздел в библиотеке, где какие-то документики будут согласовываться, старт процесса при загрузке документа, условие - чужие документы видеть не должны. Сделаешь?
- Лехкотня! (у нас же есть расширенные права!)
Приступаю. Создал раздел, прикрутил процесс при запуске, осталось только настроить права и вперде!
Это легко: дать операцию на добавление элемента, чтение папок, чтобы видел, куда кидать и запуск бп. Чтение элементов не дадим, чтобы чужое не смотрел, а чтобы со своим мог работать - дадим права на изменение автору!
Логично, блин.
Небольшое , кому лень смотреть, краткое содержание серии:
- Создаём уровень доступа "Добавление и запуск БП": Добавление элемента (чтобы мог загрузить документ), запуск бизнес-процесса (чтобы мог процесс при загрузке стартануть), чтение секции (чтобы мог видеть каталоги и грузить, в какой нужно)
- Даём права на инфоблок: отделу - "Добавление и запуск БП", автору - "Изменение с ограничениями", чтобы мог видеть и работать только со своими документами
- Проверяем под пользователем, чужие документы не видит, ок. Загружаем документ - доступ запрещён!
- Хм... Может, операция редактирования элемента нужна, вдруг его БП менять будет. Добавляем в уровень доступа
- Проверяем - доступ запрещён!
- Хм... Может, операция на установку прав на элемент? Чёрт знает, зачем, но вдруг!
- Проверяем - доступ запрещён!
- Что ж ей надо-то!? Создавать элемент можно! Запускать БП можно! Редактировать можно! И даже права выставлять на этот элемент!
- Ну давай ради эксперимента дадим права на чтение элементов...
- УРААА! Работает!..... Только вот это же чтение, теперь все видят все документы других людей...
- В данном уровне доступа запуск БП разрешён и баста! Какое ему дело до другой операции? И как догадаться о такой зависимости? Да даже пусть, но почему именно чтение, там ещё и читать-то нечего, документ не загружен, элемент не создан?
- Создающий элемент сотрудник - его автор, а у автора доступ крутой. И чтение там наличествует, но...
Но задачу-то надо решать и сейчас. Менять логику на более логичную штатного компонента или модуля, смотря где такое поведение - как-то неохота, опять потом следить за изменениями и мёржить ручками при апдейтах, это засада. Решаю устанавливать права через бизнес-процесс, раз он всё равно будет использоваться, да там вроде как и было бы неплохо автору запретить изменение документа при согласовании, чтобы у него не было соблазна подменять уже согласованный документ (никто же не заметит) и разрешить при возврате на доработку.
Тут, правда, есть нюанс - бизнес-процессы так и не научились работать с объектами из расширенных прав, типа оргструктуры, поэтому придётся создавать новую группу под сотрудников, которым надо дать доступ к этому функционалу. А потом добавлять в неё новых сотрудников, удалять старых при кадровых перестановках, в общем, админить, вместо того, чтобы дать права отделу один раз и забыть... Удовольствие, мягко, скажем, сомнительное. Про удобство вообще молчу. Но зато не забуду случайно и при апдейте не отвалится...
Второй нюанс - бизнес-процессы не могут переопределять внешние права
Но на этот случай у меня уже давно сделан хак, так как я с этим столкнулся при попытке в прошлый раз организовать функционал на вебдаве + бп. Описывал я это (ну да, с тех пор вроде ничего не изменилось по обоим пунктам).В общем, решаю пересмотреть построение схемы, будет она такой:
- Создаём новую группу пользователей "Согласование документиков", сидим и тупо заносим в неё нужный отдел (радость-то какая!)
- Даём этой группе доступ на нашу директорию "Изменение с ограничениями" (там есть и разрешённая операция чтения элементов, без которой, оказывается, процесс не запустить)
- В бизнес-процессе первым делом переопределяем права этой группе на элемент - "доступ запрещён", чтобы не читали чужие документы
- Автору во всех случаях, кроме "доработки" даём доступ только чтение, в статусе "доработка" - изменение с ограничениями
Мда. Форму прав читабельной особо не назовёшь, раньше она выглядела лучше, насколько я помню, переопределяемые права прятали исходные, зачем-то переделали, хз. Хоть бы блин зачёркивали переопределённые права, чтоб понятней было! А то так можно и в ступор впасть, особенно с учётом
| Важно! Помните о том, что приоритет доступа имеет разрешающую направленность. К примеру, если в настройках инфоблока доступ к библиотеке документов для сотрудника запрещен, а для папки в составе этого инфоблока - разрешен, то сотрудник сможет с ней работать. В обратном случае (для инфоблока - разрешен, для папки-запрещен) - сотрудник все равно будет иметь к ней доступ в соответствии с выставленным правом доступа. |
Проверил на сотруднике, поставив автору запрет доступа к элементу - тот пропал из видимости сотрудника. Фух, вроде хоть тут прокатило.
Вот вроде бы и всё, задача решена? Добавил ещё там прав человекам, которые могут создавать директории и рулить документами без ограничений, боссы, короче. Отдал в тестовую эксплуатацию. Вроде бы всё?
Как бы не так!
Функционал эксплуатируется некоторое время, накидано уже порядочно документов. В какой-то момент мне говорят, что форма с правами какая-то неудобная, не читается (а я же говорил!), ну и вообще, с правами что-то не так похоже.
Ладно, иду посмотреть.
Заглянув ещё раз в эту форму, я решаю, что хоть автора пришибить из настроек прав директории, чтобы он потом отнаследованный не смущал взоры контролирующих сотрудников. В общем, в задумчивости я немного поклацал по правам на директорию (а может поклацали ещё до меня, просто я не успел посмотреть, что было). Для пущей понятности, я записал сие с примерной демонстрацией действий и последствий.
Вкратце - изменение прав на директорию грохнуло все переопределённые права для этих же объектов на элементах! Крутотенюшка!!!
Кстати, при установке прав на элемент может возникнуть схожая ситуация - переопределённые права могут просто исчезнуть при сохранении!
К нам пришёл пушной зверёк, товарищи. Напомню, что документов уже накидали порядочно и у них у всех теперь порушились права, которые надо восстанавливать. Развлечение задарма, налетай!
Тут я, конечно, "сердечно" поблагодарил разработчиков за нереализацию такой бесполезной штуки, как установка прав в групповых операциях над документами - ...
Ну что делать. Права, я конечно, повосстанавливал на документы, а куда деваться? Но вся эта нервотрёпка (которая может и повториться при неудачном посещении кем-нибудь формы настроек прав) для решения простейшей задачи меня так достала, что я пошёл и как обычно сделал очередной хак в компоненте, чтобы бизнес-процесс запускался логично, без необходимости прав на чтение элементов и реализовал всё по первоначально планируемой схеме.
Вот такая вот "лехкотня" получилась. Иногда настолько очевидные и банальные вещи приходится делать через какое-то место.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
