Здравствуйте!
 Появилась задача разделить права на проведение документа в зависимости от вида документа. Пример для понимания: есть объект документ "Приказ". Есть права на этого объект у одного подразделения на создание этого документа, у другого подразделения на изменение и проведение этого документа.
Теперь хотят, чтобы одно из подразделений могло проводить приказы только определенного вида ("ВидПриказа"- -это реквизит документа "Приказ"), а другое подразделение приказы другого вида. Есть такая возможность?
---
Если без RLC, то контролировать подпиской на событие "при проведении", проверять есть ли права у подразделения текущего пользователя.
---
1. Из соображений наименьшего вмешательства в конфигурацию - я бы тоже посмотрел, в первую очередь, в сторону подписки на событие.
2. Если не брать во внимание соображения из п.1, то подумал бы в сторону статусов, как и советовали. Например, сделал бы статусы:

   - Подготовлен
   - Передан в управление
   - Утвержден управлением - финальный статус
   - Утвержден деканатом - финальный статус

Соответственно, документ формирует движения по регистрам только при статусах "Утвержден управлением" и "Утвержден деканатом". А вот доступ к установке этих статусов разграничен по подразделениям. То есть, будет 2 ветки прохождения приказа по маршруту согласования.
---
такая возможность есть http://infostart.ru/public/104176/
---
почитала, RLS
применяется для следующих видов прав доступа:

Чтение
Добавление
Изменение
Удаление

 Проведения здесь нет, RLS недоступно
---
у вас действительно сценарий работы таков что одно подразделение создаёт документ, а второе - проводит его?
если да - то что-то тут не так
---
да, так и есть, деканат приказ создает, а управление его проверяет, проводит, но есть приказы, которые деканат сам должен проводить, управление не несет за это ответственности, поэтому и нужно настроить проведение приказов для разных видов приказов
---
нафига тут вообще проведение? я бы статусы сделал.
дело вкуса
---
Проведение нужно (это же документ, а не справочник) для того, чтобы у студента менялось состояние, все запросы берутся из регистров, в которые этот документ создает записи.
---
Виктория, не каждый документ проводится и тем более делает движение, зависит от прикладной логики и что справочник не может формировать записи в регистр сведений состояний ?
---
я когда такой вещью заморачивался, делал справочник статусов, там указывал кто может его менять и на какие следующие статусы он может перескочить. В идеале для таких задач есть бизнес процессы, но у нас этот большой документ вырос из документа, который должен был только фиксировать решение - да или нет. Переписывать не охота было. Так вот проверка ролей - при нажатии кнопки. Если у Вас многоступенчатый документ - то может 2 статусами не ограничиться, будет гулять Ваш документ по кругу от подразделения к подразделению и только на последнем проводиться.
---
я как раз и воспользовалась проверкой ролей
---
Если без RLC, то контролировать подпиской на событие "при проведении", проверять есть ли права у подразделения текущего пользователя.
---
попробую, отпишусь
---
1. Из соображений наименьшего вмешательства в конфигурацию - я бы тоже посмотрел, в первую очередь, в сторону подписки на событие.
2. Если не брать во внимание соображения из п.1, то подумал бы в сторону статусов, как и советовали. Например, сделал бы статусы:

   - Подготовлен
   - Передан в управление
   - Утвержден управлением - финальный статус
   - Утвержден деканатом - финальный статус

Соответственно, документ формирует движения по регистрам только при статусах "Утвержден управлением" и "Утвержден деканатом". А вот доступ к установке этих статусов разграничен по подразделениям. То есть, будет 2 ветки прохождения приказа по маршруту согласования.
---
Воспользовалась подпиской на событие, как вариант решения задачи использовать можно. Спасибо!!!
---
Так я и написала уже по факту, что вот именно этот документ делает движение в регистр, проводить его обязательно, иначе мне придется снимать с поддержки несколько объектов и "пилить" запросы, зачем усложнять себе задачу и изменять конфигурацию там, где можно это обойти. Мы, наоборот стараемся максимально возможно не менять саму конфигурацию. Кстати, вот Роли у нас свои, их и хотелось править, но не случилось.