Недавно я просматривал права доступа к атрибутам и выяснял, контролируются ли определенные свойства атрибутов M, а другие — C, но похоже, что у меня есть доступ ко всем свойствам атрибутов с правами доступа M. Кто-нибудь знает, что дает права доступа Create для атрибутов?
Что делает создание прав доступа для атрибутов?
DC United
1 июля 2021 в 17:14
54
1
Ответы (1)
Mike
2 июля 2021 в 09:41
С концепцией иерархии и наследования DOORS, а также с общей концепцией, что все может иметь свои собственные права доступа, не каждое отдельное право доступа имеет смысл.
C на "что-то" позволяет вам создать "что-то еще", которое находится на один уровень иерархии ниже "чего-то". Если у вас есть Object в вашем Module и вы удалите C в свойствах этого Object для группы пользователей, эти пользователи не могут создавать Object ниже этого Object (пример: <84306319 содержащий заголовок главы 2.3. Пользователям не разрешается добавлять Object в главу 2.3).
В иерархии DOORS нет ничего ниже Attribute definitions и Attribute values, поэтому установка или удаление C здесь не имеет никакого эффекта.
В иерархии Attribute definition находятся непосредственно под Module. Итак, чтобы пользователь не создавал Атрибуты самостоятельно, вам придется удалить C для этого пользователя на Module, т.е. в свойствах модуля. К сожалению, это также не позволит этому пользователю создавать какие-либо Object на уровне 1, в результате чего они почти не смогут редактировать содержимое модуля.
Кроме того, удаление C в свойствах модуля не позволит пользователям создавать View, поскольку определения View также размещаются непосредственно под Module в иерархии.
2 июля 2021 в 14:27
Не понял, что для создания представлений требуются разрешения C для модуля, но это имеет смысл, если представления расположены ниже модулей в иерархии. В любом случае, насколько я понял после прочтения вашего комментария, добавление C к правам доступа либо к определениям атрибутов, либо к представлениям не имеет никакого эффекта? IBM могла убрать тип доступа C, как они сделали с групповыми разрешениями, но решили оставить его.
3 июля 2021 в 05:59
Ну, я думаю, они могли бы удалить его. Разница в том (насколько я могу себе представить) что пользователи и группы полностью вне иерархии, механизм наследования (корневая папка -> подпапка/проекты -> модуль -> представления/атрибуты/.../объекты -> глубже объекты) здесь не работает, поэтому для всего в иерархии они используют один механизм, а безопасность групп имеет другую реализацию. C обычно наследуется для AccessDef и они, наверное, не хотели прерывать цепочку наследования. По крайней мере, они удалили часть диалога «распространить», что на самом деле не имело бы смысла.
И я думаю, в аналогичной заметке, кто-нибудь знает, что делает создание прав доступа для представлений?