Topic
11 replies Latest Post - ‏2014-03-06T08:59:56Z by HazelWoodcock
jester76
jester76
68 Posts
ACCEPTED ANSWER

Pinned topic DOORS 9.5.1.2 Default value error

‏2014-02-25T17:10:16Z |

Hello,

Just found out that DOORS 9.5.1.2 has introduced this bug. If you try to set default value to an attribute for a set of objects you get an error.

Problem is that I have deployed it in my organization.

I am looking for an alternatives:

I know I can set a default value and life is good. But I have a user who needs the default value blank. I was wondering if there is a way to set a default value which is treated as blank.

I tried null and <"">

any thoughts?

 

Thanks

  • GregM_dxler
    GregM_dxler
    162 Posts
    ACCEPTED ANSWER

    Re: DOORS 9.5.1.2 Default value error

    ‏2014-02-25T18:51:47Z  in response to jester76

    Why do you need to set a default value of blank?  If you leave the default value unchecked, then the default value is blank.

    • jester76
      jester76
      68 Posts
      ACCEPTED ANSWER

      Re: DOORS 9.5.1.2 Default value error

      ‏2014-02-25T18:55:28Z  in response to GregM_dxler

      Correct, But if you try to reset the default value in that case on a set of selected objects or in current view. you get an error.

      • GregM_dxler
        GregM_dxler
        162 Posts
        ACCEPTED ANSWER

        Re: DOORS 9.5.1.2 Default value error

        ‏2014-02-25T20:32:24Z  in response to jester76

        Oh, this seems to be even more of an issue than first thought.

        I make a new attribute called Default Test.  I then check the Default value and enter in Default Value as the Default value.  Added the column for the new attribute and it shows up with Default Value for all objects.

        I then try and edit the Default Test attribute of one of the objects by double clicking the object's Default Value column.  It will let me change the value, but won't let me remove the value.  If I try to just delete the text, when I click out of the object, the default value comes back.

        Thinking that it has something to do with the object attribute having a default flag set or not, I tried to be sneaky by changing it's value (thereby making it not a default value) and then trying to delete the new value.  Nope, when I go to delete the new value, it then jumps back to the default value again.

        If I go into the attribute property and uncheck the default value, all the objects will then have the default value removed.

        I don't see in the object properties, selecting the attribute and editing it, there is any way to select or unselect the default value.

        So the crux of the matter is that when a default value is checked for an attribute, it can have the default value or another value, but not blank.  In order to get it empty, you have to have the default value unchecked.

        I then tried to use the attribute definition to determine properties and it gave me something interesting.  I print out the canWrite boolean property and it gives true or false.  I print out the inherit boolean property and it gives me true or false.  But when I print out the defval boolean property it gives me 182631808 !  I have to assign it to a variable of the right type in order to get true/false.

        The only workaround I see is to never have a default value.

        Hope this helps a little,

        Greg

         

        • MichaelGeorg
          MichaelGeorg
          53 Posts
          ACCEPTED ANSWER

          Re: DOORS 9.5.1.2 Default value error

          ‏2014-02-26T12:48:27Z  in response to GregM_dxler

          I don't think the problems, which the two of you describe above are necessaryly the same.

          Jester76's problem produces an error message due to an action that should be quite common for regular users in several cases. This problem was already reported to IBM - however I don't remember when it was promised to be fixed.

          While the problem described by GregM_dxler from my point of view might perhaps not be a bug but wanted behaviour.

          @Jester76: Our solution was to create a script that iterates over the selected / viewed / all objects and changes the value back to default one by one.

          @GregM_dxler: Do you know if the behaviour you describe has been introduced only with DOORS 9.5.x? I think it was there all the time as  in some of my scripts I use o.<attrName> = "" to set the attribute back to its default value.

           - Michael

          • GregM_dxler
            GregM_dxler
            162 Posts
            ACCEPTED ANSWER

            Re: DOORS 9.5.1.2 Default value error

            ‏2014-02-26T13:44:56Z  in response to MichaelGeorg

            Hi Michael,

            Your right that the two problems are not exactly alike, but they are part of the same issue.  In Jester76's case, when you try to set a default value of null, it gives you an error message saying the default value can not be empty. I can almost buy this as wanted behaviour, since it would make sense that if you want to specify a default value, then it should be a value.  However, I think there is unexpected consequences with that, with the additional problems associated with the default value that I reported on.  That is, having an attribute defined with a default value, and then not being able to set an object with no value.  The bug is that if the attribute is defined as having a default value, then you can override that and set it to any other value EXCEPT no value.

            Not sure if this was introduced in 9.5.x or not.  I have the same version as Jester76.  I don't recall that this operated this way before though.

            As for the solution, it depends on what you wanted it to do.  I can see it setting an object's attribute value to be the default value, or the same value as the default value.  But if the attribute definition defines a default value, then I don't see how you can set an object's attribute to no value because instead it will set it to the default value.  The only thing I can see is to set the attribute definition to not use a default value at all and then have the script set each object's attribute to that value.  Then any other object that you want to set the attribute to no value, you can.

            Hope this is clearer,

            Greg

  • llandale
    llandale
    2943 Posts
    ACCEPTED ANSWER

    Re: DOORS 9.5.1.2 Default value error

    ‏2014-02-26T20:26:50Z  in response to jester76

    When an attribute definition has a "default" value, then when the value is otherwise null the value appears to be the default.  "Appears" is most common uses, including:

    • When that attribute is displayed in a view column, that is what you see
    • You see that value in the Object Properties for that attribute
    • dxl querying the value retrieve the default value: string Value = obj."NameAttribute"

    No matter how you set the value to null or blank (in a column, in the properties, or with DXL), then it will appear to have the default value.  That is not a "bug", that is the intended behavior.

    If the default value is "Default" and you type in the string "Default" for that obj-attr, it is hard to tell if it is defaulted or actual.  The clumsy "hasSpecificValue()" perm can indeed tell the difference; which can be demonstrated nicely if you insert the following code into a layout column.

    • AttrDef ad = find(current Module, "aaTemp")   // "aaTemp" is name of the attribute
    • if (hasSpecificValue(obj, ad)) //
    • then display ""
    • else display "Defaulted"

    I can think of no method of changing the behavior that a null value is the "trigger" to display the Default.  Thus, attributes with a default cannot be null.  I wonder though, if you could just enter a space instead; which to human eyes appears to be null.

    -Louie

    In my opinion, it is usually unreasonable for "string" or "text" or attributes to have a default value.  Enumerated and Boolean are natural candidates (note that booleans default to "False"); and I can see where defaulting an integer to "-1" may make sense instead of the default-default of zero.

    I notice that when in-place editing, you see the "set to default" as an option; for enumerated attributes is just another "enumeration".  I notice when modifying the value from the Object Properties, you see a separate "set to default" button; which indeed I didn't see the first couple times I fired it up just now.

    "Inherited" values behave as do Default.  I think if an attribute is both "inherited" and "defaulted", then "inherited" takes precedance; meaning the default value is only used when this object and none of it's ancestors has an actual ..err.. specific value.

     

    • PRM
      PRM
      32 Posts
      ACCEPTED ANSWER

      Re: DOORS 9.5.1.2 Default value error

      ‏2014-02-26T21:00:05Z  in response to llandale

      As Louie has pointed out, the observed behaviour is not a bug\defect of DOORS but is intended - or maybe it was an accidental intention as some features sometimes turn out to be.

      W.r.t. best practice when using enumerated lists in any software application, the use of a blank option is considered to be confusing when a value is deemed to be mandatory or needs to be explicit. 

      Does a blank mean that someone has overlooked entering an expected value? Does a blank mean that a value is considered to be not applicable? A blank value can trigger a number of potentially incorrect interpretations. 

      So in most cases where a mandatory value is expected, it is wise to have a default value that is a non blank, and that a blank is not a selectable option at all. The classic default value is "To be Determind" (TBD). This explicitly represents that no decision has been made and can be easily filtered to hunt down how many decisions are still outstanding. Another option that should be in most enumerated lists is "Not Applicable" - this indicates that a decsion has been made and it was determined that a value was not applicable, at least that can also be filtered easily and challenged where necessary.

      Paul Miller
      Melbourne Australia

       
      • llandale
        llandale
        2943 Posts
        ACCEPTED ANSWER

        Re: DOORS 9.5.1.2 Default value error

        ‏2014-02-28T17:37:33Z  in response to PRM

        I have the following minority counter opinion; which I agree is subjective and by no means compelling.

        I argue that while it is true that "TBD" is easy to understand, being able for a human to notice it is more important.

        If an attribute value "must" have a value, then I think it is better if no-action is seem as a blank than "TBD", as it is easier for human eyes, when viewing a mostly populated list, to see a blank faster than to see some illegal value like TBD.  For example for attribute "Severity", I think the blanks in the 2nd column are easier to see than the TBD in the 1st.  We can have our cake and eat it too, the 3rd column.

         

        Your way
        My Way
        Both Ways
        High
        High
        High
        Low
        Low
        Low
        TBD
         
        >>TBD<<
        Med
        Med
        Med
        TBD
         
        >>TBD<<
        Low
        Low
        Low

        I thus tend to reserve "default values" for the "default case" not the "illegal case"; folks can set the value when this particular object needs it.  The "default case" for attribute "Status" may be "New"; which I'd make the "default value".

        -Louie

        I note that both "TBD" and a blank are equally easy for a DXL script (in general, computers) to find and "understand", for example in order to report (or filter) on the illegal values.

        You may notice that all stoves (that sill have rotary analog controlls), "off" is always up.  It is thus easy to tell at a glance if any of the burners are "on"; the one that is not "up" stands out when its neighbors are all "up".  Noticing that is it "on" at all is by far more important (for safety reasons) than being able to tell "how much on" it is.  Take a closer look if you need to know that.  Randomly changing the orientation of "off" of the dials would result in technical correctness (yes, you can still understand each dial and the burners would get to the right temperature), but you will end up frequently burning your food and sometimes your entire house; in spite of being "correct".

        I say "Correct" is less important than "Good".  Unfortunately, "Correct" is far easier to objectively "prove".

        • PRM
          PRM
          32 Posts
          ACCEPTED ANSWER

          Re: DOORS 9.5.1.2 Default value error

          ‏2014-02-28T22:28:26Z  in response to llandale
          I agree about the point that a blank in an attribute cell is more visually obvious, but a blank is still ambigouos.
           
          Because mangement has an obsession with knowing how much more requirements analysis work is waiting to be done and other stakeholders such as Testers need a clear direction with some decisions, there needs to be clear measurement delineation between pending decisions and decisions already made. When using scripts or filters or whatever to get metrics, a blank could be interpreted as being a pending decision or it could mean, well, many other things (not applicable, illegal value, not known, zero, null etc). I don't advocate this for every attribute, it's kind of useful for really important attributes, particularly those that are used to report back to management to help them sleep at night. It doesn't have to be a boring "TBD" as the default, it can an actual value as a starting point such as your example about a "Status" type attribute, just preferably something that is not a blank. It's not law, it's just advice. 

          Paul Miller
          Melbourne Australia

          • llandale
            llandale
            2943 Posts
            ACCEPTED ANSWER

            Re: DOORS 9.5.1.2 Default value error

            ‏2014-03-05T20:12:47Z  in response to PRM

            I agree a blank loses credibility unless you know the attribute must have a valid value; in my case above a blank could be understood to mean no Severity instead of "TBD" Severity since there is nothing about that attribute that suggests it is mandatory ..err.. must be set mindfully.  Note that my "Status" example does not need to be set mindfully, so "New" is reasonable for the default.

            The "Both Ways" above seems to mitigate your valid consern.

            -Louie

            • HazelWoodcock
              HazelWoodcock
              25 Posts
              ACCEPTED ANSWER

              Re: DOORS 9.5.1.2 Default value error

              ‏2014-03-06T08:59:56Z  in response to llandale

              I use colours for the different values to get over the man-readability issues, so a typical enumeration might be

              Value Colour
              NOT SET Red
              N/A Grey
              High Black
              Medium Black
              Low Black

              The red of NOT SET grabs the attention

              The grey of N/A allows you to visually pass over this entry

              All valid values are in default black.