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

2011-11-16 Thread Jim Lesinski
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 wrote:

> The array of names is get-at-able with "keys %seen"
>
>
>  *From*: Jim Lesinski [mailto:jim.lesin...@gmail.com]
> *Sent*: Monday, November 14, 2011 08:19 PM
> *To*: Josh Narins
> *Cc*: 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 :)
>
> Thanks,
> Jim Lesinski
>
> On Nov 14, 2011, at 7:10 PM, Josh Narins  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.lesin...@gmail.com]
> *Sent*: Monday, November 14, 2011 07:06 PM
> *To*: 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 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 <
&g

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

2011-11-14 Thread Josh Narins
The array of names is get-at-able with "keys %seen"


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

Thanks,
Jim Lesinski

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

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

2011-11-14 Thread Jim Lesinski
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  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.lesin...@gmail.com] 
> Sent: Monday, November 14, 2011 07:06 PM
> To: 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  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  
> 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
> >* softwarena

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

2011-11-14 Thread Josh Narins
 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.lesin...@gmail.com]
Sent: Monday, November 14, 2011 07:06 PM
To: 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 
mailto:jim.lesin...@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 
mailto:falc...@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
jnar...@seniorbridge.com
seniorbridge.com<http://www.seniorbridge.com/>

[http://www.seniorbridge.com/images/seniorbridgedi

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

2011-11-14 Thread Jim Lesinski
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  > 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
>>
>
>

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

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

2011-11-14 Thread Jim Lesinski
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
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
>

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

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

2011-11-14 Thread Kevin Falcone
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



pgpVRUwN62GbI.pgp
Description: PGP signature

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

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

2011-11-14 Thread Bart
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.

-- Bart


2011/11/11 Jim Lesinski 

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

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

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

2011-11-11 Thread Jim Lesinski
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