Some functions in OTRS, like escalations and automatic unlocking of tickets, depend on a proper configuration of business hours, time zones and holidays. You can define these via the SysConfig interface, in Core::Time. You can also specify different sets of business hours, holidays and time zones as separate 'Calendars' in Core::Time::Calendar1 through Core::Time::Calendar9. Calendars can be defined by queue settings, or on SLA levels. This means that, for example, you can specify a calendar with 5 x 8 business hours for your 'standard' SLA, but create a separate calendar with 7 x 24 support for your 'gold' SLA; as well as set a calendar for your 'Support-USA' queue with a different time window than your 'Support-Japan' queue. OTRS can handle up to 99 different calendars.
OTRS needs to know which time zone should be used to store date and time related data in the database. You can set this in Core::Time:OTRSTimeZone.
The default is UTC and if you set up a new OTRS it is strongly recommended to leave it at this. If you updated from an OTRS older than version 6, you must ensure that OTRSTimeZone is being set to a time zone that matches your previous setup. Otherwise new data will be stored with a different time zone than your existing data.
Once you decided on a time zone and data was stored (tickets, etc.), you shouldn't change the time zone anymore because otherwise you would end up with data stored in different time zones.
You can set a default time zone for new agents and customer users via Core::Time:UserDefaultTimeZone. This time zone will be used for all users that don't have selected a time zone in their preferences.
Set up the working hours for your system in SysConfig Core::Time:TimeWorkingHours, or for your specific calendar in the calendar's configuration. OTRS can handle a granularity of one hour. Checking the marks in the boxes 8, 9, 10 ... 17 corresponds with business hours of 8:00 AM - 6:00 PM.
Only during business hours can tickets escalate, notifications for escalated and pending tickets be sent, and tickets be unlocked.
Holidays that are on a fixed date every year, such as New Year's Day or the Fourth of July, can be specified in TimeVacationDays, or in the corresponding section for the calendars 1-9.
Tickets will not escalate nor get unlocked on dates defined in TimeVacationDays.
By default, OTRS ships with the German holidays installed.
Holidays such as Easter that do not have a yearly fixed date but instead vary each year, can be specified in TimeVacationDaysOneTime.
Tickets will not escalate and will not be unlocked on dates defined in TimeVacationDaysOneTime.
OTRS does not ship with any One-Time holidays pre-installed. This means that you need to add holidays, such as Easter or Thanksgiving, to the system when configuring OTRS.
Locked tickets can be automatically unlocked by the system. This feature might be useful if, for example, an agent has locked tickets that need to be processed, but he can't work on them for some reason, say because he is out of the office on an emergency. The automated unlock feature unlocks tickets after a given time to ensure that no locked tickets will be forgotten, thereby allowing other agents to process them.
The amount of time before a ticket is unlocked can be specified in the queue settings for every queue. The command bin/otrs.Console.pl Maint::Ticket::Unlock, which is executed periodically as a cron job, performs the automated unlocking of tickets.
Notifications on unlocked tickets are sent out only to those agents that have the queue with the unlocked tickets set in "My queues", and that have activated the notification on unlocked tickets in their personal preferences.
Tickets will be unlocked if all of the following conditions are met:
There is an unlock timeout defined for the queue the ticket is in.
The ticket is set to locked.
The ticket state is open.
The unlock timer will be reset if an agent adds a new external article to the ticket. It can be of any of the following types: email-external, phone, fax, sms, or note-external.
Also, if the last article in the ticket is created by an agent, and a customer adds another one, either via web or email response, the unlock timer will be reset.
The last event that will reset the unlock timer is when the ticket is assigned to another agent.