Права владельца

[koba]

Возник следующий вопрос по назначению прав в системе Лоцман. 3-d проектирование на нашем предприятии ведется в SolidWorks в многопользовательском режиме. Часто возникают ситуации, когда конструктор, создает сборку, вводит в Лоцман ее состав, делает предварительную компановку и деталировку в SW. Затем ему необходимо передать какие-то подсборки для более детальной проработки другим конструкторам. Соответственно он дает им права на изменение соотвествующих подсборок и деталей. Но при этом, он, являясь владельцем всех созданных им элементов, также имеет к ним полный доступ и этот доступ никак не получается с него снять. Это не может сделать ни администратор системы, ни он сам и  приводит к тому, что изменяя сборку, он случайно может изменить подсборку и сохранить эти нежелательные изменения в базу . Как все-же можно отобрать у владельца права на администрирование?

[oracle]

Я задавал аналогичный вопрос. Судя по ответу есть два способа. Первый - удалить этого пользователя (потом можно его заново создать) тогда объект останется без владельца. Второй - создать новую версию этого объекта, например модулем извещение, и владельцем станет создающий новую версию.
Вообщем здесь у них неудобно получается.

[koba]

Неужели других способов нет? Если действующего пользователя удалить из системы, а потом опять создать, он ведь потеряет индивидуальные права на доступ к файлам, их потом замучаешься восстанавливать. Компас-менеджер был более гибок на этот счет, там администратор мог задать любые права кому угодно. Или может подход к работе какой-то другой должен быть? Ведь внедрен же Лоцман на крупных предприятиях с десятками конструкторов, как-то же они выкручиваются

[AI]

Ограничение прав владельца обычно делается через смену состояний. Т.е. на объект назначается новое состояние, на которое у него максимальные права - только чтение, например.
Можно еще удалить владельца программно, через API-функцию Лоцман, но, по-моему, это не рекомендуемое действие.

[koba]

Спасибо за идею:

Ограничение прав владельца обычно делается через смену состояний. Т.е. на объект назначается новое состояние, на которое у него максимальные права - только чтение, например.

В чистом виде она правда не совсем подходит, поскольку раз уж ведется проектирование в состоянии"Проектирование", то и после передачи прав (ограничение прав владельца) состояние должно остаться "Проектирование", чтобы не было путаницы.
У меня после двух дней экспериментов получилось так:
Начальная ситуация - пользователь damir создал в базе в состоянии "Проектирование" изделие и набросал примерный его состав (сборки, подсборки и т.д.). Соответственно он является владельцем всех созданных элементов и имеет к ним доступ "Администрирование". Теперь необходимо одну сборку передать для дальнейшей работы пользователю dima, другую - пользователю alex, третью оставить себе и т.д.
Для этого было создано состояние "Передача прав" с доступом "Только чтение" для группы "Конструктора" (куда входят все указанные пользователи). Damir выбирает сборку с для передачи прав пользователю dima, назначает ему права доступа и меняет ее состояние на "Передача прав" и возвращает ее в базу . После этого и damir и dima получают на эту сборку доступ "Только чтение". Администратор базы берет сборку в работу, в "Конфигураторе" для состояния "Проектирование" группе "Конструктора" дает доступ "Только чтение" (было "Администрирование") и переводит сборку в состояние "Проектирование". Damir и dima продолжают иметь доступ на сборку "Только чтение". Администратор возвращает доступ "Администрирование" к сборке в состоянии "Проектирование" группе "Конструктора". После этого остается пользователю dima назначить необходимый ему для работы со сборкой уровень доступа ("Чтение-Запись" или "Администрирование"). У пользователя damir, несмотря на то, что он остался владельцем, установился доступ "Только чтение". Что и требовалось.

[AI]

Ничего себе комбинация! 
В принципе есть еще вариант - можно написать плагин для создания состава, который будет переподключаться к базе от имени администратора и создавать нужные объекты. Соответственно, владельцем всех объектов будет администратор. Правда, для этого нужно уметь писать плагины и напрямую подключаться к серверу.