CVS commit: rt


#1

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.edujesse@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!


#2

It would mean that whenever that entry in Watchers matches the current
transaction, the NotifyWatchers.pm action

You never told about NotifyWatchers.pm, but it might be a good idea.
Though I’m not sure about it.

would send mail to the watcher’s email
address with the template listed in the watchers table.

Regardless of which transaction is beeing done? Might be a good idea.
Then NotifyWatchers clearly need to be narrowed to only Bcc and Cc
watchers. Anyway, different templates might be wishable for different
transaction types…as the defaults I’ve putted in, they’re related to the
different transaction types, rather than personal preferences.

This can be done but only via scrips.

Today we have three levels of subscription; “All transactions”, “comments
and correspondence” and “correspondence only”. I think it should be
very easy to keep those three levels (at an individual level) and still
possible to add flexibility. I can’t see any good ways to fix this with
the current design ideas … maybe with the exception of adding a field
for transaction type to the watchers.

I fear that both scrips and watchers might be filled up with really a lot
of almost similar entries if we add too many fields to those tables.
Particularly I think it will be a Wrong Thing To Do to duplicate the
description field in the Scrips. Moving things out and into new tables
might be a solution.

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

Okay, okay … let’s try to Keep It Simple Stupid and cut corners where
possible. Those who need more functionality can always manage to get it
hacked in locally. Anyway, I think we must provide the features that
are available in 1.0. There it’s possible at queue level to indicate if
an owner is to be mailed or not. Okay, okay, it can be done from the
Scrips table. Never mind :slight_smile:

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

Yeah … but remember, we also need a functionable admin tool until then.
And it must be easy to use for those who are familiar with 1.0.

Well, what the hell … just let people add and remove the default scrips
at a queue level.

Hm, that is a thought - I think the Right Thing To Do would be to
extract the queue from Scrips to a new table which only links queues and
scrips. It would be quite straight forward to fix this, and it would be
quite straight forward for an admin tool to add and remove scrips for
queues.

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.

nod. Cool feature thought for 2.1.

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)


#3

It would mean that whenever that entry in Watchers matches the current
transaction, the NotifyWatchers.pm action

You never told about NotifyWatchers.pm, but it might be a good idea.
Though I’m not sure about it.

That’s because I hadn’t gotten around to dealing with it yet. sorry

would send mail to the watcher’s email
address with the template listed in the watchers table.

Regardless of which transaction is beeing done? Might be a good idea.
Then NotifyWatchers clearly need to be narrowed to only Bcc and Cc
watchers. Anyway, different templates might be wishable for different
transaction types…as the defaults I’ve putted in, they’re related to the
different transaction types, rather than personal preferences.

As an aside, I think I’d like to change it from Cc and Bcc to Cc and Administrative Cc.
Cc/Bcc didn’t make enough sense when trying to explain who should get comments and who shouldn’t.

This can be done but only via scrips.

Today we have three levels of subscription; “All transactions”, “comments
and correspondence” and “correspondence only”. I think it should be
very easy to keep those three levels (at an individual level) and still
possible to add flexibility. I can’t see any good ways to fix this with
the current design ideas … maybe with the exception of adding a field
for transaction type to the watchers.

The original idea was that for more complex behavior, we would build more complex
actions. That’s what &IsApplicable is for

I fear that both scrips and watchers might be filled up with really a lot
of almost similar entries if we add too many fields to those tables.
Particularly I think it will be a Wrong Thing To Do to duplicate the
description field in the Scrips. Moving things out and into new tables
might be a solution.

nod I’ll take a look

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

Okay, okay … let’s try to Keep It Simple Stupid and cut corners where
possible. Those who need more functionality can always manage to get it
hacked in locally. Anyway, I think we must provide the features that
are available in 1.0. There it’s possible at queue level to indicate if
an owner is to be mailed or not. Okay, okay, it can be done from the
Scrips table. Never mind :slight_smile:

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

Yeah … but remember, we also need a functionable admin tool until then.
And it must be easy to use for those who are familiar with 1.0.

Well, what the hell … just let people add and remove the default scrips
at a queue level.

That’s what they’ve got to do now. and we only give them 7 choices of scrip as it is.

Hm, that is a thought - I think the Right Thing To Do would be to
extract the queue from Scrips to a new table which only links queues and
scrips. It would be quite straight forward to fix this, and it would be
quite straight forward for an admin tool to add and remove scrips for
queues.

Quite possibly.

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.

nod. Cool feature thought for 2.1.

We’ll need some incenitive to make people upgrade.


Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)

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
I’m reasonably sure that at least two of the electric blue kangeroos
I saw were real.


#4

…oh, I didn’t see that rt-devel was added to the Cc list. Well. What we
are discussing here is how to cope with subscriptions in 2.0. The current
design should be very powerful, still when trying to do things in it, it
seems to me it can’t even cope with the configurations from 1.0. Maybe
the subject in this thread should be changed a bit …

[definitions cut out. they look good]

I will take out those definitions and put them into the CVS, branch
rt-1-1 under the docs directory. Meri might want to look over it and
eventually prettify it / put it somewhere else.

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)


#5

The original idea was that for more complex behavior, we would build more complex
actions. That’s what &IsApplicable is for

Hm, ok. Let’s inherit the 1.0 bug as for now (which I actually
carefully removed in the early 1.1 :), where queues subscribing to
both transactions and comments and correspondence will get two mail upon
comments and correspondence. I think my solution to this problem is quite
nice and not that complex, but we can discuss it more after the 2.0
release.

I think the Scrips should be something (people or “all queue
members”) can subscribe to, so from that point of view it makes sense
putting Scrips into the Watchers table (particularly when Queue is moved
out from the Scrips table).

My neighbour told me yesterday that they had laaaarge design charts over
their databases at work. Maybe we’ll need to paint up such charts to see
what seems logical and what doesn’t. Though, I hope we don’t have to do
that.

I’m going home now :slight_smile:

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)


#6

I think the Scrips should be something (people or “all queue
members”) can subscribe to, so from that point of view it makes sense
putting Scrips into the Watchers table (particularly when Queue is moved
out from the Scrips table).

If we let the Queue remain in the Scrips table, we can let “Scrips” be a
possible Scope value for Watchers. Still, I think that it might make
sense to allow an administrator to easily add/remove items from a table
that contain only scrip id and queue id.

This is probably not very understandable for those that hasn’t looked at
etc/schema.mysql from the rt-1-1 CVS branch :slight_smile:

Well, NOW I’ll run home and eat that dinner. :slight_smile:

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)


#7

I stringly disagree. Sometimes, something inapropriate gets in a ticket
that one desperately needs to whack. …
jesseOn Wed, Apr 05, 2000 at 10:34:25AM -0400, tobiasb@fsck.com wrote:

Module Name: rt
Committed By: tobiasb
Date: Wed Apr 5 14:34:25 UTC 2000

Modified Files:
rt/lib/RT: Ticket.pm

Log Message:
Temporary implementation of kill

As mentionated earlier, I think the right thing is to just set status
’dead’ and then eventually do some garbage collection later.

To generate a diff of this commit:
cvs rdiff -r1.1.2.46 -r1.1.2.47 rt/lib/RT/Ticket.pm


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

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
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.


#8

I stringly disagree. Sometimes, something inapropriate gets in a ticket
that one desperately needs to whack. …

I’d say something is awfully wrong somewhere if it frequently comes in
requests that are so bad that no other people with read access to the
queue should be permitted to see it under any circumstances.

And if this happens, it should be OK to have the garbage collection
mechanism available for anyone with write access to any queue. I actually
think people are getting used to the “empty trashcan” “feature” in
windows, it’s safer, there are usually enough disk space for it, and in
this case it’s also significantly faster (gee … I’ve seen trash can
implementations that takes a file, copies it to some trash can
folder/directory and then deletes it … horrible).

#Life ends with a crash
require ‘Coy.pm’;
&laughter while $I, die;
– Michael Schwern


#9

Actually, I find it quite rare that I need to kill a ticket. Generally when I need to, though, the whole ticket needs to goaway right now
Examples include: salaries, passwords or really inflamatory comments.

jesseOn Wed, Apr 05, 2000 at 04:47:11PM +0200, Tobias Brox wrote:

I stringly disagree. Sometimes, something inapropriate gets in a ticket
that one desperately needs to whack. …

I’d say something is awfully wrong somewhere if it frequently comes in
requests that are so bad that no other people with read access to the
queue should be permitted to see it under any circumstances.

And if this happens, it should be OK to have the garbage collection
mechanism available for anyone with write access to any queue. I actually
think people are getting used to the “empty trashcan” “feature” in
windows, it’s safer, there are usually enough disk space for it, and in
this case it’s also significantly faster (gee … I’ve seen trash can
implementations that takes a file, copies it to some trash can
folder/directory and then deletes it … horrible).


#Life ends with a crash
require ‘Coy.pm’;
&laughter while $I, die;
– Michael Schwern


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
"Bother," said Pooh, “Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three”


#10

| Actually, I find it quite rare that I need to kill a ticket. Generally
| when I need to, though, the whole ticket needs to goaway right now
| Examples include: salaries, passwords or really inflamatory comments.
±–>8

Hm. I haven’t ever encountered this; but then, the only people with access
to our queues are people within ECE Facilities. (And the sender can view
his/her own queue entries.)

Perhaps this needs to be configurable: “nuke immediately” vs. “kill but
allow viewing or un-killing”. Occasionally (thankfully, not too often)
we’ve needed the latter…

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]


#11

Actually, I find it quite rare that I need to kill a ticket. Generally when I need to, though, the whole ticket needs to goaway right now
Examples include: salaries, passwords or really inflamatory comments.

We use it frequently for blank requests, spam, etc.

#Life ends with a crash
require ‘Coy.pm’;
&laughter while $I, die;
– Michael Schwern


#12

[moved to rt-devel from rt-commit]

Well, for the mod_perl version, the uses take place up front. which means that
there’s no performance hit when a user runs into a page which needs another
module. As I understand it, that’s the “preferred” way to do things in a
mod_perl environment. For regular CGI, I think that we may need to move things
into the components. sigh I just wanted to be sure we were both aware of
what the other was doing.On Mon, Apr 10, 2000 at 04:46:27PM +0200, Tobias Brox wrote:

Are you adding these use statements for the CGI version of the mason
components?

Hm … do you think it’s better to place the use statements in webmux.pl /
rtmux.pl? I think I disagree.


Tobias Brox
aka TobiX
+47 22 925 871


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

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
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.


#13

sigh I just wanted to be sure we were both aware of
what the other was doing.

This is a small issue anyway. There is no performance hit involved in
having the “use” statements at both places. I will continue adding them
when needed.

Tobias Brox
aka TobiX
+47 22 925 871


#14

sigh I just wanted to be sure we were both aware of
what the other was doing.

This is a small issue anyway. There is no performance hit involved in
having the “use” statements at both places. I will continue adding them
when needed.

Agreed. that sounds good.


Tobias Brox
aka TobiX
+47 22 925 871

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
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.