Request Handling in security departments
Jens Bothe11. Dec 2013 | AdministrationConsultingUse cases
The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept.
We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.
OTRS is used in security departments and companies for long time due to the well documented code and some background in the CERT area.
In one of my recent projects the team wanted to simplify some of their processes additional to the main goals of the implemenation project. We decided to start with the authorization process for taking photos inside their business locations. Until now they had a paper based permission process.
So created a small process within OTRS. Now the customer can request a permission in the customer webinterface or by sending a mail to a special email address.
For starting a process from an email you need to create a postmaster filter which points to the process ID and the activity id of the first activity in this process.
The ticket now shows up the in the Dashboard Calendar
and the agent can go through the authorization
This will trigger an automated email via notification event to the customer
In the event based notification we can use the OTRS Notification Tags to access the values of the used dynamic fields.
After the photos are taken the user needs to send them to the ticket so an agent can approve or deny the publishing of the photo.
For building this process we need:
- several dynamic fields as shown below
- an event based notification on authorized request
- an event based notification on non authorized request
- an event based notification on approval or denying the publishing request
- a process
- a post master filter as shown on top
- some ACL rules to make it smooth
The export can be found here (remove the .txt if needed): Export_ProcessEntityID_P5.yml
You should also add an ACL to remove closed states on sending replies or forwarding.
Small process designs like this one can really increase the acceptance of your system in simple way. Just start to imagine which processes might fit for you!
Jens Bothe at 20.03.2018, 14:44
Hi, I suggest to visit an admin training or get professional services as this is not a support forum. Please contact email@example.com
Sophea at 20.03.2018, 10:48
Hello Sir, I am a new experience with OTRS. I have created a workflow (Process management) as the following: 1 - Activity1, Activity2, Activity3, Acitivity4 which all activities are assigned to each its appropriate queues (example: sale , admin, manager, supplier ...). 2 - All workflows are working correctly but each users still able to process to another step. I mean user in Activity1 should not be able access / process to another activities instead of. Regards, Sophea