Topic
  • 4 replies
  • Latest Post - ‏2013-07-18T19:46:56Z by DOORSguy
sfb
sfb
8 Posts

Pinned topic access rights to attributes?

‏2011-04-08T18:48:53Z |
Is there a way to set the access rights to specific attributes (of the enumeration type) in DOORS 9.2? I would like to identify safety attributes and lock them so others can not accidentally change the safety attribute of a requirement. They will need modify access to the object for populating other attributes.
Updated on 2011-04-12T14:12:02Z at 2011-04-12T14:12:02Z by sfb
  • SystemAdmin
    SystemAdmin
    346 Posts

    Re: access rights to attributes?

    ‏2011-04-10T08:11:34Z  
    DOORS attributes have two levels of access rights.

    1. Access rights to control who is allowed to change the value of an attribute.

    2. Access rights to control who is allowed to alter the definition of an attribute.

    You're after the first one - from the DOORS module menu select Edit > Attributes - select the attribute you want to control. You should now see a dialogue box with three tabs, one of those is named 'Access(Value)'. Deselect the "Inherit from Parent" check box and then define the specific access rights for users\groups e.g. set the Everyone Else group to R (read-only) and give specific users\groups RM (read & write) access at least.

    I'm not sure of your experience with access rights in DOORS but it is good practice, and certainly easier to manage, to apply access rights only to user groups rather than to individual users.


    Paul Miller
    Melbourne, Australia
  • sfb
    sfb
    8 Posts

    Re: access rights to attributes?

    ‏2011-04-12T14:12:02Z  
    Thank you.
  • DOORSguy
    DOORSguy
    2 Posts

    Re: access rights to attributes?

    ‏2013-07-18T15:09:40Z  

    Implementation follow-on question:

    In order for the specific users/groups (who have at least Modify permission in the specific attributes' "Access (Value)" tab) to actually be able to open the module in exclusive edit mode (let's not mess with shareable mode), do you not also need to give them Modify permission at the module level?

    If you give them Modify at the module level, then they get Modify for all the remaining attributes that are still inheriting access perms, but we don't want that.

    Therefore, would you not need to set up perms such that the couple of attributes that you want to give access to are the ONLY ones that inherit Modify from the module, and inheritence needs to be broken in the "Access (Value)" tab of every other attribute that you don't want them to be able to modify?

    I haven't done this in quite a while and just want to make sure my logic is correct before I start breaking a whole bunch of inheritances.

    Thanks!

  • DOORSguy
    DOORSguy
    2 Posts

    Re: access rights to attributes?

    ‏2013-07-18T19:46:56Z  
    • DOORSguy
    • ‏2013-07-18T15:09:40Z

    Implementation follow-on question:

    In order for the specific users/groups (who have at least Modify permission in the specific attributes' "Access (Value)" tab) to actually be able to open the module in exclusive edit mode (let's not mess with shareable mode), do you not also need to give them Modify permission at the module level?

    If you give them Modify at the module level, then they get Modify for all the remaining attributes that are still inheriting access perms, but we don't want that.

    Therefore, would you not need to set up perms such that the couple of attributes that you want to give access to are the ONLY ones that inherit Modify from the module, and inheritence needs to be broken in the "Access (Value)" tab of every other attribute that you don't want them to be able to modify?

    I haven't done this in quite a while and just want to make sure my logic is correct before I start breaking a whole bunch of inheritances.

    Thanks!

    I just recognized that my case is the opposite (complement?) to the original poster's. They did, in fact, only want to "lock down" a minority of attributes, whereas I want to enable editing in the minority of attributes.

    Looks like it's time to dust off some access-permission-setting dxl scripts.