[rt-users] multi-level keyword selections

Beachey, Kendric Kendric.Beachey at garmin.com
Thu Apr 25 09:14:12 EDT 2002


From: Eric Goodman [mailto:ericg at cats.ucsc.edu]
> I think it is very important to clarify in the keywords discussion 
> this difference between keywords containing a slash ("Priority/High", 
> "Priority/Medium", "Priority/Low") -- which appear to almost always 
> be errors -- and a keyword hierarchy (as in "Priority" == parent of 
> "High", "Medium" and "Low"). Perhaps even go so far as to disallow 
> the "/" in the keywords.

I would like to tangentize just a bit here to say that keywords in a
hierarchy such as Eric mentions don't seem to work as expected (or, at
least, as expected by me) in the Search portion of RT.

I messed with hierarchical keywords for a bit, but ended up scrapping them
because they showed up weird in the search criteria.  For a keyword set like
this...

foo
bar
baz

...with child keywords like this...

foo/a
foo/b
foo/c
bar/a
bar/b
bar/c
baz/a
baz/b
baz/c

...if I searched on keywords foo/a and bar/a, the criteria panel would show
stuff like...

KeywordSelection Blah = a [delete]
KeywordSelection Blah = a [delete]

One is actually foo/a and one is actually bar/a.  Can't tell which is which.

Has anyone else run into this?  Do I seem to be doing something wrong?

While I'm at it, another peeve that made me drop hierarchical keywords was
that in the above example, even though there are three sub-keywords called
"a", they all had to be defined separately.  It would be really cool if I
could just define two sets ({foo,bar,baz} and {a,b,c}) and then just say
that the second set was a sublevel of the first.  I'm probably just thinking
up the wrong tree with this whole train of thought, but it seemed to make
sense for what the user wanted to do.

Any insight from hierarchical keyword users would be appreciated.

--
Kendric Beachey




More information about the rt-users mailing list