RT Version: 3.6.3
Apache : 2.0.59
Perl: 5.8.5
MySQL: 4.0.20
We have a CustomField called Department. We use it do reporting on
which departments had work done for them and how much time so that later
we can charge them for that time. The problem is when the Names are
changed via the RT UI – the ObjectCustomFieldValues.Content values are
not modified. If the names were changed on the first of the month and
someone tries to pull a report from last month (or any previous month
for that matter) they will get only the Departments that haven’t had
their names changed, obviously.
I have made the updates via the MySQL CLI using the same user/pass as RT
is configured to use, so it’s not a database permissions issue.
I’ve looked through the Apache error logs and they are pretty bare…
infact there isn’t even an entry from today. If more information is
needed please let me know and I will provide it promptly.
Thank you.
Sean Edge
Consultant
MTV Networks
This email (including any attachments) is for its intended-recipient’s
use only. This email may contain information that is confidential or
privileged. If you received this email in error, please immediately
advise the sender by replying to this email and then delete this message
from your system. For further information and disclaimers that apply to
this email, see [http://www.viacom.com/email_disclaimer.jhtml].
Yeah we had to put a process in place to manually update
“ObjectCustomFieldValues” with that in “CustomFieldValues”.
[mailto:rt-devel-bounces@lists.bestpractical.com] On Behalf Of Edge,
SeanSent: Thursday, June 14, 2007 1:48 PM
To: rt-devel@lists.bestpractical.com
Subject: [Rt-devel] Bug: ObjectCustomFieldValues.Content not being
updated
RT Version: 3.6.3
Apache : 2.0.59
Perl: 5.8.5
MySQL: 4.0.20
We have a CustomField called Department. We use it do reporting on
which departments had work done for them and how much time so that later
we can charge them for that time. The problem is when the Names are
changed via the RT UI – the ObjectCustomFieldValues.Content values are
not modified. If the names were changed on the first of the month and
someone tries to pull a report from last month (or any previous month
for that matter) they will get only the Departments that haven’t had
their names changed, obviously.
I have made the updates via the MySQL CLI using the same user/pass as RT
is configured to use, so it’s not a database permissions issue.
I’ve looked through the Apache error logs and they are pretty bare…
infact there isn’t even an entry from today. If more information is
needed please let me know and I will provide it promptly.
Thank you.
Sean Edge
Consultant
MTV Networks
This email (including any attachments) is for its intended-recipient’s
use only. This email may contain information that is confidential or
privileged. If you received this email in error, please immediately
advise the sender by replying to this email and then delete this message
from your system. For further information and disclaimers that apply to
this email, see [http://www.viacom.com/email_disclaimer.jhtml].
We have a CustomField called Department. We use it do reporting on
which departments had work done for them and how much time so that
later we can charge them for that time. The problem is when the
Names are changed via the RT UI – the
ObjectCustomFieldValues.Content values are not modified. If the
names were changed on the first of the month and someone tries to
pull a report from last month (or any previous month for that
matter) they will get only the Departments that haven’t had their
names changed, obviously.
RT’s custom field values are stored by value, rather than by
reference. (If we did it by reference, you’d change history when
updating fields). Perhaps you want to Bulk Update when you rename
department names?
Jesse
PGP.sig (186 Bytes)
This is design feature. There is no code keep ObjectCustomFieldValues
in sync with the current CustomFieldValues. This allows you to retire
old CustomFieldValues without impacting Tickets. This is necessary for us.
I do see the value of on modifying a specific CFV changing the
corresponding OCFVs though.
Joby Walker
C&C SSG, University of Washington
Edge, Sean wrote:
Hi,
i think from user point of view this is a bug.
For a user it is very confusing if you have value a, b, c, d in custom field dropdown list and ticket custom field value is z.
As suggest bei jesse you could make an bulk update. But if you have script actions on custom field value change you get problems with this.
So custom field values should be stored by reference.
As mentioned by Joby Walker maybe the function of the object custom field value checkbox (check box to delete) should be changed from delete to disable, so disabled values are no longer visible in the dropdown list.
Chris