Ok.I’ve taken tobias’ suggested interim hack for subscriptions and embellished it a bit
Here’s how the proposed solution will work:
Scrips will contain a list of all scrips available within the RT instance. Examples include:
‘Autoreply’,‘Sends an automatic response to the requestor when a ticket was created’
‘TellOwnerOnTransaction’,‘Sends mail to owner when anything happens’
‘TellMembersOnMail’,‘Sends mail to interessted parties when email comes in’
‘MailComments’,‘Sends mail to interessted parties upon a comment’
‘NotifyWatchersOnCorrespond’, ‘Send mail to watchers whenever correspondence comes in’
‘NotifyAdminWatchersOnTrans’, ‘Send email to all applicable administrative watchers on every transaction’
‘NotifyWatchersOnComment’, ‘Send mail to watchers whenever comments come in’
‘NotifyWatchersOnStatus’, ‘Send mail to watchers whenever a ticket’s status changes’
‘NotifyWatchersOnResolve’, ‘Send mail to watchers whenever a ticket’s status changes to resolved. Note that this
requires a special action with extra logic’
ScripScope (I’m open to a better name) will contain a listing of queues for which each Action applies and which
template should be used.
Watchers will contain entries for which email addresses watch which queues and tickets and whethere
the watcher in question is a: Requestor, Cc or Administrative Cc. Generally, administrative Ccs will
get copies of comments added to a ticket and will not be visible to the end user. Watchers will be able to
toggle mail notification at a per ticket/queue (whatever’s in the table) level.
How does this sound?
jesse
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
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.
(…)
‘NotifyWatchersOnStatus’, ‘Send mail to watchers whenever a ticket’s
status changes’
‘NotifyWatchersOnResolve’, ‘Send mail to watchers whenever a ticket’s status changes to resolved. Note that this
requires a special action with extra logic’
(…)
Watchers will contain entries for which email addresses watch which
queues and tickets and whethere the watcher in question is a: Requestor,
Cc or Administrative Cc. Generally, administrative Ccs will get copies
of comments added to a ticket and will not be visible to the end user.
Watchers will be able to toggle mail notification at a per ticket/queue
(whatever’s in the table) level.
It’s still a bit diffuse how you’re planning to handle watcher
ccs/adm…blah…bccs. If you’re doing it with a special NotifyWatchers
action, then there will be a slight design bug in the scheme above as I
see it. Except for that, it’s good enough. It can do all the things we
could do in 1.0, and it is more flexible, so it’s good enough for 2.0.
For 2.1, we need to let individuals limit their subscription to only some
few scrips.
(…)
‘NotifyWatchersOnStatus’, ‘Send mail to watchers whenever a ticket’s
status changes’
‘NotifyWatchersOnResolve’, ‘Send mail to watchers whenever a ticket’s status changes to resolved. Note that this
requires a special action with extra logic’
(…)
Watchers will contain entries for which email addresses watch which
queues and tickets and whethere the watcher in question is a: Requestor,
Cc or Administrative Cc. Generally, administrative Ccs will get copies
of comments added to a ticket and will not be visible to the end user.
Watchers will be able to toggle mail notification at a per ticket/queue
(whatever’s in the table) level.
It’s still a bit diffuse how you’re planning to handle watcher
ccs/adm…blah…bccs. If you’re doing it with a special NotifyWatchers
action, then there will be a slight design bug in the scheme above as I
see it.
What bug would that be?
Except for that, it’s good enough. It can do all the things we
could do in 1.0, and it is more flexible, so it’s good enough for 2.0.
For 2.1, we need to let individuals limit their subscription to only some
few scrips.
Yeah. I’ve come to realized that the access-control system for that may be hellish
and anyway, it’s going to slip our schedule a bunch. This systems isn’t as flexible
as I’d hoped, but I think it’s a whole lot better than what’s in 1.x
It’s still a bit diffuse how you’re planning to handle watcher
ccs/adm…blah…bccs. If you’re doing it with a special NotifyWatchers
action, then there will be a slight design bug in the scheme above as I
see it.
What bug would that be?
Maybe I’ve misunderstood. I thought that you, regardless of the scrips,
where to call a NotifyWatchers action which sent mail to Bccs and Ccs with
whatever template they would like. The problem with that is, that as long
as it’s only requestors, Ccs and Bccs in the watcher table, you don’t know
who the “queue members” which might want to receive the comments,
correspondance, etc, are.
Except for that, it’s good enough. It can do all the things we
could do in 1.0, and it is more flexible, so it’s good enough for 2.0.
For 2.1, we need to let individuals limit their subscription to only some
few scrips.
Yeah. I’ve come to realized that the access-control system for that may be hellish
and anyway, it’s going to slip our schedule a bunch.
The ACL? Shouldn’t be that difficult. If we cut some corners and offer
not much more than in 1.0 - that is, the current QueueACL table, it should
be pretty simple to check if the user has permission or not on a certain
ticket or transaction object.
In later version I’d really like to see possibilities for setting more
fine tuned ACLs. I think I have had some ideas here earlier.
It’s still a bit diffuse how you’re planning to handle watcher
ccs/adm…blah…bccs. If you’re doing it with a special NotifyWatchers
action, then there will be a slight design bug in the scheme above as I
see it.
What bug would that be?
Maybe I’ve misunderstood. I thought that you, regardless of the scrips,
where to call a NotifyWatchers action which sent mail to Bccs and Ccs with
whatever template they would like.
No. there will still need to be an explicit entry in ScripScope that says to notify watchers.
I think for now, I’m going to cut the per-watcher template settings. maybe later they’ll come back.
The problem with that is, that as long
as it’s only requestors, Ccs and Bccs in the watcher table, you don’t know
who the “queue members” which might want to receive the comments,
correspondance, etc, are.
Nope. now watchers can apply to both tickets and queues.
Except for that, it’s good enough. It can do all the things we
could do in 1.0, and it is more flexible, so it’s good enough for 2.0.
For 2.1, we need to let individuals limit their subscription to only some
few scrips.
Yeah. I’ve come to realized that the access-control system for that may be hellish
and anyway, it’s going to slip our schedule a bunch.
The ACL? Shouldn’t be that difficult. If we cut some corners and offer
not much more than in 1.0 - that is, the current QueueACL table, it should
be pretty simple to check if the user has permission or not on a certain
ticket or transaction object.
That part doesn’t bother me. it’s things like “which scrips can this user
subscribe to?” “with which templates?”
In later version I’d really like to see possibilities for setting more
fine tuned ACLs. I think I have had some ideas here earlier.
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
. . . when not in doubt, get in doubt. – Old Discordian Proveb
That part doesn’t bother me. it’s things like “which scrips can this user
subscribe to?” “with which templates?”
Ah … well … my idea was not to put limits on what scrips the user can
subscribe to, but filter out what he can’t get somewhere else … ehrm …
yeah, it might be difficult. But anyway, let’s priority to get it up
running, including the web interface.
I should have helped out looking at it this night, and yesterday
night, but … well … maybe next week. The work is going at a skiing
event this weekend, so I’ll be away.