• 2 replies
  • Latest Post - ‏2012-11-26T17:43:19Z by llandale
38 Posts

Pinned topic Access Rights on Attribute Definition or Attribute Value

‏2012-11-26T09:29:02Z |

reading the DXL documentation confuses me a little bit when having a look at the section for access controls for attribute definitions or attribute values.

Under the section of access rights for attribute values you can see functions as canCreate, canModify or canDelete.
Under the section of access rights for attribute definitions you see canCreateVal or canDeleteVal, but no canModifyVal.

This leads me to the open question whether it is necessary to check if a user can modify an attribute value. Isn't it enough to check whether the user has create rights? The same holds for canCreate. If the user has create rights, isn't it enough? Or is the user not able to set null values for such attributes if canDelete is false for this attribute?

Can someone explain what is the meaning of create, modify and delete in the context of attribute definitions and attribute values?

Moreover, can anyone explain the difference between canCreateDef and canCreateAttrDefs? Is only the signature of the functions different, but the functionality is the same?

Thanks in advance, Helko
Updated on 2012-11-26T17:43:19Z at 2012-11-26T17:43:19Z by llandale
  • Helko
    38 Posts

    Re: Access Rights on Attribute Definition or Attribute Value

    Another strange point is that canRead(AttrType at) returns true, if the current DOORS user can read the attribute type definition or false otherwise. It is strange or senseless, because you have to catch a real value other than null for 'at' to prevent a null pointer exception, but therefor you need read access to that attribute type.

    Hope that someone can clarify.

    Cheers, Helko
  • llandale
    3035 Posts

    Re: Access Rights on Attribute Definition or Attribute Value

    The "canXX" commands figure out what the user can do right now; so to "canCreate" you must have access AND have the module open Edit. CanXX therefore accurately predict the success of the various create/modify et tal commands. Checking access rights is inadequate.

    For Attr Definitions, you must have the module open Exclusive and have appropriate "C" rights to the module.

    "C"reate rights to values and specific Defs seem to have no meaning (since attributes are not in a hierarchy). Never really thought about that before.

    for Attr Values, you must have "M" rights to the Attr Values AND must have access to the Object; either Exclusive or Shared and locked, and "M" rights.
    • bool CanChangeValue(Object o, string NameAttr)
    • { // Can I change the object attr-value?
      • AttrDef ad = find(module(o), NameAttr)
      • return(canModify(o) and canModifyVal(ad))
    • }

    canCreateAttrDefs(Module) says whether you have such rights to create some new Attr Def.

    Not sure what canCreateDef(AttrDef) realistically means since I don't think you can get a non-null AttrDef handle unless it already exists.