Quote:
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.
Quote:
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.