[rt-users] Keywords (not) designed into Create Ticket, and...

[doug.mildram at mindspeed.com]

This is more about RT design and features as opposed to a "....broken/help".
(sorry, about 60+ lines long).  I'm testing it out by myself so far.

I'm new to (TRYING) RT this week: 2.0.6 tues, Upgraded to 2.0.7 thursday.
Because it's unix+web+open, I want to "sell" this (USE in a large company) 
 to my cohorts and their bosses. But I have to determine what it can
  and cannot do easily, and we have some needs/expectations.  

Being a large multi-site company, we envision a queue or 2 FOR EACH SITE.

And, there are various kinds of users and problems common to all sites,
    e.g.  unix vs. pc users/problems;  software vs hardware; 
          backups; printers; etc.  Certainly we won't create queues
          for all these various things.  But, the help desk does need
          to know different background info depending on the problem.

Jesse said the RT answer was probably KEYWORDS; e.g. "Client OS".

So, I learned enough (thank you, www.helgrim.com/rtdocs ! ) 
      to add pulldown KEYWORD menus for queues.
Then tested the flow.......  the first thing i noticed was:

When creating NEW TICKET from the standard web-gui, 
              *********
 the user has no vision into, or idea about about the keywords. So,
the (untrained end-user) might dutifully input a lot in text, or lazily just
typing a problem without enough background  (e.g. "Client OS").
Then, user can hit SUBMIT.  Then user can! CONTINUE and (this would take
arm twisting or training the users) THEN Select Keywords. It might aggravate
the dutiful ascii-typing person, and the lazy person probably wouldnt 
CONTINUE (take 2nd look, add keywords). Unless we trained endusers to do so.
Am I missing something to easily fix this? 
This seems a rather illogical flow; restated, it's asking a lot for a user 
to "submit"/change his input a couple times because "keywords appear later".

So is the answer a much-different homegrown front end,  (pay Jesse?:)
     or a (perhaps very difficult?) tweak to the initial Create Ticket?
 (something we'd certainly want/expect to be able to adjust ourselves.)

---down the yellow brick road,  (you're still READING this? god love ya)
Perhaps a different (set of) frontend(s) for New Ticket is needed.
We do envision a VARIETY of "forms" (ascii or menu-select)
  which (in our dreams,) magically arise depending on choices.  

While I can imagine designing web-forms (inside or outside of RT ? )
to generate emails as incoming ticket source to RT, 
then I have a "mixed authentication problem"  (if outside RT).
Seems like I'd need the reporter/user to be "in RT gui"  (authenticated w/RT)
so the frontend knows correct email address corresponding to RT loginname.
Probably like most people, I'm way behind the web language curve,
though it has an intoxicating smell. (I've seen Mason errors in RT,
and omigod, i think the dying line of code underlines itself on failure!)
(gotta wonder where the bizzare HASH comes from though !:)

-----I'm also very interested in the possible "fix" to the
  "MOVED ticket....keywords LOST" bug/feature.
I verified this as you may have too; 
I also moved the ticket BACK to the original
 queue, and the keywords for that ticket reappear. 
Hope springs eternal.               

A moment of prayer...(for all things). You folks are a nice bunch. --doug
================================================================
Doug Mildram  Mindspeed Technologies 
doug.mildram at mindspeed.com     8 Technology Drive             
Systems Admin.		       Westborough, MA  01581        
DIRECT: 508-621-0667