[rt-users] Categories are based on... How to handle the same value for multiple parent categories

Josh Narins jnarins at seniorbridge.com
Mon Nov 14 20:28:29 EST 2011

The array of names is get-at-able with "keys %seen"

From: Jim Lesinski [mailto:jim.lesinski at gmail.com]
Sent: Monday, November 14, 2011 08:19 PM
To: Josh Narins
Cc: rt-users at lists.bestpractical.com <rt-users at lists.bestpractical.com>
Subject: Re: [rt-users] Categories are based on... How to handle the same value for multiple parent categories

Right, but I think then I'd have to build an array of names and then iterate through that second array to output the option values. I am not sure which would be more efficient but there is probably a better way to do it.

Either way the result of the code would be ideally added to the base code, but not necessarily my personal code :)

Jim Lesinski

On Nov 14, 2011, at 7:10 PM, Josh Narins <jnarins at seniorbridge.com<mailto:jnarins at seniorbridge.com>> wrote:

 I don't know anything about your patch, but with Perl, it is more common to write something like...

next if $seen{ $value->Name }++;

From: Jim Lesinski [mailto:jim.lesinski at gmail.com]
Sent: Monday, November 14, 2011 07:06 PM
To: rt-users at lists.bestpractical.com<mailto:rt-users at lists.bestpractical.com> <rt-users at lists.bestpractical.com<mailto:rt-users at lists.bestpractical.com>>
Subject: Re: [rt-users] Categories are based on... How to handle the same value for multiple parent categories

I had some time after work to code up a possible solution for the searchbuilder. I am new to perl so feel free to correct me.

Below is a snippet of code from /html/Elements/SelectCustomFieldValue, starting at line 48. I have added my name after the lines I added to make the search builder drop down show only unique string values. It would be super cool if this made it into the base code.

% $m->callback( Name => $Name, CustomField => $CustomField );
% if ($CustomField->Type =~ /Select/i) {
% my $values = $CustomField->Values;

% my %seen = ();    # Jim Lesinski

<select name="<%$Name%>">
<option value="" selected="selected">-</option>
<option value="NULL"><&|/l&>(no value)</&></option>
% while (my $value = $values->Next) {
%    unless ($seen{$value->Name}){    # Jim Lesinski
       <option value="<%$value->Name%>"><%$value->Name%></option>
%      $seen{$value->Name} = 1;    # Jim Lesinski
%    }    # Jim Lesinski
% }
% }
% else {
<input name="<%$Name%>" size="20" />
% }

On Mon, Nov 14, 2011 at 2:09 PM, Jim Lesinski <jim.lesinski at gmail.com<mailto:jim.lesinski at gmail.com>> wrote:
I wouldn't think that the searchbuilder would show the same string value though if you have the value occurring multiple times based on a parent field. In my example below the value "softwarename1.1" will show up in the searchbuilder each time I have entered it for that field.

What I was suggesting is that one way to handle this would be to make the searchbuilder page only add a string value if that string value doesn't exist in the values already. That seems like the simplest was to avoid the same value from showing up several times in the searchbuilder.

Right now what happens is, you end up with 4 "Password Reset" Values in the example below. This also would create 4 "Password Reset" in the searchbuilder dropdown, which works because the search is based on the String value and not the ID of the record.

* Active Directory
      * Password Reset
* TimeSheet
      * Password Reset
* TestDomain
      * Password Reset
* Whatever
      * Password Reset

Just a suggestion... but an excellent way to handle it may be to add functionality to the "Categories are based on" drop down so that you select the parent field first, and then select each value that the current value is visible for. This would let you have a more flexible relationship for building the hierarchy.

Then you could select Field1 as the Parent for Field2, but also specify that Field2.Value1 would be an option when you select Field1.Value1, Field1.Value3, Field1.Value4, Field1.Value7 - etc.

On Mon, Nov 14, 2011 at 10:53 AM, Kevin Falcone <falcone at bestpractical.com<mailto:falcone at bestpractical.com>> wrote:
On Fri, Nov 11, 2011 at 03:01:18PM -0500, Jim Lesinski wrote:
>    Hi,
>    In request tracker, how would you recommend setting up your dependent drop down lists that
>    have a consistent drop down value for multiple parent values? Below, under the 1st level
>    Administration value, I show an example of what I am asking about.

If you use the 'Categories are based on' feature in later 3.8 and 4.0
you'll get much better search options than typing in the Category box.

>      * Hardware
>           * item1.1
>           * item1.2
>           * item1.3
>      * Software
>           * item2.1
>           * item2.2
>           * item2.3
>      * Administration
>           * password reset
>                * softwarename1.1
>                * softwarename1.2
>                * softwarename1.3
>           * profile update
>                * softwarename1.1
>                * softwarename1.2
>                * softwarename1.3
>    I was able to set up the outline above by using the built in "categories are based on" option
>    for drop down lists and entering the value one time for each parent value. The only thing that
>    I see as a possible issue with doing this is that the search builder then shows the drop down
>    text value multiple times. Maybe just a bug or improvement that could be made in the
>    searchbuilder (ie; only show DISTINCT dropdownlist value)? Or should I handle this a different
>    way?
>    Either way I would appreciate your insight.
>    Thanks,
>    Jim


Josh Narins
Director of Application Development

845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Fax: (212) 994-4260
Mobile: (917) 488-6248
jnarins at seniorbridge.com<mailto:jnarins at seniorbridge.com>


SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.--------
> RT Training Sessions (http://bestpractical.com/services/training.html)
> *  Barcelona, Spain ? November 28 & 29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain — November 28 & 29, 2011

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111114/02582ef7/attachment.htm>

More information about the rt-users mailing list