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@wesleyan.edu – jesse@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!
