Newbie trouble: keywords don't work

I am trying to make a test rt install for my company’s internal helpdesk
usage and have one problem left of which I can find no other mention:
the keywords feature does not seem to work.

I add keywords as I understand how to do them; for example:

OS/
OS/Linux
OS/Windows
OS/Mac OS X

Then I attach keyword selections to a queue or globally; for example:

Platform - multiple - children of OS/ up to 1 levels deep

The result? Empty select boxes on the keywords page. I can get the
select boxes to kind of work by changing the children of to “-” after
initial creation, but this obviously won’t do the job and it breaks as
soon as I change it back to the correct parent.

I am at a complete loss and any help would be greatly appreciated. The
[hopefully] relevant details for my install are:

RedHat 7.2 server with 2.4.18 kernel
Request Tracker 2.0.13
Perl 5.6.1 built from source
PostgreSQL 7.2.1 database installed from official RPMs

Joe.

Try “up to 0 levels deep” (where 0 means "as many children as possible).

Marc Hedlund
e: marc at precipice dot orgOn Mon, 29 Apr 2002, Joe Baldwin wrote:

I am trying to make a test rt install for my company’s internal helpdesk
usage and have one problem left of which I can find no other mention:
the keywords feature does not seem to work.

I add keywords as I understand how to do them; for example:

OS/
OS/Linux
OS/Windows
OS/Mac OS X

Then I attach keyword selections to a queue or globally; for example:

Platform - multiple - children of OS/ up to 1 levels deep

The result? Empty select boxes on the keywords page. I can get the
select boxes to kind of work by changing the children of to “-” after
initial creation, but this obviously won’t do the job and it breaks as
soon as I change it back to the correct parent.

I am at a complete loss and any help would be greatly appreciated. The
[hopefully] relevant details for my install are:

RedHat 7.2 server with 2.4.18 kernel
Request Tracker 2.0.13
Perl 5.6.1 built from source
PostgreSQL 7.2.1 database installed from official RPMs

Joe.


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Just tried setting levels deep to 0; no luck unfortunately.

Any other suggestions would be welcome.

Joe.

Try “up to 0 levels deep” (where 0 means "as many children as possible).

Marc Hedlund
e: marc at precipice dot org

I am trying to make a test rt install for my company’s internal
helpdesk
usage and have one problem left of which I can find no other mention:
the keywords feature does not seem to work.

I add keywords as I understand how to do them; for example:

OS/
OS/Linux
OS/Windows
OS/Mac OS X

Then I attach keyword selections to a queue or globally; for example:

Platform - multiple - children of OS/ up to 1 levels deep

The result? Empty select boxes on the keywords page. I can get the
select boxes to kind of work by changing the children of to “-” after
initial creation, but this obviously won’t do the job and it breaks as
soon as I change it back to the correct parent.

I am at a complete loss and any help would be greatly appreciated. The
[hopefully] relevant details for my install are:

RedHat 7.2 server with 2.4.18 kernel
Request Tracker 2.0.13
Perl 5.6.1 built from source
PostgreSQL 7.2.1 database installed from official RPMs

Joe.

Are you typing in the ‘/’ after ‘OS’ manually? If so, instead you should
type “OS” as a keyword, hit the “Add” button, then click on the word
"OS" (which is a link now), then add “Linux”, etc.

Marc Hedlund
e: marc at precipice dot orgOn Mon, 29 Apr 2002, Joe Baldwin wrote:

Just tried setting levels deep to 0; no luck unfortunately.

Any other suggestions would be welcome.

Joe.

On Monday, April 29, 2002, at 02:54 PM, Marc Hedlund wrote:

Try “up to 0 levels deep” (where 0 means "as many children as possible).

Marc Hedlund
e: marc at precipice dot org

On Mon, 29 Apr 2002, Joe Baldwin wrote:

I am trying to make a test rt install for my company’s internal
helpdesk
usage and have one problem left of which I can find no other mention:
the keywords feature does not seem to work.

I add keywords as I understand how to do them; for example:

OS/
OS/Linux
OS/Windows
OS/Mac OS X

Then I attach keyword selections to a queue or globally; for example:

Platform - multiple - children of OS/ up to 1 levels deep

The result? Empty select boxes on the keywords page. I can get the
select boxes to kind of work by changing the children of to “-” after
initial creation, but this obviously won’t do the job and it breaks as
soon as I change it back to the correct parent.

I am at a complete loss and any help would be greatly appreciated. The
[hopefully] relevant details for my install are:

RedHat 7.2 server with 2.4.18 kernel
Request Tracker 2.0.13
Perl 5.6.1 built from source
PostgreSQL 7.2.1 database installed from official RPMs

Joe.


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

That was the problem – it works perfectly now. It’s amazing how
difficult a problem can seem to be, then how obvious it becomes once you
learn one simple detail.

Thanks a bunch!

Joe.

Are you typing in the ‘/’ after ‘OS’ manually? If so, instead you
should
type “OS” as a keyword, hit the “Add” button, then click on the word
"OS" (which is a link now), then add “Linux”, etc.

Marc Hedlund
e: marc at precipice dot org

Just tried setting levels deep to 0; no luck unfortunately.

Any other suggestions would be welcome.

Joe.

Given that it seems like every single user who tries to set up keywords
has this problem (I had it myself, but managed to figure it out without
inflicting another request for explanation to the list), just having the
Keywords tutorial doesn’t seem like enough.

Is there any reason the following patch (untested) or something much
like it, shouldn’t be used to prevent newbies from making this classic
mistake?

— old/usr/local/rt2/lib/RT/Keyword.pm Fri Dec 14 14:03:08 2001
+++ /usr/local/rt2/lib/RT/Keyword.pm Thu May 16 12:49:27 2002
@@ -107,6 +107,11 @@
$RT::Logger->err( "can’t yet specify parents by name, sorry: ".
$args{‘Parent’});
return(0,‘Parent must be specified by id’);
}

  • if ( $args{‘Name’} =~ m|/| ) {
  •   $RT::Logger->err( "keyword names cannot contain '/', sorry: ". 
    

$args{‘Name’});

  •   return(0,'Keyword names cannot contain /');
    
  • }

    my $val = $self->SUPER::Create(Name => $args{‘Name’},
    Description => $args{‘Description’},

@alex
mailto:dupuy@sysd.com

+1!

Marc Hedlund
e: marc at precipice dot orgOn Thu, 16 May 2002, Alexander Dupuy wrote:

Given that it seems like every single user who tries to set up keywords
has this problem (I had it myself, but managed to figure it out without
inflicting another request for explanation to the list), just having the
Keywords tutorial doesn’t seem like enough.

Is there any reason the following patch (untested) or something much
like it, shouldn’t be used to prevent newbies from making this classic
mistake?

— old/usr/local/rt2/lib/RT/Keyword.pm Fri Dec 14 14:03:08 2001
+++ /usr/local/rt2/lib/RT/Keyword.pm Thu May 16 12:49:27 2002
@@ -107,6 +107,11 @@
$RT::Logger->err( "can’t yet specify parents by name, sorry: ".
$args{‘Parent’});
return(0,‘Parent must be specified by id’);
}
+

  • if ( $args{‘Name’} =~ m|/| ) {
  •   $RT::Logger->err( "keyword names cannot contain '/', sorry: ". 
    

$args{‘Name’});

  •   return(0,'Keyword names cannot contain /');
    
  • }

    my $val = $self->SUPER::Create(Name => $args{‘Name’},
    Description => $args{‘Description’},

@alex

mailto:dupuy@sysd.com


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Given that it seems like every single user who tries to set up keywords
has this problem (I had it myself, but managed to figure it out without
inflicting another request for explanation to the list), just having the
Keywords tutorial doesn’t seem like enough.

Is there any reason the following patch (untested) or something much
like it, shouldn’t be used to prevent newbies from making this classic
mistake?

Because you’re a newbie for a couple weeks, and an experienced user
for years. :slight_smile:

You might have, say,

Shirts
Size
M
L
Color
Solid black
Red/blue stripe

and have a keyword select rooted at “Shirts/Size” one level deep,
and one rooted at “Shirts/Color” one level deep. So you want
your keyword boxes to look like

Size [ M ] Color [ Solid black ]
[ L ] [ Red/blue stripe ]

Since RT doesn’t have to be protected from slashes in keywords, the
user doesn’t need to be protected from it either; slashes in keywords
should work just fine. Of course, if they don’t actually work, that’s
a real bug. :slight_smile:

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca -----------±----------------------------------------------

Rich lafferty writes:

Because you’re a newbie for a couple weeks, and an experienced user
for years. :slight_smile:

On the other hand, the number of newbies who run into this problem >>>
the number of experienced users who need ‘/’ characters in their
keywords. On most systems, you can’t have ‘/’ characters in your
filenames either, but I haven’t heard people complain too much about that.

and have a keyword select rooted at “Shirts/Size” one level deep,
and one rooted at “Shirts/Color” one level deep. So you want
your keyword boxes to look like

Size [ M ] Color [ Solid black ]
[ L ] [ Red/blue stripe ]

Since RT doesn’t have to be protected from slashes in keywords, the
user doesn’t need to be protected from it either; slashes in keywords
should work just fine. Of course, if they don’t actually work, that’s
a real bug. :slight_smile:

You can always use “Red&blue stripe” or “Red-blue stripe” etc. And an
experienced user can always search the perl code for the error message
they receive and disable the check; this is a lot harder for a newbie
(especially since the error message you get in that case is far removed
from the source of the problem).

@alex
mailto:dupuy@sysd.com

Rich lafferty writes:

Because you’re a newbie for a couple weeks, and an experienced user
for years. :slight_smile:

On the other hand, the number of newbies who run into this problem >>>
the number of experienced users who need ‘/’ characters in their
keywords. On most systems, you can’t have ‘/’ characters in your
filenames either, but I haven’t heard people complain too much about that.

I haven’t heard people complain too much about this.

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca -----------±----------------------------------------------

Rich lafferty writes:

Because you’re a newbie for a couple weeks, and an experienced user
for years. :slight_smile:

On the other hand, the number of newbies who run into this problem >>>
the number of experienced users who need ‘/’ characters in their
keywords. On most systems, you can’t have ‘/’ characters in your
filenames either, but I haven’t heard people complain too much about that.

I’m with Rich on this: placing an artificial limitation on a system to
protect new users from the power of that system is just wrong. It’d be
like putting a 10MPH governor on a Ferrari because a new driver might
have an accident if they go faster.

Perhaps the more proper solution is to improve the documentation?

Cheers!

–j
Jim Meyer, Geek At Large purp@wildbrain.com

Jim Meyer wrote:

I’m with Rich on this: placing an artificial limitation on a system to
protect new users from the power of that system is just wrong. It’d be
like putting a 10MPH governor on a Ferrari because a new driver might
have an accident if they go faster.

Perhaps the more proper solution is to improve the documentation?

Improving the documentation assumes that people actually read it first.
And it does nothing to address the fact that the user interface uses
’/’ as a separator between nested levels of keywords in it’s display,
leading users to believe that it works like filenames (which disallow
’/’ except as a separator). If you really think ‘/’ in keyword names is
important, the more proper solution is to rework the user interface so
that ‘/’ isn’t used to indicate keyword nesting (it would be ambiguous
in any case).

And your analogy with a 10MPH governor is overblown; it’s just a
fripping ‘/’, for cripes sakes! A somewhat better (though still flawed)
analogy would be having an interlock on your gearshift that requires you
to depress the brake before you shift out of park. This might be a
minor annoyance to some experienced drivers, but it will also prevent
other drivers from crashing the car into a wall. And serious racers
will replace the automatic transmission with a manual transmission
(without ‘park’) anyhow.

@alex
mailto:dupuy@sysd.com

And your analogy with a 10MPH governor is overblown; it’s just a
fripping ‘/’, for cripes sakes!

Yep! That’s why it’s still there. I’m glad you agree it doesn’t
matter.

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca -----------±----------------------------------------------

Jim Meyer wrote:

Perhaps the more proper solution is to improve the documentation?

Improving the documentation assumes that people actually read it first.

This is where it reduces to philosophy: you don’t want new users to have
to read the instructions before you start setting RT up for production.
I think that reading those instructions is the measure of a responsible
technologist. I wouldn’t hire an irresponsible one; you spend too much
time cleaning up problems of poor implementation or, worse, poor
preliminary evaluation.

And it does nothing to address the fact that the user interface uses
’/’ as a separator between nested levels of keywords in it’s display, […]

I don’t see that using a / separator is a problem which needs to be
addressed. Again, I think it’s a matter of philosophy.

And your analogy with a 10MPH governor is overblown; […]

Analogy is always flawed; it’s an attempt to model a problem in more
familiar terms and fewer words than required to precisely describe the
entire system at hand. If you find you’re having to explain your
analogy, you know it’s not a good one.

To be precise, your solution means that any new user is protected
against this one flaw (and lulled into thinking he understands the
system, a side issue to this discussion); any programmer can remove the
limitation once s/he has hunted it down; and any other user (e.g.
experienced non-programmers) is stuck with it. That is unacceptably and
artificially dumbing-down the system to no worthy purpose.

I think we must agree to disagree. Luckily, we are neither of us the
arbiter of this. =]

Cheers!

–j
Jim Meyer, Geek At Large purp@wildbrain.com

Jim Meyer wrote:

Perhaps the more proper solution is to improve the documentation?

Improving the documentation assumes that people actually read it
first.

This is where it reduces to philosophy: you don’t want new users to
have to read the instructions before you start setting RT up for
production. I think that reading those instructions is the measure of
a responsible technologist.

I agree with both of you! I reckon it’s responsible to read through the
instructions before deploying a new system for real.

But also before making a decision to deploy new software, it’s
responsible to evaluate it. Given how awful most software is, it seems
responsible, at least initially, to minimise the time spent testing a
particular program. Often just by playing around with some software
it’s possible to get a feel for it (or at least enough to know it isn’t
worth bothering with!).

I’d expect a competent techie to have enough background, experience,
nouse, and curiosity to be able to make a stab at an initial evaluation
without spending lots of time ploughing through all the available docs.

And it does nothing to address the fact that the user interface
uses ‘/’ as a separator between nested levels of keywords in it’s
display, […]

I don’t see that using a / separator is a problem which needs to be
addressed. Again, I think it’s a matter of philosophy.

For what it’s worth, I also initially tried creating hierarchies by
typing slashes in keyword names, but I worked out the ‘correct’ way
within half an hour or so. I did look at the documentation – it was
the ‘RT/FM Installation Guide’ that caused me to try typing slashes in
the first place. (I hadn’t read the Keywords-Howto by that stage.)

So an explicit warning in the installation guide would seem a good idea.
(Many beginners appear to have fallen for this, and that won’t irritate
experienced users since the latter won’t be reading the installation
guide.)

To be precise, your solution means that any new user is protected
against this one flaw (and lulled into thinking he understands the
system, a side issue to this discussion); any programmer can remove
the limitation once s/he has hunted it down; and any other user (e.g.
experienced non-programmers) is stuck with it. That is unacceptably
and artificially dumbing-down the system to no worthy purpose.

I agree with that; removing this functionality would be bad.

However, as a compromise, what about not refusing to add keywords with
slashes but still displaying a warning message? That way any beginner
who’s got this wrong gets told about it, but on the odd occasions
experienced users want slashes they still can.

The warning could even be restricted to only being displayed when
generating a keyword called “Left/Right” when there already is a keyword
simply called “Left”; that would catch all the beginners making this
mistake and affect hardly anybody genuinely wanting slashes.

Note that the above is merely by conjecture: there is almost no chance
of me being bothered to write code to do this – yes I did make the
mistake, but having made it once I’m not going to make it again, and
there’s many more things I want in ‘RT’ for my own use that I’m much
more likely to code.

Cheers.

Smylers
GBdirect