[rt-users] Problem with categories in custom fields
theillien at yahoo.com
Thu Sep 20 12:49:16 EDT 2007
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:
> 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?
> On 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:
>>>> I had a user report a problem with categories in custom fields
>>>> 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
>>>> 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.
>>>> When updating an existing ticket the name value gets updated,
>>>> but the
>>>> category does not get set and remains as just "-". The following
>>>> 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 184.108.40.206 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?
>>> Keep up with me and what I'm up to: http://theillien.blogspot.com
>>> 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
>> 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
More information about the rt-users