RT 3.4.2 custom fields defaulting to value '1'

RT Users
1

After upgrading RT from 3.4.1 to 3.4.2, I’m finding that “enter one
value” and “select one value” custom fields are defaulting to a value
of ‘1’ (instead of empty). For example, I have a "select one value"
transaction custom-field called ‘severity’, with values: ‘normal’,
‘urgent’, or ‘(no value)’. When ‘(no value)’ is selected, and the
transaction is saved, the transaction displays with a severity of
’1’ (which is obviously bogus).

If the field is actually set (eg, I choose ‘normal’), then it works
properly – there seems to only be a problem when the field is not set.

Has anyone else observed this issue?

Thank you.

  • Jason Parsons
2

After upgrading RT from 3.4.1 to 3.4.2, I’m finding that “enter one
value” and “select one value” custom fields are defaulting to a
value of ‘1’ (instead of empty). For example, I have a “select one
value” transaction custom-field called ‘severity’, with values:
‘normal’, ‘urgent’, or ‘(no value)’. When ‘(no value)’ is
selected, and the transaction is saved, the transaction displays
with a severity of ‘1’ (which is obviously bogus).

With a bit more debugging, it does appear that this is a problem on
the update side. Saving a note from Update.html without touching the
custom fields yields these sql queries:

INSERT INTO ObjectCustomFieldValues (ContentType, LargeContent,
CustomField, Creator, ObjectId, LastUpdatedBy, Disabled, Created,
Content, ContentEncoding, LastUpdated, ObjectType) VALUES (NULL,
NULL, ‘1’, ‘94’, ‘10568’, ‘94’, ‘0’, ‘2005-08-04 02:31:30’, ‘1’, ‘’,
‘2005-08-04 02:31:30’, ‘RT::Transaction’)

INSERT INTO ObjectCustomFieldValues (ContentType, LargeContent,
CustomField, Creator, ObjectId, LastUpdatedBy, Disabled, Created,
Content, ContentEncoding, LastUpdated, ObjectType) VALUES (NULL,
NULL, ‘2’, ‘94’, ‘10568’, ‘94’, ‘0’, ‘2005-08-04 02:31:30’, ‘1’, ‘’,
‘2005-08-04 02:31:30’, ‘RT::Transaction’)

Note that ‘Content’ is being set to ‘1’.

I haven’t been able to track down where this is happening.

  • Jason Parsons
3

After upgrading RT from 3.4.1 to 3.4.2, I’m finding that “enter one
value” and “select one value” custom fields are defaulting to a
value of ‘1’ (instead of empty). For example, I have a “select one
value” transaction custom-field called ‘severity’, with values:
‘normal’, ‘urgent’, or ‘(no value)’. When ‘(no value)’ is
selected, and the transaction is saved, the transaction displays
with a severity of ‘1’ (which is obviously bogus).

This bug should be fixed in the forthcoming RT 3.4.3. Try 3.4.3
release candidate 2 and let us know if this bug still exists.

–dave
Code Monkey, Best Practical Solutions
David Glasser | glasser@bestpractical.com

4

After upgrading RT from 3.4.1 to 3.4.2, I’m finding that “enter
one value” and “select one value” custom fields are defaulting to
a value of ‘1’ (instead of empty).

This bug should be fixed in the forthcoming RT 3.4.3. Try 3.4.3
release candidate 2 and let us know if this bug still exists.

Thank you. Is it safe to DELETE FROM ObjectCustomFieldValues the
bogus entries? A quick review seems to suggest that it would be safe
to selectively drop rows from ObjectCustomFieldValues, but it would
be nice to know if this will create any inconsistencies.

  • Jason Parsons
5

This bug should be fixed in the forthcoming RT 3.4.3. Try 3.4.3
release candidate 2 and let us know if this bug still exists.

3.4.3 did resolve this problem.

Is it safe to DELETE FROM ObjectCustomFieldValues the bogus entries?
A quick review seems to suggest that it would be safe to selectively
drop rows from ObjectCustomFieldValues, but it would be nice to know
if this will create any inconsistencies.

Thank you.

  • Jason Parsons
6

This bug should be fixed in the forthcoming RT 3.4.3. Try 3.4.3
release candidate 2 and let us know if this bug still exists.

3.4.3 did resolve this problem.

Is it safe to DELETE FROM ObjectCustomFieldValues the bogus entries?
A quick review seems to suggest that it would be safe to selectively
drop rows from ObjectCustomFieldValues, but it would be nice to know
if this will create any inconsistencies.

The only other places that OCFVs will be referenced is in the
Transactions table. (So it can say “value foo added”)