[rt-devel] Re: [rt-commit] CVS commit: rt

Jesse jesse at fsck.com
Wed Mar 22 14:01:16 EST 2000

On Wed, Mar 22, 2000 at 07:42:10PM +0100, Tobias Brox wrote:
> > > And why do you think it's better to bind users to Templates
> > > instead of Scrips?  Well, I can see the reason when the user should be
> > > Bcc'ed/Cc'ed ... but except for that, templates must be a lot less
> > > flexible than Scrips?
> > >
> > 
> > Right. I actually want to significantly limit what interested parties can 
> > set themselves up to recieve.
> When thinking, maybe it won't be right to bind a Watcher to a specific
> entry in the Scrips table.  But I don't think it makes more sense binding
> it to a specific entry in the Template table!  Besides it's a bit
> confusing; would it mean that this template always should be sent to the
> watcher when something happens, or does it mean that the watcher should
> only get emails when the template is invoked?

It would mean that whenever that entry in Watchers matches the current
transaction, the NotifyWatchers.pm action would send mail to the watcher's email 
address with the template listed in the watchers table. The plan was to eventually
set up another table which listed which templates could be selected by which classes
of watchers in whihc queues.

> Maybe we need to rethink the whole concept of Watchers, Scrips, Actions 
> and Templates.  At least I think we need to define them better.  I can see
> problems to the current approach.
[definitions cut out. they look good] 
> How do I subscribe to all correspondence of queue A?
> ...add an entry to the Watchers table.
> /* Here we do have a problem.  The Templates doesn't relate to the queues
> in any way.  What if we have 5-6 basic templates and all of them are
> translated into 5 different languages?  It would be utterly stupid to give
> the web user 30 choises, where only some few of them applies to the actual
> queue.  We might check up the scrips, and ask them what queues are related
> to what templates ... but I think it's sort of the wrong way to do it
> anyway.  And what if we use the same template for several Scrips?  I can
> agree that there would be something of the same issues if binding watchers
> to scrips (or even actions) as the actions contain logic for
> deciding who should get mail and who shouldn't.  It seems that whatever we
> do here, we will fail.
> I suggest a third option; let it be possible to subscribe to specific 
> transaction types. */

This can be done but only via scrips. which I don't want end-users to be able 
to do. Maybe certain users could be permitted to add in scrips for themselves/others

> I'm owning some requests, but I really don't want to get mail about every
> transaction - how do I turn it off?
> ...sorry, you can't.

Your RT administrator can change the scrips for your queue.

Lets not completely overhaul scrips for 2.0.  We can do the cool stuff 
with order-of-evaluation, etc for 2.1

> /* what about moving owner to the watchers table? */
> We have the installed the package with all the defaults, and added some
> ten queues.  We don't want AutoReply at the last queue we set up, how do
> we turn it off?
> ...by replacing Scrip 1 with one Scrip for each queue except the last one.
> /* This is not a good way to do it.  I think we can avoid it with my
> idea about priorities */

Like I said above, lets leave this for 2.1. It's not ideal, but I want to get 2.0 out by june

> I'm subscribing to queue 2, but I don't want to receive activity on ticket
> #456.  Can I turn it off?
> No.
> /* What about letting one Quiet Watcher item turn off an active watcher
> item? */

No fundamental objection, but lets leave this for now. 


jesse reed vincent -- jrvincent at wesleyan.edu -- jesse at fsck.com 
pgp keyprint:  50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
They'll take my private key when they pry it from my cold dead fingers!

More information about the Rt-devel mailing list