In celebration of OTRS 9th birthday *, the community is pleased to publish the following two News/Stories.
User Story IV - Help for hospital
I work in Information Systems for a county hospital and have recently moved the Helpdesk ticketing to OTRS from HEAT. It is a great flexible system.
The one and only thing I miss about HEAT is the ability to put attachments on a user's profile. In OTRS this would be in Customer Management. Currently we have to attach forms for computer systems access to individual tickets for the user. Over time each user gets multiple requests this way and we will have to sort through tickets to find the form. If all forms for a particular person could be attached to their profile in customer management we could attach all forms in one place.
My vision is to have this paper process go away as I've already built the necessary forms in OTRS to facilitate this. Its just a matter of approval from various people in the hospital, but it will be a while before its ready on the adminitrative side and we still have to work.
Thanks for OTRS!
Knowhow I - Tutorial how to create a postmaster filter
by Johannes Nickel
The following Tutorial is based on the SystemMonitoring Package available for OTRS. This package allows OTRS "to read" Nagios emails and start actions on tickets based on their content.
Nagios sends an email
Subject: Server HOST01 DOWN Message: Address: 192.168.1.1 Service: HTTP Status: DOWN
This will create a new Ticket in OTRS. No magic at this point. An email creates a ticket. Works as expected. ;)
After some time Nagios sends a nother email:
Subject: Server HOST01 UP Message: Address: 192.168.1.1 Service: HTTP Status: UP
So the ticket could be closed.
This is where the magic starts. The SystemMonitoring Package "reads" the email and looks for keywords like:
You could specifiy an From-Address where those types of emails came from, so not every email has to be checked.
You could do much more with this module. You can perform (all) Actions on tickets wich are available through the OTRS API. You could perform searches, append new emails to exisiting tickets, create, reopen, close tickets without any manual afford. So very complex workflows are possible.
1) A simple PostMasterFilter in the Admin Interface can`t do this.
So lets say you want to append a new email to an existing ticket or create a ticket if a special value is in it. For example you get status updates for an external process with no ticket# in the subject or the body. Because the emails are generated from a Computer System, not by a human.
In our example we want to have a look on UPS packages.
If a package is on travel we get an email with the subject (in german):
"UPS - Versandbenachrichtigung, Kontrollnummer XXXXXXXX"
If our package is deliverd we get a nother email (in german):
"UPS - Zustellbenachrichtigung, Kontrollnummer XXXXXXXX"
So every new ticket is in a Queue (products on travel) and could be closed if the delivery was successful.
Now... let's have a look at such an automatic email:
The key to identify a process here is the tracking number (Kontrollnummer).
So what should happen when an email from "email@example.com" arrives?
- we have to search for the key (Kontrollnummer) in all open tickets
- FOUND=NO: we have to create a new ticket (regular way) a Ticket is generated with a Number and so on
- FOUND=YES: We have to append the email to the existing ticket and close it. If the subject is our "Closing" Subject (Zustellbenachrichtigung) then we will search for the Key (Kontrollnummer). If we found this key we will append this to our ticket as a note (note-internal) and close it.
Ok. Let's start:
Please Install take a look in the attached archive (CustomPreFilter.zip) In the src folder you'll find 2 Files: (CustomPreFilter.xml, CustomPreFilter.pm) We need those 2 files to generate the OPM later. The XML is the config file, the PM is the "core" filter module.Please do all this on a DEMO System. This modul is for testing purposes only.
First write a Config File for OTRS and save it.
Here you can save the values that you might want to change later.
Here we use:
- SenderType -> is the sender type used from OTRS to save the article
- ArticleType -> is the article type used from OTRS to save the article
- FromAddressrRegeExp -> is the regular expression that should match to the "from address)"
- SubjectOpenRegExp -> is the regular expression that should match the "subject" for a new ticket
- SubjectCloseRegExp -> is the regular expression that should match the "subject" to close a ticket
- CloseActionState -> is the state that the ticket will become when the "SubjectCloseRegExp" matches
<?xml version="1.0" encoding="iso-8859-1" ?> <otrs_config version="1.0" init="Application"> <ConfigItem Name="PostMaster::PreFilterModule###1-CustomPreFilter" Required="0" Valid="1"> <Description Lang="en">Basic mail interface to "read" Mails.</Description> <Description Lang="de">Einfache Schnittstelle um Mails zu "lesen"</Description> <Group>CustomPreFilter</Group> <SubGroup>Core::PostMaster</SubGroup> <Setting> <Hash> <Item Key="Module">Kernel::System::PostMaster::Filter::CustomPreFilter</Item> <Item Key="SenderType">system</Item> <Item Key="ArticleType">note-internal</Item> <Item Key="FromAddressRegExp">firstname.lastname@example.org</Item> <Item Key="SubjectOpenRegExp">UPS - Versandbenachrichtigung, Kontrollnummer </Item> <Item Key="SubjectCloseRegExp">UPS - Zustellbenachrichtigung, Kontrollnummer </Item> <Item Key="CloseActionState">closed successful</Item> </Hash> </Setting> </ConfigItem> </otrs_config>
Later, after the installation of this CustomPreFilter you`ll find those options in the Sysconfig. This method allows you to easyily change some values.
Now we need to write / modify the "core" Filter for our Module. This files is based on SystemMonitoring.pm which is in the SystemMonitoring Package. I renamed the file to "CustomPreFilter.pm" you`ll find it in the ZIP
I wrote comments in the CustomerPreFilter.pm file. With this Comments you it should be clear what each line does. And where you have to change a line to get what you need.
Let's build an OPM:
- Copy the files to (Kernel in OTRS_HOME)
- After this we need a sopm. This is the base for our OPM. An example, redy to use.
<?xml version="1.0" encoding="utf-8" ?> <otrs_package version="1.0"> <Name>CustomPreFilter</Name> <Version>1.0.0</Version> <Framework>2.4.x</Framework> <Vendor>Johannes Nickel</Vendor> <URL>http://www.lotb.de/</URL> <License>GNU GENERAL PUBLIC LICENSE Version 2, June 1991</License> <ChangeLog Version="1.0.0" Date="2011-03-09 10:00:00">Initial.</ChangeLog> <Description Lang="en">A custom mail "reader" using PreFilter</Description> <Description Lang="de">Eine Schnittstelle um Werte aus einer E-Mail zu lesen.</Description> <IntroInstall Type="post" Lang="en" Title="Thank you!">A present brought to you for the 9th birthday of OTRS</IntroInstall> <IntroInstall Type="post" Lang="de" Title="Vielen Dank!">Ein Geschenk zum 9. Geburtstag von OTRS.</IntroInstall> <BuildDate>?</BuildDate> <BuildHost>?</BuildHost> <Filelist> <File Permission="644" Location="Kernel/System/PostMaster/Filter/CustomPreFilter.pm"></File> <File Permission="644" Location="Kernel/Config/Files/CustomPreFilter.xml"></File> </Filelist> </otrs_package>
- Now open the Console, go to OTRS_HOME/bin
shell> cd /OTRS_HOME/bin/
Now enter the following line. This line tells OTRS to build an OPM with the config (sopm) we
build before. The path has to be modifed to your own.
shell> ./opm.pl -a build -p /home/debian/CustomPreFilter/CustomPreFilter.sopm
- Now you can install the OPM and Check everything works as expected.
If you use the OPM that comes with this post you can send a email with the following subject to open a ticket:
"UPS - Versandbenachrichtigung, Kontrollnummer 5678987654"
After this you can send a email with the following subject to close the ticket by the PreFilter:
"UPS - Zustellbenachrichtigung, Kontrollnummer 5678987654"
Johannes Nickel (email@example.com)