Jay R. Ashworth 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
- RT adds transaction to the ticket that ticket was moved from queue A
to queue B.
- 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.
Clearly, you missed where I said “where I was originally
going with ticket-tracking design before I found RT”.
PS: sales@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@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