Categories are based on... How to handle the same value for multiple parent categories

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.

  • 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

We have a similar setup, and I’m afraid there isn’t much you can change
about it (to my knowledge at least).

We’ve made it look like this: (CF names)

  • Item A
    • Item B
      • Item C

When it comes to the search builder you’ll see duplicate values, but if you
search on Item C with value password (that’s maybe listed three times) then
it will show the content of all tickets containing the value password for
Item C.

The search builder simply checks for the string, if it matches then it will
give you the results. If you want to make sure it shows the correct tickets
then you’ll have to combine the Item C value password with an Item A and/or
Item B which will result in a specific result.

Either way, you don’t have to worry about the duplicates the result will be
the same regardless of which duplicate you select.

Hope this helps.

– Bart2011/11/11 Jim Lesinski jim.lesinski@gmail.com

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.

  • 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


RT Training Sessions (http://bestpractical.com/services/training.html)

  • Barcelona, Spain — November 28 & 29, 2011

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.

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@bestpractical.comwrote:

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


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

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

- <&|/l&>(no value) % while (my $value = $values->Next) { % unless ($seen{$value->Name}){ # Jim Lesinski <%$value->Name%> % $seen{$value->Name} = 1; # Jim Lesinski % } # Jim Lesinski % } % } % else { % }On Mon, Nov 14, 2011 at 2:09 PM, Jim Lesinski 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@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


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

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@gmail.com]
Sent: Monday, November 14, 2011 07:06 PM
To: rt-users@lists.bestpractical.com rt-users@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

- <&|/l&>(no value) % while (my $value = $values->Next) { % unless ($seen{$value->Name}){ # Jim Lesinski <%$value->Name%> % $seen{$value->Name} = 1; # Jim Lesinski % } # Jim Lesinski % } % } % else { % }

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.

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
jnarins@seniorbridge.com
seniorbridge.comhttp://www.seniorbridge.com/

[http://www.seniorbridge.com/images/seniorbridgedisclaimerTAG.gif]

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

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 :slight_smile:

Thanks,
Jim LesinskiOn Nov 14, 2011, at 7:10 PM, Josh Narins jnarins@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@gmail.com]
Sent: Monday, November 14, 2011 07:06 PM
To: rt-users@lists.bestpractical.com rt-users@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

- <&|/l&>(no value) % while (my $value = $values->Next) { % unless ($seen{$value->Name}){ # Jim Lesinski <%$value->Name%> % $seen{$value->Name} = 1; # Jim Lesinski % } # Jim Lesinski % } % } % else { % }

On Mon, Nov 14, 2011 at 2:09 PM, Jim Lesinski jim.lesinski@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@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
SeniorBridge

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

The array of names is get-at-able with "keys %seen"From: Jim Lesinski [mailto:jim.lesinski@gmail.com]
Sent: Monday, November 14, 2011 08:19 PM
To: Josh Narins
Cc: rt-users@lists.bestpractical.com rt-users@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 :slight_smile:

Thanks,
Jim Lesinski

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@gmail.com]
Sent: Monday, November 14, 2011 07:06 PM
To: rt-users@lists.bestpractical.commailto:rt-users@lists.bestpractical.com <rt-users@lists.bestpractical.commailto:rt-users@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

- <&|/l&>(no value) % while (my $value = $values->Next) { % unless ($seen{$value->Name}){ # Jim Lesinski <%$value->Name%> % $seen{$value->Name} = 1; # Jim Lesinski % } # Jim Lesinski % } % } % else { % }

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.

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
jnarins@seniorbridge.commailto:jnarins@seniorbridge.com
seniorbridge.comhttp://www.seniorbridge.com/

[http://www.seniorbridge.com/images/seniorbridgedisclaimerTAG.gif]

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

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 jnarins@seniorbridge.comwrote:

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

From: Jim Lesinski [mailto:jim.lesinski@gmail.com]
Sent: Monday, November 14, 2011 08:19 PM
To: Josh Narins
Cc: rt-users@lists.bestpractical.com rt-users@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 :slight_smile:

Thanks,
Jim Lesinski

On Nov 14, 2011, at 7:10 PM, Josh Narins jnarins@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@gmail.com]
Sent: Monday, November 14, 2011 07:06 PM
To: rt-users@lists.bestpractical.com rt-users@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

- <&|/l&>(no value) % while (my $value = $values->Next) { % unless ($seen{$value->Name}){ # Jim Lesinski <%$value->Name%> % $seen{$value->Name} = 1; # Jim Lesinski % } # Jim Lesinski % } % } % else { % }

On Mon, Nov 14, 2011 at 2:09 PM, Jim Lesinski jim.lesinski@gmail.comwrote:

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@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
SeniorBridge

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