> > 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 <[EMAIL PROTECTED]> kernzeit AG _______________________________________________ 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 Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/
