Администраторы потеряли доступ к созданным объектам, помещенным в архив

[Askell]

Добрый день
Используем Лоцман PLM 8.5.2.1
Недавно обнаружили что многие администраторы имеют доступ только "Чтение" к объектам, которые они создали, но уже помещены в архив. Пользователи при этом состоят только в группах Users и Administrators. При этом права на тип и на состояние у групп установлены, соответственно, "Чтение" и "Полный доступ" - согласно документации "Если пользователь входит в несколько групп, имеющих разные уровни доступа к одинаковым типам объектов, документов, атрибутам или состояниям, то ему дается максимальный из уровней доступа всех пользовательских групп, в которые он входит." - т.е. не должен быть полный доступ, но почему то это не так.
Может быть менялось членство пользователей в группах, но почему тогда права не пересчитались, когда пользователю были повышены привелегии? Можно ли это поправить штатными средствами без прямого ковыряния в базе?

Спасибо.

[tur]

Создайте еще одну административную группу Лоцмана, дайте в конфигураторе Лоцмана для этой группы доступ к объектам и состояниям которые Вам нужны, добавьте в группу пользователя (при этом лучше чтобы этот пользователь был только в одной этой группе) и будет вам счастье!

[Askell]

Нет, не помогло - создал новую группу, у нее сделал полные права на тип и состояние проблемного объекта (с правом создания на всякий случай), удалил пользователя из всех групп, добавил в новую - права как были на чтение, так и остались.
Начал копать внутреннюю структуру БД: таблица dbo.stPrivileges, столбец inlevel=1 (чтение), inOwnLevel=3 (Администрирование). Меняю inLevel - меняется результирующий уровень, членство в группах никак не влияет. Т.е. похоже баг похоже где-то в алгоритме рассчета прав, видимо когда делали понижение прав создателя, либо триггер какой-то поломался...

[Danila]

Да, посмотрите вкладку безопасность. Там стоят директивные права, которые судя по всему при каких-то ваших махинациях опустились.
Вы можете через БД скинуть эти права. Или попробовать откатить до предыдущего состояния, чтобы состояние вернулось до уровня owner. Тогда при переводе в архив вы не потеряете права.

Кстати, мы тоже создали группу SuperAdmin, в которой определили права максимальными. Так как иногда некоторые особо умелые разработчики умудряются опустить права админам. А потом с этим мучаться - не весело.

ПС. если есть директивные права для пользователя/группы- просто удалитесь из группы Администраторы и тогда ваши права повысятся)

[Askell]

ПС. если есть директивные права для пользователя/группы- просто удалитесь из группы Администраторы и тогда ваши права повысятся)

В том то и дело, что директивные права установлены для создателя, и удалиться из такой группы никак)

Да и вообще это похоже на какой то баг системы директивных прав - почему то ни через штатный интерфейс, ни через альтернативынй, например LWF, нельзя назначить директивные права создателю, что очень странно. Т.е. грубо говоря, я как администратор, могу директивно дать любому пользователю с улицы доступ к объекту в архиве, кроме создателя - его директивные права недоступны для редактирования. При этом система сама рассчитывает эти права как-то криво.
Конечно, придется, видимо, скидывать права через базу, либо попробую через API, но не совсем понятно, как такая ситуация сложилась, т.к. в нее вовлечены несколько пользователей и несколько десятков тысяч объектов и что делать чтобы она не повторялась. Хотя конечно проблему можно решать периодическим запуском SQL скрипта или модуля, но это как-то некрасиво.

[Danila]

есть некоторые особенности, с ними несложно справляться, хорошо зная структуру БД Лоцмана.

Тогда можно быстро все это исправлять.

Ну и грамотно если внести некоторую коррекцию по части БД - то можно избавить от большого количества проблем в будущем.

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

так что будьте сразу готовы много разбиратсья в БД, чтобы получать максимальный результат.

АПИ - это хорошо, но он своеобразен. Им много дел сразу не сделаешь, да и разработан он исходя из потребностей интерфейса Лоцмана. А опять же не пользователей, а значит кол-во шагов для получения результата - будет большим.

[Askell]

Через API UpGrantOnVersion тоже не получилось поменять директивные права создателя - метод отрабатывает без ошибок, но ничего не делает.
Еще пробовал давать директивные права пользовательской группе, но похоже директивные права пользователя имеют больший приоритет по сравнению с директивными правами группы, в которую он входит (что в общем то логично).
Так что похоже придется SQL скриптом править директивные права в базе.

UPD.
Неожиданно UpGrantOnVersion с параметром boDel отработал - удалил директивные права! Так что теперь администратор получил обычные права на свой же объект наравне с другими администраторами. Хотя конечно на полноценное системное решение это не тянет - лечится следствие, а не причина - полный список объектов на которые назначены некорректные права создателям все равно предстоит формировать самим.

Ну либо как вариант, снести к чертям все директивные права, по крайней мере у создателей. Кому реально надо - попросят еще раз.

[Danila]

Аскел, зачем?
просто удалите назначенное директивное право - и не будет проблем. Или просто назначьте повышенные права другим пользователем, не входящим в настроенные директивные права (находящимся вне этих групп - как у нас в суперадминах - для них стоят права также повсюду полный доступ).

Как вариант - через БД. Но в интерфейсе Лоцмана есть возможность настройки групповых прав, в том числе с удалением имеющихся.

Есть, конечно, проблема - через лоцман сделать правильную выборку с нужными правами - невозможно. Это только через БД. Или как вариант везде для всех объектов уничтожить/выставить право Администраторам - Полное. Но отклик интерфейса и время выполнения вас неприятно удивят, если у вас большое кол-во объектов)))  Но результат будет)))

[Askell]

Да, похоже придется удалять директивные права, причем через плагин - в интерфейсе такой возможности нет, лезть руками в базу религия не позволяет.
А все пляски с группами тщетны - у пользователя-создателя объекта автоматически добавляются директивные права на это объект, а вот какие - система решает похоже с потолка, т.к. иногда иногда эти права выставлены правильно, а иногда - нет. И эти директивные права перекрывают все, что мы нагородим для этого пользователся с группами.
И самое веселое, что как я уже писал, отредактировать директивные права создателя ни через интерфейс ни через API (что логично, ведь интерфейс через API и работает), нельзя. На удивление, через API получилось удалить директивные права, хотя в интерйефсе эта команда недоступна для директивных прав создателя.
Получается, что проблема в архитектуре системы безопасности - система, в принципе, не обязана менять директивные права пользователя при изменении его членства в группах, на то они и директивные. Но почему тогда права создателя назначаются через директивные права и не пересчитываются? Чем он провинился? Видимо пытались через эти директивные права оставить лазейку чтобы создатели получали полные права на созданный объект (правда непонятно,зачем это), с которой тоже у кого то была проблема, описанная на этом форуме - у создателей оставались полные права на объект после перевода в архив. Несовсем понятен изначальный посыл - зачем давать создателю полные права на создаваемый объект - ну есть у пользователя право создавтаь объект в определенном состоянии, ну и перкрасно, главное чтобы были права на редактирование объекта в этом состоянии и соответственно возможность перевести его в следующее состояние - перевел конструктор свой объект из состояния проектирование на согласование и все, потерял права на редактирование, вернули ему объект обратно в работу - получил права снова. Зачем было огород городить, непонятно.

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

[Danila]

API  зачастую тоже не даст вам сделать ничего больше, чем доступно в системе.
Там точно такая же проверка прав и соответственно возможности. В итоге большинство механизмов АПИ зашито в процедурах и триггерах БД. но могут быть и исключения. Мы в большинстве переориентировались на использование БД.

Так что вам лучше просто грамотно разобраться с вашей системой конфигурирования прав. У вас где-то ошибка в методологии при построении системы прав доступа.

Скорее всего или где-то не выставлены права доступа или для состояния или для типа объекта.

если все правильно сделать, то результат можно получить и через интерфейс. но надо хорошо понять, что от чего как зависит и как построена их система.

Очень, конечно, неплохо для этого хорошо все-таки знать скуль, чтобы можно было профайлером находить, что используется у лоцманистов при тех или иных действиях - а соответственно найти их логику и в случае, если она претит вашей выстроенной системе, и затем грамотно ее сориентировать под свои правила. Но делать это надо ООООЧЕНЬ аккуратно. Не зная всей цепочки - можно наворотить таких проблем...

У вас используется старая версия Лоцмана, никакой тех.поддрежки на нее уже нет, ну или можно сказать практически нет. Так что создаете тестовую базу и дерзаете.

В вашем случае, прежде чем лепить "заплатку" в системе - неплохо более глобально понять, что и как устроено внутри, иначе вам не избежать будущих проблем в построении системы.

[Askell]

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

[Danila]

проверьте внимательно права доступа к объектам.

назначать права можно только при имеющемся полном доступе (белом кружке).

если после смены состояния директивные права понизились, то вернутся они при откате прав,а директивно поднять невозможно все-таки из-за ваших прав в конфигураторе!

смотрите внимательно права доступа!

[Askell]

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

UPD. Тему можно закрывать - помог подход из известного сереиала IT Crowd: "а вы не пробовали выключить и включить" - передернул объект туда-сюда между двумя состояниями ("разрешено к применению"->"проектирование"->"разрешено к применению") - директивные права создателя пересчитались корректно, счастье в жизни есть.