Attribute updates itself! Causing Date Modified to be changed.

[dasymington]

This is repeatable. I have a user defined attribute called location that I use on a form in a template. At some time I have entered a value of "dunfermline" onto an item based on the template. At another time I've entered the value "Dunfermline". Both appear in the drop down list of previous values when I'm using the form. If I create a new data item based on the template and type "Dunfermline", when I go back to view that data item later the value changes to "dunfermline" and the Date Modified gets updated to the date and time that I view the item. This makes the Date Modifed item completely useless.

[armsys]

dasymington,

Please search all occurrences of dunfermline, including those in
Recycle Bin?

Armstrong

[kinook]

For attributes with 'Auto-complete values from other items' checked, UR is supposed to prevent two attributes from being assigned the same value with only upper/lower case differences. We now see that there is one situation where that isn't done -- when a value with different case is explicitly typed into a form field (not chosen from the drop-down list). In that case, it gets saved with the case difference, but when the item is displayed again, the first matching value in the drop-down is selected (the all-lower-case occurrence in your case), and the item is saved that way when leaving the item. From that point on, as long as the value is not explicitly changed again to a different case by explicitly typing it differently, the item will not be modified when visited again.

To prevent this behavior, turn off auto-completion for that attribute, but that exposes another case sensitivity issue. UR was not intended to allow naming two attributes with the same name, differing only in upper/lower case (i.e., Location and location). It does allow this, but since it is not expected, there is a problem with modifying its properties -- the Attribute Properties dialog is not loaded with the properties of the attribute, so you need to type in the name and category again (and uncheck the Auto-complete option) to modify attribute. And you may want to add a trailing space to the attribute name to avoid that problem in the future.

[armsys]

For the auto-completion, is it possible for UR to automatically insert the found char string but also restore the original case?

Armstrong

[dasymington]

Originally posted by kinook
... We now see that there is one situation where that isn't done -- when a value with different case is explicitly typed into a form field (not chosen from the drop-down list).

It's even worse than that: if you have a value for the Location attribute of, for example, Yosemite in the auto-complete list and you type "y" the value of "yosemite" appears in the attribute. Pressing tab to accept it results in the lower case value being stored and forever after being in the auto-complete list. For auto-completion to be really helpful, I think, it should show the upper case value of "Yosemite" that's already there when you start typing.

Originally posted by kinook
To prevent this behavior, turn off auto-completion for that attribute, but that exposes another case sensitivity issue. UR was not intended to allow naming two attributes with the same name, differing only in upper/lower case (i.e., Location and location). It does allow this, but since it is not expected, there is a problem with modifying its properties -- the Attribute Properties dialog is not loaded with the properties of the attribute, so you need to type in the name and category again (and uncheck the Auto-complete option) to modify attribute. And you may want to add a trailing space to the attribute name to avoid that problem in the future.

I think here you're referring to an attribute being called location and another one being called Location, which is different to the problem I've highlighted.

I look forward to UR preventing the problem I've described. For a long time I've been aware of the Date Modified value of items changing for apparently no reason. I use Date Modified a lot in standard searches that I run and the random changing of this value makes it very much harder to quickly find the information I'm looking for.