I've just come across a rather strange element of fucntionality that I wasn't aware of before. I'm interested to illicit views on whether this is expected functionality or not.
Create an object attribute of some enumerated type (say Value_1, Value_2, Value_3). Set the attribute to have a default value of "Value_1". Create some objects, and they receive the default value "Value_1".
Now imagine that you want to change the default value for objects created from this point on to "Value_3". Change the default value in the attribute definition to "Value_3" and Hey Presto! all your old objects that used have the previous default value of "Value_1" now have the value "Value_3"!
I can see some circumstances where such behaviour might be useful, but I can't believe that this would be the default (pun intended) behaviour.
Is this a generally known 'feature'? A long-standing bug? I have seen the behaviour in both v8.3 and v9.2.0.2.
Craig_Cordrey - Tue Jun 15 06:41:20 EDT 2010 |
|
Re: Default Attribute Values
PDU - Tue Jun 15 09:18:17 EDT 2010
Hello,
it is a normal behaviour :
if you have specified a value for an attribut, change the default value do not change the value of this attribut.
but if you have specified a value for an attribut, it have always a default value, blank (by default) or the default value you define for the attribut. So if you change this default value, all attributes with no specified value change?
Pierre
|
|
Re: Default Attribute Values
Craig_Cordrey - Tue Jun 15 10:31:36 EDT 2010 PDU - Tue Jun 15 09:18:17 EDT 2010
Hello,
it is a normal behaviour :
if you have specified a value for an attribut, change the default value do not change the value of this attribut.
but if you have specified a value for an attribut, it have always a default value, blank (by default) or the default value you define for the attribut. So if you change this default value, all attributes with no specified value change?
Pierre
And this seems like acceptable behaviour to everyone?
Yesterday I was deriving a new set of requirements associated with a user GUI. I wanted to set the "Allocated_To" attribute of all these requirements to "GUI". The easiest way of doing this was by using the Default. Today I am deriving a new set of requirements associated with a Record_Replay capability. I want to set the "Allocated_To" attribute of all these requirement to "Record_Replay". The easiest way of doing this is by changing the Default. Wow, all of yesterday's requirements are now allocated to "Record_Replay".
Am I really the only person on the planet that wants to work this way?
|
|
Re: Default Attribute Values
SystemAdmin - Tue Jun 15 11:03:51 EDT 2010 Craig_Cordrey - Tue Jun 15 10:31:36 EDT 2010
Yes, that is correct - if I don't physically select "Value_1" for my attribute value and I change the default to "Value_3" then my attribute value changes to "Value_3".
And this seems like acceptable behaviour to everyone?
Yesterday I was deriving a new set of requirements associated with a user GUI. I wanted to set the "Allocated_To" attribute of all these requirements to "GUI". The easiest way of doing this was by using the Default. Today I am deriving a new set of requirements associated with a Record_Replay capability. I want to set the "Allocated_To" attribute of all these requirement to "Record_Replay". The easiest way of doing this is by changing the Default. Wow, all of yesterday's requirements are now allocated to "Record_Replay".
Am I really the only person on the planet that wants to work this way?
It sounds to me like you want a default value of 'Not Set' in your Allocated_To enumeration. This way you can add a number of new requirements, filter on 'Not Set' and then set the required value for those objects by editing the display set.
Hazel
|
|
Re: Default Attribute Values
Craig_Cordrey - Tue Jun 15 11:10:16 EDT 2010 SystemAdmin - Tue Jun 15 11:03:51 EDT 2010
Craig,
It sounds to me like you want a default value of 'Not Set' in your Allocated_To enumeration. This way you can add a number of new requirements, filter on 'Not Set' and then set the required value for those objects by editing the display set.
Hazel
|
|
Re: Default Attribute Values
kbmurphy - Tue Jun 15 18:58:56 EDT 2010 Craig_Cordrey - Tue Jun 15 11:10:16 EDT 2010
Yes, most of our important attributes have a 'TBD' default value to ensure that they are specifically set to a value, hopefully applying some intellectual effort in doing so. That's why it's taken me so long to find this anomalous (in my view) behaviour.
For instance, I had a default value for an attribute, and I used the Quality Center integration and pushed this attribute to QC. AND it used inheritance. Well, it didn't work, because the default value that was inherited actually isn't a value that could be seen in the child objects. In other words, a change to the parent object's value with inheritance does not count as a change to the children, thus to the QC Integration, only one requirement changed, and not say, 40.
In other words, always be weary when changing default values and using inheritence too. I run scripts that say something like:
o."Attribute with Inheritance" = o."Attribute with Inheritance"
before changing these types of attribute definitions.
|
|
Re: Default Attribute Values
llandale - Thu Jun 17 13:57:16 EDT 2010
'Default' value does not mean 'Initial' value. That is, 'default' does NOT mean the that the obj-attr value gets set when the object is created, or when the Default is changed.
A 'Default' value is presumed when the object has no value for that attribute. Normally you cannot tell the difference since when you display the value in the GUI and when you retrieve the value with DXL (string s = obj.NameAttr), you get the value OK. However, in DXL you can deduce whether the object has an actual value with the 'bool hasSpecificValue(obj, AttrRef__)' perm. With that perm, you can tell when an object is having its value defaulted or whether its actually set to the Default value.
To do what you want, you should set all objects that currently have no value ..err.. no specific value to the old default, and then change the default. Something like this:
AttrDef ad = find(mod, NameAttr)
for obj in entire mod
do
{
if (!hasSpecificValue(obj, ad))
{ noError() obj.NameAttr = ValueOldDefault lastError()
}
}
then change the Default.
The above applies to 'inherited' attributes. When an attr is both 'defaulted' and 'inherited', then top-level-one objects can 'default' their values, all other objects will 'inherit'.
|
|
Re: Default Attribute Values
Craig_Cordrey - Fri Jun 18 04:10:22 EDT 2010 llandale - Thu Jun 17 13:57:16 EDT 2010
'Default' value does not mean 'Initial' value. That is, 'default' does NOT mean the that the obj-attr value gets set when the object is created, or when the Default is changed.
A 'Default' value is presumed when the object has no value for that attribute. Normally you cannot tell the difference since when you display the value in the GUI and when you retrieve the value with DXL (string s = obj.NameAttr), you get the value OK. However, in DXL you can deduce whether the object has an actual value with the 'bool hasSpecificValue(obj, AttrRef__)' perm. With that perm, you can tell when an object is having its value defaulted or whether its actually set to the Default value.
To do what you want, you should set all objects that currently have no value ..err.. no specific value to the old default, and then change the default. Something like this:
AttrDef ad = find(mod, NameAttr)
for obj in entire mod
do
{
if (!hasSpecificValue(obj, ad))
{ noError() obj.NameAttr = ValueOldDefault lastError()
}
}
then change the Default.
The above applies to 'inherited' attributes. When an attr is both 'defaulted' and 'inherited', then top-level-one objects can 'default' their values, all other objects will 'inherit'.
|
|