[rt-users] Problem with categories in custom fields

Tue Apr 1 14:25:07 EDT 2008

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 at 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
> >> _______________________________________________
> >> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> >>
> >> Community help: http://wiki.bestpractical.com
> >> Commercial support: sales at bestpractical.com
> >>
> >>
> >> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> >> Buy a copy at http://rtbook.bestpractical.com
> >>
> > _______________________________________________
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> >
> > Community help: http://wiki.bestpractical.com
> > Commercial support: sales at 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.
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20080401/b7ff4baf/attachment.htm>