On one hand I don't like the idea of spreading this work away from the OTRS, on the other hand I _don't_ control the mail server. I _could_ do a fetchmail/procmail solution though, if nothing else works.
Yeah. I would do this outside OTRS because it's really a translation function between OTRS and something in the outside world. Neither OTRS or the outside world really needs to know about the translation process (and probably shouldn't in the long run for scalability), and coding dependencies into OTRS for this kind of stuff always tends to be a pain to unwind later when/if the exception customer goes away. Fetchmail/procmail would be a good route to go for implementation if you can't control the mail server - I tend to like to do stuff like this in /etc/aliases so it's easy to find and migrate later, but c'est la vie. Having a ticket id mapping exit (disabled by default) in the base OTRS postmaster code would be worth submitting as a suggestion, though. Or model it on the Nagios integration package - hmm... what if you tinkered with the Nagios integration package and supplied a different regexp that could recognize the incoming reports from your foreign ticketing system? That might work (haven't tried it, but in theory all the code is there to create/match/close incoming tickets based on a pattern).
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
