Change value of one custom db field changes dependent fields - silently and incorrectly

[Monika Danielsson]

I have some Database Custom Fields. One is defined in terms of another (as in sql code "...WHERE secondtable.column={customfield_first}", if that makes sense), where the second one has several options for each choice in the first field.

Now, if both fields have values, and I change the first field, then the second field gets changed too. And not to none (as one might expect, since I have the "add none option" checked), but to the first value in the list of possible values. Even more scary, this seems to be done silently, so there's no trace of this change in the history of the issue; it took me a while to even notice that it was happening, and how it was happening.

Both my fields are custom database fields, defined as select lists. I do think it makes sense to change the value in the second field when the first changes - but I consider it a bug to pick a (fairly arbitrary) value and (silently) set it, instead of both setting it to none, and noting it in the history. Am I right, or have I overlooked something?

[Alexandru_Iacob]

Hi Monika,

Are you reffering to the inline editing feature from view issue? If so, yes, this was the intended behavior.

When changing a value in inline edit for a db field all dependent fields will be updated on issue with the first matching value for the new dependency. We will try however to record this change in the issue histroy in the next release of databasecf.

Regards,

Alex

[Monika Danielsson]

Hi,

Thanks for the quick reply! I appreciate that you are so quick at responding to these questions! (And also, I appreciate the plans for adding history - thanks!)

But, pray tell me - why change to the first matching value? If there is only one matching value, then I can maybe understand it - maybe - but if there's more than one match, how can randomly picking one be the right thing to do, from a user point of view?

Regards,

/Monika