I was recently looking at access rights for attributes and seeing if certain attribute properties are controlled by M and others by C, but it seems like I have access to all attribute properties with the M access rights. Does anyone know what Create access rights gives for attributes?
With DOORS' concept of hierarchy and inheritance and with the general concept that everything may have its own access rights, not every single access right makes sense.
C on "something" allows you to create "something else" that is one hierarchy level below the "something". If you have an Object in your Module and remove C on this Object's properties for a group of users these users may not create Objects below this Object (example: Object containing the heading of chapter 2.3. The users will not be allowed to add any Objects in Chapter 2.3).
There is nothing in the DOORS hierarchy below Attribute definitions and Attribute values, so setting or removing C here has no effect.
In the hierarchy, Attribute definitions are directly below the Module. So, in order to prevent that a user creates Attributes on their own, you will have to remove C for this user on the Module, i.e. in the module properties. Unfortunately, this will also disallow that user to create any Object on Level 1, leaving them to being next to unable to edit the module content.
Also, removing C on the module properties will disallow the users to create Views, as View definitions are also placed directly below the Module in the hierarchy.