Problem with categories in custom fields

RT Users
1

Greetings,
I had a user report a problem with categories in custom fields recently
that I have been unable to solve. I have looked through the wiki, the
bugs listed in rt, and the mailing lists and I have been unable to find
a solution to my problem.

We have several custom fields that have been created as a type of

“Select one value”, with a validation of “Mandatory”. The problem is
that when a user creates a ticket, or updates an existing ticket, the
category that is associated with the name is not saved. As an example if
you created a custom filed with 2 values, each with a different name and
category, only the name is saved with the ticket. The category field
will be left as “-”.

This is causing a problem as some times we have the same name in

different categories (we have the same components within different
products and we use the custom fields to indicate which component and
product the ticket is for).

I have been able to reproduce on both RT 3.6.1 which we run in

production and on RT 3.6.4 which we run in test. I have noticed that
when creating a new ticket in RT 3.6.4 with a custom field of this type
the following error is being logged.

Jul 18 15:25:32 hostname RT: Use of uninitialized value in string eq at
/usr/local/rt/lib/RT/Record.pm line 1686.
(/usr/local/rt/lib/RT/Record.pm:1686)

When updating an existing ticket the name value gets updated, but the

category does not get set and remains as just “-”. The following message
appears in the “Results” section at the top of the page after clicking
“Save Changes” in both RT 3.6.1 and RT 3.6.4.

User asked for an unknown update type for custom field
ChetTestSelectSingleValue for RT::Ticket object #6

As mentioned I have seen this problem in both RT 3.6.1 and RT 3.6.4. We
are running on RHEL 3 Update 8 with apache 1.3.31, Perl 5.8.4, mod_perl
1.29, and mysql 4.0.18.

Has anyone seen this before and/or know if there is something else I
need to do to enable this functionality?

Chet Burgess
Senior Unix Systems Administrator
Web Systems, Ticketmaster
chet.burgess@ticketmaster.com
310-360-3251

signature.asc (249 Bytes)

2

Chet Burgess wrote:

Greetings,
I had a user report a problem with categories in custom fields recently
that I have been unable to solve. I have looked through the wiki, the
bugs listed in rt, and the mailing lists and I have been unable to find
a solution to my problem.

We have several custom fields that have been created as a type of
“Select one value”, with a validation of “Mandatory”. The problem is
that when a user creates a ticket, or updates an existing ticket, the
category that is associated with the name is not saved. As an example if
you created a custom filed with 2 values, each with a different name and
category, only the name is saved with the ticket. The category field
will be left as “-”.

This is causing a problem as some times we have the same name in
different categories (we have the same components within different
products and we use the custom fields to indicate which component and
product the ticket is for).

I have been able to reproduce on both RT 3.6.1 which we run in
production and on RT 3.6.4 which we run in test. I have noticed that
when creating a new ticket in RT 3.6.4 with a custom field of this type
the following error is being logged.

Jul 18 15:25:32 hostname RT: Use of uninitialized value in string eq at
/usr/local/rt/lib/RT/Record.pm line 1686.
(/usr/local/rt/lib/RT/Record.pm:1686)

When updating an existing ticket the name value gets updated, but the
category does not get set and remains as just “-”. The following message
appears in the “Results” section at the top of the page after clicking
“Save Changes” in both RT 3.6.1 and RT 3.6.4.

User asked for an unknown update type for custom field
ChetTestSelectSingleValue for RT::Ticket object #6

As mentioned I have seen this problem in both RT 3.6.1 and RT 3.6.4. We
are running on RHEL 3 Update 8 with apache 1.3.31, Perl 5.8.4, mod_perl
1.29, and mysql 4.0.18.

Has anyone seen this before and/or know if there is something else I
need to do to enable this functionality?

Did you ever get any input on this? I actually just ran into the same issue
verified using both IE and Firefox on Windows and Linux. I have a couple other
issues with it as well also on both 3.6.1 and 3.6.4. I’m running Fedora Core 5
and mysql 5.0.0.2 though.

First, when using Firefox, selecting a category filters the second drop down
(the one with the actual values) to just the values of that particular category
(which I suspect to be the intended behaviour). However, in IE, this is not
the case. Selecting the category does not run the filter on the second drop
down. All categories and values are listed regardless of the category selected
in the first drop down.

Second, once a value has been assigned to a category, it is not possible to
remove it by simply blanking out the category field. When testing this feature,
I found that in order to remove the category from an item, I had to delete the
item and then recreate it. After doing this, it would appear in the drop down
list as not being associated with any category while all others which have not
been changed still were. Attempting to simply set the category as blank
resulted in it being repopulated with the category after hitting submit.

Are there plans on fixing this with the next release?

Mathew
Keep up with me and what I’m up to: http://theillien.blogspot.com

3

Does anyone have any input on this?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

4

Anyone have any input on this?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

5

Mathew,

Yes, we are experiencing the same problems as you are with Category. We

use firefox, so we do get the drop-down filtering effect, but the
category is never saved (we get the same error message) and we cannot
remove them, now that they are there. We will probably run some SQL
against the DataBase to make all categories blank again and keep them
that way until the problem gets solved. Have you heard any estimates on
when the problem will be resolved?

Kenn
LBNLOn 9/20/2007 6:49 AM, Mathew Snyder wrote:

Anyone have any input on this?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

Chet Burgess wrote:

Greetings,
I had a user report a problem with categories in custom fields recently
that I have been unable to solve. I have looked through the wiki, the
bugs listed in rt, and the mailing lists and I have been unable to find
a solution to my problem.

We have several custom fields that have been created as a type of
“Select one value”, with a validation of “Mandatory”. The problem is
that when a user creates a ticket, or updates an existing ticket, the
category that is associated with the name is not saved. As an example if
you created a custom filed with 2 values, each with a different name and
category, only the name is saved with the ticket. The category field
will be left as “-”.

This is causing a problem as some times we have the same name in
different categories (we have the same components within different
products and we use the custom fields to indicate which component and
product the ticket is for).

I have been able to reproduce on both RT 3.6.1 which we run in
production and on RT 3.6.4 which we run in test. I have noticed that
when creating a new ticket in RT 3.6.4 with a custom field of this type
the following error is being logged.

Jul 18 15:25:32 hostname RT: Use of uninitialized value in string eq at
/usr/local/rt/lib/RT/Record.pm line 1686.
(/usr/local/rt/lib/RT/Record.pm:1686)

When updating an existing ticket the name value gets updated, but the
category does not get set and remains as just “-”. The following message
appears in the “Results” section at the top of the page after clicking
“Save Changes” in both RT 3.6.1 and RT 3.6.4.

User asked for an unknown update type for custom field
ChetTestSelectSingleValue for RT::Ticket object #6

As mentioned I have seen this problem in both RT 3.6.1 and RT 3.6.4. We
are running on RHEL 3 Update 8 with apache 1.3.31, Perl 5.8.4, mod_perl
1.29, and mysql 4.0.18.

Has anyone seen this before and/or know if there is something else I
need to do to enable this functionality?

Did you ever get any input on this? I actually just ran into the same issue
verified using both IE and Firefox on Windows and Linux. I have a couple other
issues with it as well also on both 3.6.1 and 3.6.4. I’m running Fedora Core 5
and mysql 5.0.0.2 though.

First, when using Firefox, selecting a category filters the second drop down
(the one with the actual values) to just the values of that particular category
(which I suspect to be the intended behaviour). However, in IE, this is not
the case. Selecting the category does not run the filter on the second drop
down. All categories and values are listed regardless of the category selected
in the first drop down.

Second, once a value has been assigned to a category, it is not possible to
remove it by simply blanking out the category field. When testing this feature,
I found that in order to remove the category from an item, I had to delete the
item and then recreate it. After doing this, it would appear in the drop down
list as not being associated with any category while all others which have not
been changed still were. Attempting to simply set the category as blank
resulted in it being repopulated with the category after hitting submit.

Are there plans on fixing this with the next release?

Mathew
Keep up with me and what I’m up to: http://theillien.blogspot.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

6

No but I did submit it as a bug this morning. I imagine I’ll hear something
through there in the next week or so.

Keep up with me and what I’m up to: http://theillien.blogspot.com

Kenneth Crocker wrote:

7

Have you had any further input on this? I am experiencing the same thing in
IE. Do you have a workaround?

Thanks,
Laura

Mathew Snyder-3 wrote:

Anyone have any input on this?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

Chet Burgess wrote:

Greetings,
I had a user report a problem with categories in custom fields recently
that I have been unable to solve. I have looked through the wiki, the
bugs listed in rt, and the mailing lists and I have been unable to find
a solution to my problem.

We have several custom fields that have been created as a type of
“Select one value”, with a validation of “Mandatory”. The problem is
that when a user creates a ticket, or updates an existing ticket, the
category that is associated with the name is not saved. As an example if
you created a custom filed with 2 values, each with a different name and
category, only the name is saved with the ticket. The category field
will be left as “-”.

This is causing a problem as some times we have the same name in
different categories (we have the same components within different
products and we use the custom fields to indicate which component and
product the ticket is for).

I have been able to reproduce on both RT 3.6.1 which we run in
production and on RT 3.6.4 which we run in test. I have noticed that
when creating a new ticket in RT 3.6.4 with a custom field of this type
the following error is being logged.

Jul 18 15:25:32 hostname RT: Use of uninitialized value in string eq at
/usr/local/rt/lib/RT/Record.pm line 1686.
(/usr/local/rt/lib/RT/Record.pm:1686)

When updating an existing ticket the name value gets updated, but the
category does not get set and remains as just “-”. The following message
appears in the “Results” section at the top of the page after clicking
“Save Changes” in both RT 3.6.1 and RT 3.6.4.

User asked for an unknown update type for custom field
ChetTestSelectSingleValue for RT::Ticket object #6

As mentioned I have seen this problem in both RT 3.6.1 and RT 3.6.4. We
are running on RHEL 3 Update 8 with apache 1.3.31, Perl 5.8.4, mod_perl
1.29, and mysql 4.0.18.

Has anyone seen this before and/or know if there is something else I
need to do to enable this functionality?

Did you ever get any input on this? I actually just ran into the same
issue
verified using both IE and Firefox on Windows and Linux. I have a couple
other
issues with it as well also on both 3.6.1 and 3.6.4. I’m running Fedora
Core 5
and mysql 5.0.0.2 though.

First, when using Firefox, selecting a category filters the second drop
down
(the one with the actual values) to just the values of that particular
category
(which I suspect to be the intended behaviour). However, in IE, this is
not
the case. Selecting the category does not run the filter on the second
drop
down. All categories and values are listed regardless of the category
selected
in the first drop down.

Second, once a value has been assigned to a category, it is not possible
to
remove it by simply blanking out the category field. When testing this
feature,
I found that in order to remove the category from an item, I had to
delete the
item and then recreate it. After doing this, it would appear in the drop
down
list as not being associated with any category while all others which
have not
been changed still were. Attempting to simply set the category as blank
resulted in it being repopulated with the category after hitting submit.

Are there plans on fixing this with the next release?

Mathew
Keep up with me and what I’m up to: http://theillien.blogspot.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

View this message in context: http://www.nabble.com/Problem-with-categories-in-custom-fields-tp11716848p16420562.html

8

I find the implementation of categories lacking. Don’t use them if the
values are not unique across all categories.On Tue, Apr 1, 2008 at 2:21 PM, lgrella lgrella@acquiremedia.com wrote:

Have you had any further input on this? I am experiencing the same thing
in
IE. Do you have a workaround?

Thanks,
Laura

Mathew Snyder-3 wrote:

Anyone have any input on this?

Keep up with me and what I’m up to: http://theillien.blogspot.com

Mathew Snyder wrote:

Chet Burgess wrote:

Greetings,
I had a user report a problem with categories in custom fields
recently
that I have been unable to solve. I have looked through the wiki, the
bugs listed in rt, and the mailing lists and I have been unable to
find
a solution to my problem.

We have several custom fields that have been created as a type of

“Select one value”, with a validation of “Mandatory”. The problem is
that when a user creates a ticket, or updates an existing ticket, the
category that is associated with the name is not saved. As an example
if
you created a custom filed with 2 values, each with a different name
and
category, only the name is saved with the ticket. The category field
will be left as “-”.

This is causing a problem as some times we have the same name in

different categories (we have the same components within different
products and we use the custom fields to indicate which component and
product the ticket is for).

I have been able to reproduce on both RT 3.6.1 which we run in

production and on RT 3.6.4 which we run in test. I have noticed that
when creating a new ticket in RT 3.6.4 with a custom field of this
type
the following error is being logged.

Jul 18 15:25:32 hostname RT: Use of uninitialized value in string eq
at
/usr/local/rt/lib/RT/Record.pm line 1686.
(/usr/local/rt/lib/RT/Record.pm:1686)

When updating an existing ticket the name value gets updated, but

the

category does not get set and remains as just “-”. The following
message
appears in the “Results” section at the top of the page after clicking
“Save Changes” in both RT 3.6.1 and RT 3.6.4.

User asked for an unknown update type for custom field
ChetTestSelectSingleValue for RT::Ticket object #6

As mentioned I have seen this problem in both RT 3.6.1 and RT 3.6.4.
We
are running on RHEL 3 Update 8 with apache 1.3.31, Perl 5.8.4,
mod_perl
1.29, and mysql 4.0.18.

Has anyone seen this before and/or know if there is something else I
need to do to enable this functionality?

Did you ever get any input on this? I actually just ran into the same
issue
verified using both IE and Firefox on Windows and Linux. I have a
couple
other
issues with it as well also on both 3.6.1 and 3.6.4. I’m running
Fedora
Core 5
and mysql 5.0.0.2 though.

First, when using Firefox, selecting a category filters the second drop
down
(the one with the actual values) to just the values of that particular
category
(which I suspect to be the intended behaviour). However, in IE, this
is
not
the case. Selecting the category does not run the filter on the second
drop
down. All categories and values are listed regardless of the category
selected
in the first drop down.

Second, once a value has been assigned to a category, it is not
possible
to
remove it by simply blanking out the category field. When testing this
feature,
I found that in order to remove the category from an item, I had to
delete the
item and then recreate it. After doing this, it would appear in the
drop
down
list as not being associated with any category while all others which
have not
been changed still were. Attempting to simply set the category as
blank
resulted in it being repopulated with the category after hitting
submit.

Are there plans on fixing this with the next release?

Mathew
Keep up with me and what I’m up to: http://theillien.blogspot.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

–
View this message in context:
http://www.nabble.com/Problem-with-categories-in-custom-fields-tp11716848p16420562.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com