Just a final note on this - After doing some more investigation, it seems that while Request Tracker doesn't restrict you from creating 2 (or more) drop down values at the same level with the same string value, it also does't use the record ID to filter subsequent drop downs either. - it uses the string value to filter subsequent values. This means if you have 3 fields that filter you end up with a mess of child values that may not relate to the parent value anyway.
So it seems that adding a prefix or suffix to the text of the drop down value is the only way to achieve what I had wanted. On Mon, Nov 14, 2011 at 8:28 PM, Josh Narins <[email protected]>wrote: > The array of names is get-at-able with "keys %seen" > > > *From*: Jim Lesinski [mailto:[email protected]] > *Sent*: Monday, November 14, 2011 08:19 PM > *To*: Josh Narins > *Cc*: [email protected] <[email protected]> > *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 :) > > Thanks, > Jim Lesinski > > On Nov 14, 2011, at 7:10 PM, Josh Narins <[email protected]> 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:[email protected]] > *Sent*: Monday, November 14, 2011 07:06 PM > *To*: [email protected] <[email protected]> > *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 > % } > </select> > % } > % else { > <input name="<%$Name%>" size="20" /> > % } > > > On Mon, Nov 14, 2011 at 2:09 PM, Jim Lesinski <[email protected]>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 < >> [email protected]> 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 >>> SeniorBridge >>> >>> 845 Third Ave >>> 7th Floor >>> New York, NY 10022 >>> Tel: (212) 994-6194 >>> Fax: (212) 994-4260 >>> Mobile: (917) 488-6248 >>> [email protected] >>> seniorbridge.com <http://www.seniorbridge.com/> >>> >>> [image: SeniorBridge] >>> >>> >>> ------------------------------ >>> *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 >>> >> >> >
-------- RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 & 29, 2011
