[ Sent to rt-devel, since it deals with a contributed script. ]
I’m a bit confused; I installed 2.0.8 and the web interface seems to be
working fine. DB connectivity is working fine. I installed enhanced-mailgate
alongside rt-mailgate, updated my .qmail files, and everything is working
fine.
Except that enhanced-mailgate won’t act on any embedded pseudoheaders for
existing tickets. Nor does it look like it should: the code for acting on
existing tickets starts at line 327 of that script. Nowhere in that else {}
clause do the calls to ParseMessageForCommands() or any other
pseudoheader-aware function appear to happen.
I’ve tried all sorts of configurations (with/without $PermitReplayAttacks
for instance; I haven’t tried gpg stuff). But any way you look at it, it
doesn’t ever seem to get to code that can ``take pseudo-headers in the
message body to set parameters on…existing tickets.‘’ (This is evidenced,
partially, by the fact that the pseudoheaders are simply passed as part of
the body of the message.)
What am I missing? What other information can I provide to help debug this?
Thanks,
/pg
Peter Green : root @ DonorWare, LLC : PeterGreen@DonorWare.com
v: 877.751.3300 x413 f: xxx.xxx.xxxx c: xxx.xxx.xxxx
But what can you do with it? – ubiquitous cry from Linux-user partner.
(Submitted by Andy Pearce, ajp@hpopd.pwd.hp.com)
Right around line 207-208. if it’s an action alias, it does what you want.On Wed, Oct 17, 2001 at 11:36:28PM -0600, Peter Green wrote:
[ Sent to rt-devel, since it deals with a contributed script. ]
I’m a bit confused; I installed 2.0.8 and the web interface seems to be
working fine. DB connectivity is working fine. I installed enhanced-mailgate
alongside rt-mailgate, updated my .qmail files, and everything is working
fine.
Except that enhanced-mailgate won’t act on any embedded pseudoheaders for
existing tickets. Nor does it look like it should: the code for acting on
existing tickets starts at line 327 of that script. Nowhere in that else {}
clause do the calls to ParseMessageForCommands() or any other
pseudoheader-aware function appear to happen.
I’ve tried all sorts of configurations (with/without $PermitReplayAttacks
for instance; I haven’t tried gpg stuff). But any way you look at it, it
doesn’t ever seem to get to code that can ``take pseudo-headers in the
message body to set parameters on…existing tickets.‘’ (This is evidenced,
partially, by the fact that the pseudoheaders are simply passed as part of
the body of the message.)
What am I missing? What other information can I provide to help debug this?
Thanks,
/pg
Peter Green : root @ DonorWare, LLC : PeterGreen@DonorWare.com
v: 877.751.3300 x413 f: xxx.xxx.xxxx c: xxx.xxx.xxxx
But what can you do with it? – ubiquitous cry from Linux-user partner.
(Submitted by Andy Pearce, ajp@hpopd.pwd.hp.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.
Right around line 207-208. if it’s an action alias, it does what you want.
I would prefer not to have to use the action alias, since it requires
PGP/GnuPG. Fine for me, maybe not for everyone that will be using this and
(hopefully) updating tickets.
Also, it appears that the action alias doesn’t actually update the ticket
with correspondence or comments, does it? It seems like that would be useful
as well…
Is PGP/GnuPG the only answer for now? If so, is it in the cards for
enhanced-mailgate to support commands in the body without requiring
PGP/GnuPG? (Yeah, it’s probably not the safest idea, what with mail being so
easy to forge…)
Thanks for your quick response!
/pg
Peter Green : root @ DonorWare, LLC : PeterGreen@DonorWare.com
v: 877.751.3300 x413 f: xxx.xxx.xxxx c: xxx.xxx.xxxx
Those who don’t understand Linux are doomed to reinvent it, poorly.
(Unidentified source.)