Howdy!
The subject mostly says it all.
RT::Action::Autoreply derives from RT::Action::SendEmail, in which
SetRecipients() is a mostly empty placeholder waiting to be overridden.
As you might expect, RT:A:AR overrides it by forcing the requestors into
the To field and moving on.
Contrast this with RT::Action::Notify, which implements a lovely
SetRecipients() accepting as an argument a comma-separated list any or
all of “Owner, Requestor, AdminCc, Cc or All”. This allows RT:A:N to be
used all the different non-“AsComment” scrips just by changing the
arguments.
It feels like Autoreply should either derive from Notify (as
NotifyAsComment does) or Notify::SetRecipients() should be promoted to
SendEmail. Oddly enough, I favor the latter because an autoreply is just
a specialized notification (with the proper queue return address set).
Any thoughts? I’ll happily submit either patch.
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
Autoreply is a one-trick pony. What do you stand to gain by adding
the layer of indirection?On Tue, Feb 19, 2002 at 08:51:45PM -0800, Jim Meyer wrote:
Howdy!
The subject mostly says it all.
RT::Action::Autoreply derives from RT::Action::SendEmail, in which
SetRecipients() is a mostly empty placeholder waiting to be overridden.
As you might expect, RT:A:AR overrides it by forcing the requestors into
the To field and moving on.
Contrast this with RT::Action::Notify, which implements a lovely
SetRecipients() accepting as an argument a comma-separated list any or
all of “Owner, Requestor, AdminCc, Cc or All”. This allows RT:A:N to be
used all the different non-“AsComment” scrips just by changing the
arguments.
It feels like Autoreply should either derive from Notify (as
NotifyAsComment does) or Notify::SetRecipients() should be promoted to
SendEmail. Oddly enough, I favor the latter because an autoreply is just
a specialized notification (with the proper queue return address set).
Any thoughts? I’ll happily submit either patch.
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
I should also point out that by default, Notify strips the sender out of the
message’s recipients. The whole reason Autoreply was created as a seperate
module was to avoid that behavior.
-jOn Tue, Feb 19, 2002 at 11:58:02PM -0500, Jesse Vincent wrote:
Autoreply is a one-trick pony. What do you stand to gain by adding
the layer of indirection?
On Tue, Feb 19, 2002 at 08:51:45PM -0800, Jim Meyer wrote:
Howdy!
The subject mostly says it all.
RT::Action::Autoreply derives from RT::Action::SendEmail, in which
SetRecipients() is a mostly empty placeholder waiting to be overridden.
As you might expect, RT:A:AR overrides it by forcing the requestors into
the To field and moving on.
Contrast this with RT::Action::Notify, which implements a lovely
SetRecipients() accepting as an argument a comma-separated list any or
all of “Owner, Requestor, AdminCc, Cc or All”. This allows RT:A:N to be
used all the different non-“AsComment” scrips just by changing the
arguments.
It feels like Autoreply should either derive from Notify (as
NotifyAsComment does) or Notify::SetRecipients() should be promoted to
SendEmail. Oddly enough, I favor the latter because an autoreply is just
a specialized notification (with the proper queue return address set).
Any thoughts? I’ll happily submit either patch.
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
–
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
Howdy!
I’ll take 'em both at once.
Autoreply is a one-trick pony. What do you stand to gain by adding
the layer of indirection?
AutoreplyToRequestorsAndCcs.
[Pardon me while I gush: it’s outrageously hip that RT is so well
designed – that it’s architecture is so easy to grasp – that I could
make a sensible reply that concise. I love good engineering. =]
I should also point out that by default, Notify strips the sender out of the
message’s recipients. The whole reason Autoreply was created as a seperate
module was to avoid that behavior.
Sorry, I overlooked that difference.
I think I’d then change my opinion and consider elevating
Notify::SetRecipients() into SendEmail once SetRecipient can be told to
leave the sender in (though not by default) and the behavior if provided
no arguments is to simply return().
That way, Notify can call it and still get the expected behavior,
Autoreply can call it requesting that the sender not be stripped, and
anything which relies on the current behavior of the dummy
SetRecipients() won’t be offended.
And again, I’d offer to do the work on this.
Cheers!
–j> > On Tue, Feb 19, 2002 at 08:51:45PM -0800, Jim Meyer wrote:
Howdy!
The subject mostly says it all.
RT::Action::Autoreply derives from RT::Action::SendEmail, in which
SetRecipients() is a mostly empty placeholder waiting to be overridden.
As you might expect, RT:A:AR overrides it by forcing the requestors into
the To field and moving on.
Contrast this with RT::Action::Notify, which implements a lovely
SetRecipients() accepting as an argument a comma-separated list any or
all of “Owner, Requestor, AdminCc, Cc or All”. This allows RT:A:N to be
used all the different non-“AsComment” scrips just by changing the
arguments.
It feels like Autoreply should either derive from Notify (as
NotifyAsComment does) or Notify::SetRecipients() should be promoted to
SendEmail. Oddly enough, I favor the latter because an autoreply is just
a specialized notification (with the proper queue return address set).
Any thoughts? I’ll happily submit either patch.
Jim Meyer, Geek At Large purp@wildbrain.com
Howdy!
I’ll take 'em both at once.
Autoreply is a one-trick pony. What do you stand to gain by adding
the layer of indirection?
AutoreplyToRequestorsAndCcs.
Reasonable. For now, I’d probably recommend
“OnCreate AutoReplyToRequestors with template Autoreply”
“OnCreate NotifyRequestorsAndCcs with template Autoreply” (which won’t notify the requestor, as they’re sending the message)
[Pardon me while I gush: it’s outrageously hip that RT is so well
designed – that it’s architecture is so easy to grasp – that I could
make a sensible reply that concise. I love good engineering. =]
Wow. Thanks so very much!
And again, I’d offer to do the work on this.
Sounds reasonable, though I’d like the work to go into RT 2.1, rather than 2.0.
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
AutoreplyToRequestorsAndCcs.
Reasonable. For now, I’d probably recommend
“OnCreate AutoReplyToRequestors with template Autoreply”
“OnCreate NotifyRequestorsAndCcs with template Autoreply” (which won’t notify the requestor, as they’re sending the message)
I thought of this earlier and discarded it as I suspected that multiple
requestor tickets would cause the non-creator requestor(s) to receive
duplicates. And as trivial as deleting an email is, I get crankygrams
from people over duplicate emails.
Is my suspicion unfounded?
[Pardon me while I gush: it’s outrageously hip that RT is so well
designed – that it’s architecture is so easy to grasp – that I could
make a sensible reply that concise. I love good engineering. =]
Wow. Thanks so very much!
Thanks very much for RT. I’m still picking up the pieces of wreq. Ugh.
And again, I’d offer to do the work on this.
Sounds reasonable, though I’d like the work to go into RT 2.1, rather than 2.0.
I think I hear CVS in there somewhere. Any pointers to a quick primer on
getting the various versions of RT out of CVS? Also, any quick pointer
as to how to view the RT queue for RT itself?
Thanks!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
Talking to myself. A bad sign.On Wed, 2002-02-20 at 18:40, Jim Meyer wrote:
I think I hear CVS in there somewhere. Any pointers to a quick primer on
getting the various versions of RT out of CVS? Also, any quick pointer
as to how to view the RT queue for RT itself?
You’d think I’d have perhaps spotted the big “BUGS” and “CVS” links on
Request Tracker... So much more than a help desk — Best Practical Solutions by now, wouldn’t you?
Cheers!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
Well, RT 2.1 is a bit more complex actually. I’m in the process of moving to a
new version control system, aegis, as it looks like it will provide much better
support for distributed development and make my life a good deal easier to boot 
When things get set up, you’ll either be able to haul down aegis changesets,
grab the current baseline as an aegis package OR use the tracking cvs repository
that will live at
:pserver:anoncvs@cvs.fsck.com:/raid/tracking-cvs
It’s actually there now, it just doesn’t let you authenticate yet.
-jOn Wed, Feb 20, 2002 at 07:02:11PM -0800, Jim Meyer wrote:
Talking to myself. A bad sign.
On Wed, 2002-02-20 at 18:40, Jim Meyer wrote:
I think I hear CVS in there somewhere. Any pointers to a quick primer on
getting the various versions of RT out of CVS? Also, any quick pointer
as to how to view the RT queue for RT itself?
You’d think I’d have perhaps spotted the big “BUGS” and “CVS” links on
Request Tracker... So much more than a help desk — Best Practical Solutions by now, wouldn’t you?
Cheers!
–j
Jim Meyer, Geek At Large purp@wildbrain.com
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
When things get set up, you’ll either be able to haul down aegis changesets,
grab the current baseline as an aegis package OR use the tracking cvs repository
that will live at
:pserver:anoncvs@cvs.fsck.com:/raid/tracking-cvs
It’s actually there now, it just doesn’t let you authenticate yet.
How about now? ( Or how does one get aegis changesets without downloading
large chunks from www.fsck.com/pub/rt/devel ? )
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations
I haven’t had the time to make the tracking-cvs properly world-readable yet.
You can get aegis changesets in two different ways:
You can either stuck down the baseline and each changeset from
http://fsck.com/pub/rt/changesets/
and apply the changesets in order to get the full historical record OR
you can grab a current baseline without a full historical record from
http://fsck.com/pub/rt/devel/rt.2.1-current-baseline.ae
As I mentioned, aegis isn’t quite working out to be quite as nifty-keen
as I’d hoped. I need to put some more energy into figuring out whether I’ll have
an easier time writing the aegis tools to make it do what it’s lacking or the CVS
tools to let me pull up changesets from other repositories without pain and suffering.> On Thu, 21 Feb 2002, Jesse Vincent wrote:
When things get set up, you’ll either be able to haul down aegis changesets,
grab the current baseline as an aegis package OR use the tracking cvs repository
that will live at
:pserver:anoncvs@cvs.fsck.com:/raid/tracking-cvs
It’s actually there now, it just doesn’t let you authenticate yet.
How about now? ( Or how does one get aegis changesets without downloading
large chunks from www.fsck.com/pub/rt/devel ? )
–
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
Just my $0.02. . CVS sucks, but so do most config revision systems,
and most standards for that matter… I understand why you’d want to
improve RT with aegis, but i’d guess that you’d loose sync with
your developers who also need to catch up behind your research… Personally,
it would make it much harder for me to keep my systems up-to-date,
though i do appreciate your desire to improve the system…
Indeed. That’s why I’ve set up the tracking-cvs repository. As I get the
release-engineering stuff ironed out, that sound become a reasonable option
for just about anybody.
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.