jesse at pallas
Mar 13, 2000, 8:24 AM
Post #2 of 2
(420 views)
Permalink
|
Ok, I'm about to head off to work, so I'm going to do a quick pass over this
On Mon, Mar 13, 2000 at 10:10:54AM -0500, Rouillard, John wrote:
> 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.
> 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.
>
We're getting a much better notification system in RT2. (It's mostly there already)
> 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.
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.
>
> 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.
>
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.
> 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.
>
Cute. I'll think about that for RT2
>
> 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.
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 [at] lists
> http://lists.fsck.com/mailman/listinfo/rt-devel
>
--
jesse reed vincent -- jrvincent [at] wesleyan -- jesse [at] fsck
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.
|
