Forgive me if this is covered somewhere else, I can’t find it.
The command:
%RT SET status 1 open
worked w/ my new RT2 install,
However I am not able to get any of the other commands to work (I am
working off the RT1 mail commands sheet).
Are the RT2 mail commands documented somewhere yet?
Are they implemented yet?
Thanks in advance,
Joshua
Are the RT2 mail commands documented somewhere yet?
Are they implemented yet?
They aren’t implemented, and, according to jesse, not planned for 2.0
release, unless someone else steps in and codes them
-alex
Correct. The reason that the SET OPEN worked is because when RT recieves
mail from an admin, the ticket flips from
“new” to open. :)On Wed, Apr 04, 2001 at 04:04:44PM -0400, Alex Pilosov wrote:
On Wed, 4 Apr 2001, Joshua Johnson wrote:
Are the RT2 mail commands documented somewhere yet?
Are they implemented yet?
They aren’t implemented, and, according to jesse, not planned for 2.0
release, unless someone else steps in and codes them-alex
Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
that’s security the same way that asking for directions to topeka and
being told that a seal is a mammal is informative
-robin@apocalypse.org
Any thoughts on how you would like to implement them Jesse?
I.E. a full perl lexer/parser using an RT grammar running against the first
mime text area??
or
Something more direct
( A bunch of =~'s to call out things?)
or
Something in between the two?
Also,
Is there a particular issue with the web file attachment that kept you from
implementing it sooner? I have done the file upload piece before, however I
assume the issue was not in the actual upload code but somewhere else.
I have very limited time, and I have only been in your code this week so I am
not really well versed, but I would be willing to help where I can if you
have an idea of what you would like done?
Eventually I want to tie this in with an aegis source control tool (using
shell scripts, and the CLI) so I would like to help if I can to accelerate
the integration.
Thanks for all of the hard work–and a wonderful product,
Josh
Joshua Johnson FTL Systems Inc.
Chief Software Eng. Mgr. 1620 Greenview Dr. SW
(PHONE)1.507.288.3154 Rochester, MN 55902
( FAX )1.507.289.1108 USA
www.ftlsystems.com joshua.johnson@ftlsys.comOn Wednesday 04 April 2001 03:00 pm, Jesse wrote:
Correct. The reason that the SET OPEN worked is because when RT receives
mail from an admin, the ticket flips from
“new” to open.On Wed, Apr 04, 2001 at 04:04:44PM -0400, Alex Pilosov wrote:
On Wed, 4 Apr 2001, Joshua Johnson wrote:
Are the RT2 mail commands documented somewhere yet?
Are they implemented yet?
They aren’t implemented, and, according to jesse, not planned for 2.0
release, unless someone else steps in and codes them-alex
Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Any thoughts on how you would like to implement them Jesse?
I.E. a full perl lexer/parser using an RT grammar running against the first
mime text area??
or
Something more direct
( A bunch of =~'s to call out things?)
or
Something in between the two?
I’m not really too picky about how it gets done.
I suspect the message syntax used in RT 1.0 won’t cut it at all.
My real requirements are that it:
be easy for someone with slight-to-moderate programming background
to read and modify.
be clean, well commented code.
have hooks such that that PGP or S/MIME or password or some other auth
could be plugged in
I suspect that “the right thing to do” would be to do the mail-command mode
as a completely seperate tool from the user-mode mail gateway.
Among other things, that would probably speed development and make it
easier for sites to deploy without fear of clobbering their
incoming mail interface. That would also decouple it from the core’s release
schedule, which means that folks won’t have to wait for 2.2 to get a stable
mail command mode 
Also,
Is there a particular issue with the web file attachment that kept you from
implementing it sooner? I have done the file upload piece before, however I
assume the issue was not in the actual upload code but somewhere else.
There were some issues with how to do it in a way that would work with mod_perl
and with the various *CGI interfaces when they got working. And really, it was
less important than getting a stable release out I actually have HTML::Mason
code to implement file upload. it’s just not slated for integration until
after 2.0
I have very limited time, and I have only been in your code this week so I am
not really well versed, but I would be willing to help where I can if you
have an idea of what you would like done?
nodnod If you want to hack on a prototype RT2 mail gateway, that would be
very very cool.
Eventually I want to tie this in with an aegis source control tool (using
shell scripts, and the CLI) so I would like to help if I can to accelerate
the integration.
Oh. that would rock.
Thanks for all of the hard work–and a wonderful product,
No problem. I’m glad it’s useful to you.
Josh
Joshua Johnson FTL Systems Inc.
Chief Software Eng. Mgr. 1620 Greenview Dr. SW
(PHONE)1.507.288.3154 Rochester, MN 55902
( FAX )1.507.289.1108 USA
www.ftlsystems.com joshua.johnson@ftlsys.com
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
that’s security the same way that asking for directions to topeka and
being told that a seal is a mammal is informative
-robin@apocalypse.org
| I suspect that “the right thing to do” would be to do the mail-command
| mode as a completely seperate tool from the user-mode mail gateway.
| Among other things, that would probably speed development and make it
| easier for sites to deploy without fear of clobbering their
| incoming mail interface. That would also decouple it from the core’s
| release schedule, which means that folks won’t have to wait for 2.2 to
| get a stable mail command mode
±–>8
Ideally it would also be possible to use the command mechanism with some
source other than mail as well; I’ve done a little hacking on RT1 to
support commands over authenticated zephyr, but it requires a fairly
complete rewrite of the action mechanism in RT1 so I didn’t get very far on
it. Something which can be fed a random file or a Perl string would be
useful for that.
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]
Hi,
I just upgrade a test installation of RT2 from 1.3.47 to 1.3.70.
Upgrading went smoothly, my existing data is still there, and I
applied the DB change listed in 0000,8000,0000http://lists.fsck.com/pipermail/rt-
devel/2001-April/001065.html with no problem.
Problems occur whenever I hit /Admin/Queues/Modify - Mason
coughs up a lung (see below).
I originally thought that HTML::Mason v1.015 was causing
problems so I reverted back to 1.0 and restarted Apache. No dice;
any attempt to administer queues (view or change settings, or add
queues) throws this error.
I’m not averse to blowing away the current setup - this is a test
installation after all. I don’t know enough about Mason to know
where to start poking at this beast to make it go.
Thoughts?
– Bob
0100,0100,0100System error
while serving rt2.austin.excite.com /Admin/Queues/Modify.html
error while executing /Admin/Queues/Modify.html:
Undefined subroutine &HTML::Mason::Commands::UpdateRecordObject called at /u/rt/rt2/WebRT/data/obj/Admin/Queues/Modify.html line 54, < chunk 45.
HTML::Mason::Request::__ANON__('Undefined subroutine &HTML::Mason::Commands::UpdateRecordObject ...') called at /u/rt/rt2/WebRT/data/obj/Admin/Queues/Modify.html line 54
HTML::Mason::Component::run('HTML::Mason::Component::FileBased=HASH(0xe0db4c)', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', 14, 'Enabled', ...) called at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 657
HTML::Mason::Request::comp1('HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)', 'HTML::Mason::Component::FileBased=HASH(0xe0db4c)', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', 14, ...) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 576
HTML::Mason::Request::comp('HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)', 'HTML::Mason::Component::FileBased=HASH(0xe0db4c)', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', 14, ...) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 310
HTML::Mason::Component::run('HTML::Mason::Component::FileBased=HASH(0xd80948)', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', 14, 'Enabled', ...) called at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 657
HTML::Mason::Request::comp1('HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)', 'HASH(0xdd4094)', 'HTML::Mason::Component::FileBased=HASH(0xd80948)', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', ...) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 582
HTML::Mason::Request::comp('HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)', 'HASH(0xdd4094)', 'HTML::Mason::Component::FileBased=HASH(0xd80948)', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', ...) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 152
eval {...} called at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 152
HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)', '/Admin/Queues/Modify.html', 'CommentAddress', 'boring-comment@rt2.austin.excite.com', 'Name', 'boring', 'DefaultDueIn', 14, ...) called at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm
line 651
HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x8d7d28)', 'Apache=SCALAR(0x4d5f14)', 'HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)', undef) called at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line 322
eval {...} called at /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line 322
HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x8d7d28)', 'Apache=SCALAR(0x4d5f14)') called at /u/rt/rt2/bin/webmux.pl line 144
RT::Mason::handler('Apache=SCALAR(0x4d5f14)') called at /dev/null line 0
eval {...} called at /dev/null line 0
backtrace: /Admin/Queues/Modify.html <<= /autohandler
Sounds like somehow, apache isn’t seeing youyr new Interface/Web.pm.
I’m on a slow link from tokyo right now, so I’m not going to go into more detail, but hopefully that’s a start 
-jOn Sat, Apr 07, 2001 at 03:44:22PM -0500, arclight@jump.net wrote:
Hi,
I just upgrade a test installation of RT2 from 1.3.47 to 1.3.70.
Upgrading went smoothly, my existing data is still there, and I
applied the DB change listed in http://lists.fsck.com/pipermail/rt-
devel/2001-April/001065.html with no problem.Problems occur whenever I hit /Admin/Queues/Modify - Mason coughs up a
lung (see below).I originally thought that HTML::Mason v1.015 was causing problems so I
reverted back to 1.0 and restarted Apache. No dice; any attempt to
administer queues (view or change settings, or add queues) throws this
error.I’m not averse to blowing away the current setup - this is a test
installation after all. I don’t know enough about Mason to know where
to start poking at this beast to make it go.Thoughts?
– Bob
System error
while serving rt2.austin.excite.com /Admin/Queues/Modify.html
error while executing /Admin/Queues/Modify.html:
Undefined subroutine &HTML::Mason::Commands::UpdateRecordObject called
at /u/rt/rt2/WebRT/data/obj/Admin/Queues/Modify.html line 54,
chunk 45.
HTML::Mason::Request::ANON(‘Undefined subroutine
&HTML::Mason::Commands::UpdateRecordObject …’) called at
/u/rt/rt2/WebRT/data/obj/Admin/Queues/Modify.html line 54HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xe0db4c)’,
‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
‘boring’, ‘DefaultDueIn’, 14, ‘Enabled’, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 657HTML::Mason::Request::comp1(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
‘HTML::Mason::Component::FileBased=HASH(0xe0db4c)’, ‘CommentAddress’,
‘boring-comment@rt2.austin.excite.com’, ‘Name’, ‘boring’,
‘DefaultDueIn’, 14, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 576HTML::Mason::Request::comp(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
‘HTML::Mason::Component::FileBased=HASH(0xe0db4c)’, ‘CommentAddress’,
‘boring-comment@rt2.austin.excite.com’, ‘Name’, ‘boring’,
‘DefaultDueIn’, 14, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 310HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xd80948)’,
‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
‘boring’, ‘DefaultDueIn’, 14, ‘Enabled’, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 657HTML::Mason::Request::comp1(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
‘HASH(0xdd4094)’, ‘HTML::Mason::Component::FileBased=HASH(0xd80948)’,
‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
‘boring’, ‘DefaultDueIn’, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 582HTML::Mason::Request::comp(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
‘HASH(0xdd4094)’, ‘HTML::Mason::Component::FileBased=HASH(0xd80948)’,
‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
‘boring’, ‘DefaultDueIn’, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 152
eval {…} called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 152HTML::Mason::Request::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
‘/Admin/Queues/Modify.html’, ‘CommentAddress’,
‘boring-comment@rt2.austin.excite.com’, ‘Name’, ‘boring’,
‘DefaultDueIn’, 14, …) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line
651HTML::Mason::ApacheHandler::handle_request_1(‘HTML::Mason::ApacheHandler=HASH(0x8d7d28)’,
‘Apache=SCALAR(0x4d5f14)’,
‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’, undef) called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line
322
eval {…} called at
/usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line
322HTML::Mason::ApacheHandler::handle_request(‘HTML::Mason::ApacheHandler=HASH(0x8d7d28)’,
‘Apache=SCALAR(0x4d5f14)’) called at /u/rt/rt2/bin/webmux.pl line 144
RT::Mason::handler(‘Apache=SCALAR(0x4d5f14)’) called at
/dev/null line 0
eval {…} called at /dev/null line 0backtrace: /Admin/Queues/Modify.html <= /autohandler
Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
Gur SOV jnagf gb znxr guvf fvt vyyrtny.
hi there!
i had the really really same problem and played many many hours with the
problem on the serverside…
i found out, that following webserverconstellation works stable:
apache-1-3-19 with mod_perl_1.25
if you bind php4 or some other modules in it → it gaves me the same
output as you had…
so verify that you use apache with only mod_perl_1.25 and no! other
modules.
greetings
chrisOn Sun, 8 Apr 2001, Jesse wrote:
*Sounds like somehow, apache isn’t seeing youyr new Interface/Web.pm.
*I’m on a slow link from tokyo right now, so I’m not going to go into more detail, but hopefully that’s a start
-j
*On Sat, Apr 07, 2001 at 03:44:22PM -0500, arclight@jump.net wrote:
*> Hi,
*>
*> I just upgrade a test installation of RT2 from 1.3.47 to 1.3.70.
*> Upgrading went smoothly, my existing data is still there, and I
*> applied the DB change listed in http://lists.fsck.com/pipermail/rt-
*> devel/2001-April/001065.html with no problem.
*>
*> Problems occur whenever I hit /Admin/Queues/Modify - Mason coughs up a
*> lung (see below).
*>
*> I originally thought that HTML::Mason v1.015 was causing problems so I
*> reverted back to 1.0 and restarted Apache. No dice; any attempt to
*> administer queues (view or change settings, or add queues) throws this
*> error.
*>
*> I’m not averse to blowing away the current setup - this is a test
*> installation after all. I don’t know enough about Mason to know where
*> to start poking at this beast to make it go.
*>
*> Thoughts?
*>
*> – Bob
*>
*> System error
*>
*> while serving rt2.austin.excite.com /Admin/Queues/Modify.html
*> error while executing /Admin/Queues/Modify.html:
*> Undefined subroutine &HTML::Mason::Commands::UpdateRecordObject called
*> at /u/rt/rt2/WebRT/data/obj/Admin/Queues/Modify.html line 54,
*> chunk 45.
*> HTML::Mason::Request::ANON(‘Undefined subroutine
*> &HTML::Mason::Commands::UpdateRecordObject …’) called at
*> /u/rt/rt2/WebRT/data/obj/Admin/Queues/Modify.html line 54
*>
*> HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xe0db4c)’,
*> ‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
*> ‘boring’, ‘DefaultDueIn’, 14, ‘Enabled’, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 657
*>
*> HTML::Mason::Request::comp1(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
*> ‘HTML::Mason::Component::FileBased=HASH(0xe0db4c)’, ‘CommentAddress’,
*> ‘boring-comment@rt2.austin.excite.com’, ‘Name’, ‘boring’,
*> ‘DefaultDueIn’, 14, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 576
*>
*> HTML::Mason::Request::comp(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
*> ‘HTML::Mason::Component::FileBased=HASH(0xe0db4c)’, ‘CommentAddress’,
*> ‘boring-comment@rt2.austin.excite.com’, ‘Name’, ‘boring’,
*> ‘DefaultDueIn’, 14, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 310
*>
*> HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0xd80948)’,
*> ‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
*> ‘boring’, ‘DefaultDueIn’, 14, ‘Enabled’, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 657
*>
*> HTML::Mason::Request::comp1(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
*> ‘HASH(0xdd4094)’, ‘HTML::Mason::Component::FileBased=HASH(0xd80948)’,
*> ‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
*> ‘boring’, ‘DefaultDueIn’, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 582
*>
*> HTML::Mason::Request::comp(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
*> ‘HASH(0xdd4094)’, ‘HTML::Mason::Component::FileBased=HASH(0xd80948)’,
*> ‘CommentAddress’, ‘boring-comment@rt2.austin.excite.com’, ‘Name’,
*> ‘boring’, ‘DefaultDueIn’, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 152
*> eval {…} called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/Request.pm line 152
*>
*> HTML::Mason::Request::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’,
*> ‘/Admin/Queues/Modify.html’, ‘CommentAddress’,
*> ‘boring-comment@rt2.austin.excite.com’, ‘Name’, ‘boring’,
*> ‘DefaultDueIn’, 14, …) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line
*> 651
*>
*> HTML::Mason::ApacheHandler::handle_request_1(‘HTML::Mason::ApacheHandler=HASH(0x8d7d28)’,
*> ‘Apache=SCALAR(0x4d5f14)’,
*> ‘HTML::Mason::Request::ApacheHandler=HASH(0xdd4070)’, undef) called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line
*> 322
*> eval {…} called at
*> /usr/local/lib/perl5/site_perl/5.005/HTML/Mason/ApacheHandler.pm line
*> 322
*>
*> HTML::Mason::ApacheHandler::handle_request(‘HTML::Mason::ApacheHandler=HASH(0x8d7d28)’,
*> ‘Apache=SCALAR(0x4d5f14)’) called at /u/rt/rt2/bin/webmux.pl line 144
*> RT::Mason::handler(‘Apache=SCALAR(0x4d5f14)’) called at
*> /dev/null line 0
*> eval {…} called at /dev/null line 0
*>
*> backtrace: /Admin/Queues/Modify.html <= /autohandler
*>
*>
*> _______________________________________________
*> Rt-devel mailing list
*> Rt-devel@lists.fsck.com
*> http://lists.fsck.com/mailman/listinfo/rt-devel
*>
*>
*>
*jesse reed vincent – root@eruditorum.org – jesse@fsck.com
*70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
*Gur SOV jnagf gb znxr guvf fvt vyyrtny.
*Rt-devel mailing list
*Rt-devel@lists.fsck.com
*http://lists.fsck.com/mailman/listinfo/rt-devel