[rt-users] Comment when ticket transfers queues

[Ruslan U. Zakirov]

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.

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

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

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

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

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.


PS: sales at bestpractical.com or hack it yourself and share.
> 
> Cheers,
> -- jra