As every incoming email generates a new ticket in OTRS Not quite true. Incoming emails that are identified as follow-ups to existing tickets won't create a new ticket, but will in fact be added to the existing one.
Ok, this was already clear to me, but I meant it in combination with the notification of our monitoring server, which does not know anything about any Ticket-IDs, so no follow-ups can be created without any coding-work to do.
I want some integration that the monitoring server does not sends mails, but opens new tickets, inserts follow- ups and also closes tickets (on recovery of a problem, e.g.)
Despite the latter, this weren't a problem. OTRS' core function is to open up tickets on receival of new emails and add follow-ups to existing ones, ie. track tickets.
But therefor I need a stage between the monitoring server which notifies about a problem, a (to code) application which analyses these notifications and holds a state for rewriting the notification- mails, so OTRS can recognize a follow-up.
Closing tickets via email isn't impossible at all, but requires coding.
But GA is a good way for this, isn't it?
- if it is the best way to (mis-)use the GenericAgent for such a job? Strike through the (mis-), as GA is meant for performing tasks like these.
My problem is only that GA is running in cron-mode and not as a daemon which is always running through all incoming mails, e.g. So I need a pre-stage in OTRS again in which all notifications come in and though which OTRS-GA is running and maybe deleting on some defined criterias.
- does the GenericAgent can create new tickets at all, or does the GenericAgent is always based on already existing tickets? No, GA can't, and yes, GA can. GA runs on existing tickets, but you may well run shell scripts from within GA, from within you may send an email which opens up a new ticket, if you want.
Do you mean I create a search pattern in GA on which GA will never find any ticket and then running a shell script? Or would GA not run the script when not finding any existing ticket? Because if it just works when finding a ticket it wouldn't make sense to let GA send a new mail, when a mail was already received by OTRS before...
- should I write a whole OTRS-LowLevel-Module which Depends on your demand. Why not? A maximum of flexibility combines with the highest complexity, though. See below. Btw, what are low-level modules? Or better: what were high- level modules then?
I was thinking of an easy module which maybe can be written already by my person (a non-coder), maybe through a existing, documented framework. Because it would make no sense (or better: it would cost to many ressources) to get a coder who first has to read, under- stand OTRS in all its functions to write a module for our functionality.
No, under seldom circumstances only you should write a thing directly to the DB. Try to prevent it wherever possible.
Ok, thats what I am thinking too about this way ;-)
Use Procmail (or your mail server directly) or the lightweight, but integrated version: OTRS' PostMaster::PreFilterModule capabilities. grep Kernel/Config/Defaults.pm for them. You are allowed to set X-OTRS-headers from within Procmail or the PreFilter modules.
That sounds very good for me!
Maybe I just let the monitoring server write the important
criteria (like system hostname, notification status, into the
X-OTRS-headers). Then the PreFilter would search through these
infos and sorts depending on the X-OTRS-headers and creates a
follow-up or closes a ticket depending on these infos.
Thank you for your very nice input!
Matthias
--
Matthias Eichler