[rt-users] Comment when ticket transfers queues

[Jay R. Ashworth]

On Sat, Jun 18, 2005 at 01:20:00AM +0400, Ruslan U. Zakirov wrote:
> Jay R. Ashworth wrote:
> > On Fri, Jun 17, 2005 at 11:47:46PM +0400, Ruslan U. Zakirov wrote:
> > 
> >>Vicki Stanfield wrote:
> >>
> >>>I am trying to determine how to get RT to prompt for and add a comment
> >>>to the ticket when it is transferred to another queue. I tried editing
> >>
> >>1) RT adds transaction to the ticket that ticket was moved from queue A
> >>to queue B.
> >>2) You can't force user to add comment whe he moves ticket to another
> >>queue. Learn your users explain thier movement.
> > 
> > "The software can't do it, train your users not to forget" is never an
> > acceptable answer, Ruslan.  :-)

> Hehe, do you have time and knowledge to work on this for free? I work on
> other RT relaited projects. Did you see wishlist on the wiki? In my head
> and local rt_todo.txt a lot of additions to that list.

At the moment, no.  But, if there's a concensus that it is The Right
Thing To Do, then certainly, someone ought to communicate that
concensus to Those Who Design.  No?

> > Yes, I believe that's what she wants: she wants to force RT to prompt
> > for a comment transaction to automagically accompany the queue change
> > transaction.

> You should know that RT doesn't support mandatory actions at all. For
> example you can't force user to do something if he want do something
> else. So to implement this feature in the right way you have to write
> basic framework that allows developers to write fallback code paths
> easy. By "right way" I mean patch is can be merged into mainline, and
> requirements to such patches are far-far away from patches users usualy
> send to MLs, it requires docs, tests...

Well, bouncing updates that don't meet spec is, I suspect already in
there; this amounts merely to changing "doesn't meet spec" slightly.

The full-sized version of how I'd approach this, myself, though,
constitutes a fairly large change, yes.

> > On reflection, it seems to *me* that the easiest way to accomplish
> > that, since the queue in which a ticket lives seems only to be able to
> > be changed in the GUI from Basics and Jumbo, is to further restrict it
> > only to the Jumbo screen, and modify the code which catches it to throw
> > an error on Queue changes unless the comment field has contents in it.

> solution is broken, because you have to learn your users to use Jumbo
> page if he wants move ticket to another queue. Do you often use Jumbo
> page? I never used it :)

If there's no other place to move it, then what will they do?  :-)

> You should catch event in all places, even in bulk update and this would
> be right solution.

Well, semantically, bulk updates ought to have comments for (slightly)
different reasons, but going that far pushes it down into a DBMS
trigger, I suspect.

> > I'm not enough of an RT hacker to know how practical such a change to
> > the code is, but this sort of speaks to where *I* was originally going
> > with ticket-tracking design before I found RT, which is that *every*
> > transaction automatically has fields for both private and public
> > comment, regardless of what sort of transaction it is.

> I don't understand what are you talking about.

Then you didn't read closely enough.

> This is Transactions table with comments:
>   id INTEGER NOT NULL  AUTO_INCREMENT,
>   ObjectType varchar(64) NOT NULL,
>   ObjectId integer NOT NULL DEFAULT 0  ,
> # Link to the object: for eaxmle ('Ticket', 1)
> 
>   TimeTaken integer NOT NULL DEFAULT 0  ,
> # time taken to finish job described in this transaction
> 
>   Type varchar(20) NULL  ,
> # type of transaction
> 
>   Field varchar(40) NULL  ,
>   OldValue varchar(255) NULL  ,
>   NewValue varchar(255) NULL  ,
> # what field was changed with this transaction, old value, new value
> 
>   ReferenceType varchar(255) NULL,
>   OldReference integer NULL  ,
>   NewReference integer NULL  ,
> # new thing to me, didn't analize this much
> 
>   Data varchar(255) NULL  ,
> # private data
> 
>   Creator integer NOT NULL DEFAULT 0  ,
>   Created DATETIME NULL  ,
> # common fields
> 
>   PRIMARY KEY (id)
> 
> I don't see any special fields with public or private comments in the
> Transactions table.

<sigh>  Clearly, you missed where I said "where *I* was originally
going with ticket-tracking design before I found RT".

> PS: sales at bestpractical.com or hack it yourself and share.

Oh, so we're *not* interested in suggestions regarding design issues,
then?  That's an assertion that I think I'll only actually believe if
it comes with an @bestpractical.com email address.

All The Smart Designers Aren't You, either, to paraphrase the rule.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

      If you can read this... thank a system administrator.  Or two.  --me