[rt-devel] Some stuff I would like.

[Rouillard, John]

I have just installed rt, and it looks good. I like the web interface, but
I'm an old req user at heart, and years ago I modified req to do some things
I would like implemented in rt, but I am really at a loss as to where to
start. If some of this stuff is covered in the next version (2.x) of rt, let
me know.

1) The ability to hide requests from users who didn't submit them. In req, I
had it set up so that users could view all tickets except those with a
non-empty

	X-REQ-Restricted:

header. The value of the header was the list of users (email addresses) who
were allowed to see the existance of the request.  If the header was empty,
viewing the ticket wasn't restricted. The requestor, and anybody elso on the
notify lists (see item 2 below) could always see the request as could the
owner. This was good for those instances where we got "delete joe blow's
account on 2/10" when joe blow didn't know he wouldn't be needing his
account. There were also some other items that were just not intended for
general consumption.

Note that this was a per request thingy, not a per queue/area thingy.

I think adding two new access modes would work to implement this.

	display-self  - only see tickets you are associated with.
	display-all   - see all tickets including hidden requests.

have display default to seeing all non-hidden tickets.see all requests
except hidden requests.

2) The ability to add users to the list of people receiving responses. I
defined headers:

	x-req-resolve
	x-req-stall
	x-req-status
	x-req-all

with email address for reporting status changes (give, take, steal, open,
resolved ...), resolution or stalling of problems (subset of status), all
traffic on the ticket. Again this was a per ticket thingy, so if my boss
wanted to be kept up to date on what was happening to tickets submitted to
me from other groups, I just added him onto the redistribution list on the
ticket.

Also the cc list was parsed on the incomming ticket and added to the cc list
for the ticket which was sent email just like the requestor. This made it
easy for a user to enter a ticket that he and his partner were working on,
and both got the responses.

3) auto filtering/assignment of tickets. I used a redirection scheme that I
hacked into the mail filter to allow the calling of an external script to
look for info in the files and returned the owner, and area. This way
tickets could be a automagically assigned if for instance the words "order
paper" appear in the message, it would get assigned to the person who did
the ordering. 

Also areas could have particular owners associated with them. When the
ticket was sorted/assigned to an area, the owner was automagically notified
that there was a new ticket that s/he owned.

5) The email interface in req allowed everything I could want (I added a few
things) including getting a full copy of the ticket. However, req didn't
require all users that would use it to be added to a database E.G. %RT user
%rt password weren't used. Also commands embeded in the ticket X-Request-Do
were acted on by all aliases, not just the "-action" alias. I got a fair
number of requests from off site users that I had to respond to, who could
track their entire ticket via email. Trying to give them two addresses and
explain when each was to be used would be a bit of a problem.

I was thinking of changing the email interface so that email destined for
people already associated with the ticket don't have to identify themselves
for actions that are reversible (resolving a ticket, but not killing or
merging a ticket) or have no effect (e.g. getting a copy of the ticket).
Also actions would be parsed for in all tickets. The action lines would be
stripped out before the message was saved as a comment or reply transaction,
thern the actions in the message would be appended as transactions. This way
I could send email like:

	mumble mumble this is done.
	%RT resolve

and have the user notified that the request was done, and marked resolved
all in one fell swoop. As it appears to work, I need two separate emails to
make my comments about how I solved the problem and that it is resolved.

This would also allow for an %RT comment command in the message that would
allow email to be trated as a comment and not forwarded to interested
parties. This would be an alternate way of sending email comments besides
the [comment] subject tag that somebody submitted patches to implement. Also
%RT sendto could be used to force rt to cc a message and record it as a
transaction.

6) A stale date was associated with a ticket. This was used only when the
ticket was stalled. If there was no stale date specified in the stall
request one would automatically be added 7 days hence. The daily maintainace
scripts would look at stalled tickets. If the stall date was today, then
email was sent to the owner of the ticket saying that it was stalled. If
nothing was done to lengthen the stall date, the ticket was reopened the
following day.


7) The open, stalled, resolved model works, but we found a copule of more
status's to be useful:
	deferred - means it sould be solved at some time, but not right now.
It keeps
		it alive in the queue, but it isn't put in with the open
tasks.
	confirm - means the ticket is waiting for the user to confirm that
the problem 		is solved before the ticket is closed. I realise rt
is using the req 			mechanism of  repopen the ticket if
a change is made after it is 			      resolved, but
sometimes that just isn't a good model.

As an aside, I just looked at the web based interface with lynx. None of the
headers line up with anything underneath. I think its because of the way
lynx handles tables, but it can probably be cleaned up if the cgi can figure
out what the output browser is.

Well enough from my mouth (um fingers) for now. Quips, comments, evasions,
questions or answers anybody?

-- rouilj