Some stuff I would like


#1

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.

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

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

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

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

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


#2

Ok, I’m about to head off to work, so I’m going to do a quick pass over this

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.

Well, RT 2 will come with a tool that will allow users to see all their requests,
which should help deal with such things.

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

We’re getting a much better notification system in RT2. (It’s mostly there already)

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

I have some vague ideas about how to implement this in RT2 but haven’t started touching
it yet. RT’s implementation of this should be database-driven…but it’s certainly
something that I’d like to see added to the new mailgate.

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

So basically using email address instead of %RT user as an auth mechanism?
It’s not secure, but it’s become apparent that some sites want it. I’m sure
a patch posted to rt-devel would be appreciated greatly.

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

Cute. I’ll think about that for RT2

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

for 2.0, we’re sticking with this status model. There are only so many things
we can address at a go. I’ve been pondering queue-level status configuration for
a future version.

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.

Try a text-based browser that can handle tables, like links or w3m.

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

– rouilj


Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Gur SOV jnagf gb znxr guvf fvt vyyrtny.