Quantcast
Channel: OTRS Community Blog » OTRS Tips & Tricks
Viewing all 11 articles
Browse latest View live
↧

OTRS Tips & Tricks: Notification Tags

June 14, 2011, 11:27 am
$
0
0

While working with response templates, automatic replies, or email notifications based on certain ticket events, you may want to work with several ticket attributes, like the ticket status, priority and so on.

For that purpose OTRS uses a placeholder mechanism called Notification tags, which you can simply add to your response templates, and OTRS will replace them automatically and use the current value of a certain attribute.
General OTRS environmental attributes

<OTRS_CONFIG_HttpType>
This tag reads from the SysConfig whether plain HTTP or HTTPS is used and returns one of these values

<OTRS_CONFIG_FQDN>
This tag returns the Fully Qualified Domain Name as defined in your SysConfig
OTRS Ticket attributes

<OTRS_TICKET_TicketNumber>
Return the Ticket number of the current ticket. If you?re using this tag, please keep in mind that the Ticket number does not contain the Ticket Hook, for example Ticket# but only the Ticket number!

<OTRS_TICKET_TicketID>
This return the ID of the Ticket as given by your application database. Please notice that the OTRS front-ends mainly operate with the Ticket number rather than with the Ticket ID.

<OTRS_TICKET_Title>
Contains the Title of the ticket. Most likely the Ticket Title will become the subject of the first Ticket article. If you add [xy] to this tag, OTRS will shorten the title to xy chars.

<OTRS_TICKET_Queue>
This tag returns the queue the Ticket resides in.

<OTRS_TICKET_QueueID>
The Queue ID is the ID a given by the  application database

<OTRS_TICKET_State>
If you want to propagate the current Status of a Ticket, you can use this tag.

<OTRS_TICKET_StateType>
The State Type reflects the type of the current Ticket according to your OTRS configuration. Valid types are for example open, closed, pending, pending auto

<OTRS_TICKET_Priority>
Returns the Priority of the current Ticket as defined in your OTRS configuration.

<OTRS_TICKET_PriorityID>
The Priority ID contains the ID as given by your application database.

<OTRS_TICKET_Lock>
Returns if the current Ticket is “locked” or “unlocked”

<OTRS_TICKET_LockID>
The Lock ID returns the ID of  “locked” or “unlocked” according to your OTRS application database

<OTRS_TICKET_Owner>
This tag returns the current Owner / Agent this Ticket is assigned to

<OTRS_TICKET_OwnerID>
Returns the User ID of the Owner of this Ticket

<OTRS_TICKET_CustomerID>
This Tag returns the Customer ID of the current Customer this Tickets is assigned to. This value is queried from your Customer Database.

<OTRS_TICKET_CustomerUserID>
This tag returns the username of a Customer as given by your Customer Database.

<OTRS_TICKET_Created>
Returns the creation date of the Ticket in the format YYYY-MM-DD HH:MM:SS

<OTRS_TICKET_Changed>
Returns the date when Ticket was changed the last time in the format YYYY-MM-DD HH:MM:SS

<OTRS_TICKET_TicketFreeKey1>
This tag is available for all Ticket Free Keys  1-16. Simply change the suffix to the according number of the Free Key you want to refer to.

<OTRS_TICKET_TicketFreeText1>
This tag is available for all Ticket Free Text Fields  1-16. Simply change the suffix to the according number of the Free Key you want to refer to.

<OTRS_TICKET_TicketFreeTime1>
This tag is available for all Free Time Fields 1-6. Simply change the suffix to the Free Time Field you need.

↧
Search

OTRS Tips & Tricks: Controlling Agent Notifications

July 6, 2011, 11:37 am
$
0
0

When implementing OTRS, you need to consider what activities in OTRS will trigger email notifications to your Agents. You might want to have agent A, who routes incoming requests, only get notified when a new ticket gets created, while Agent B, who responds to the tickets, will get notified when a ticket is moved into their queue and when customers send follow up emails.

You have four types of email notification in OTRS:

  1. New Ticket Notification – triggers an email notification to the selected agent every time a new ticket is created through the customer portal, or an email gets sent to the support address(es) for your system.
  2. Ticket Follow Up Notification – triggers an email to the selected agent if they are assigned or responsible on an existing ticket that receives a follow up email.
  3. Ticket Lock Timeout Notification – triggers a notification email to the selected agent if ‘Unlock timout’ has been set for queue.
  4. Ticket Move Notification – triggers an email to the selected agent when a ticket is moved into one of their queues.

Setting Notifications for Existing Agents

You need to enable email notifications in the agent preferences, and select which Queues each agent will receive notifications for using the “My Queues” selector. You can select queues and email settings by editing an already existing agent (from the Admin / Agent panel), or your agents can do it by clicking their username in the upper right corner.

For your agents to receive email notifications for a given queue, three things must be true:

1) The agent must have group permissions to view that queue, 2) the agent must have that queue selected in “My Queues”, and 3) the agent must have the desired notification preference switched to “Yes”.

Agent preferences view - accessed by clicking your username in the upper right corner.

Agent edit view - accessed by editing agent settings from the Admin / Agent panel.

Setting Notifications for New Agents

  1. Create agent, define username, email, password,
  2. Enable the desired email notifications:
    • New ticket notification
    • Ticket follow up notification
    • Ticket lock timeout notification
    • Ticket move notification
  3. Click submit. This takes you to the group permissions screen. Define agent permissions and click submit.
  4. Go back to the Admin / Agent panel and edit the agent again. you will now see a multi-select called “My Queues”. These are the queues that the agent has permissions into, as defined in step 3. In “My Queues” select the queues that you want the agent to receive notifications for.
↧
↧

OTRS Tips & Tricks: Create a Junk Queue that Deletes Tickets

August 4, 2011, 1:05 pm
$
0
0

Do you get a lot of junk or spam email in your OTRS System? Today we’re going to show how deal with this problem by creating a Junk queue that automatically deletes tickets on a regular basis.

Normally, from the Agent side, OTRS doesn’t allow you to delete tickets. But if you receive heavy spam or other unwanted emails, they can fill up your database and generally clog up the system with useless information.

Directions:

Create a Junk queue:

  1. From Admin panel / Queues, add a queue named “Junk”.
  2. Set “Follow up Option” to “reject”. This will make it so that any replies sent to tickets in the Junk queue get rejected by the system. 
  3. Submit.                                      

 Create a GenericAgent Job to delete tickets:

  1. From Admin panel / GenericAgent, add a job named “Delete Junk Tickets”.
  2. Set how often the job should run by selecting at least one time from each of the three columns “Schedule minutes”,  “Schedule hours”, and “Schedule days”. If we wanted the job to run at noon every Monday, we’d select “00″ in minutes, “12″ in hours, and “Mon” in days. To have the job run every 10 minutes, select all options in each column.
  3. Under the “Ticket Filter” section, select the Junk queue you just created. This GenericAgent job will deletes all tickets in the selected queue(s), so be sure you have the right one selected!
  4. Under the “Ticket Commands” section set “Delete tickets” to “Yes”.
  5. Save.                                            
  6. You’ll see a list of all tickets affected by the job you just created. Click “Run Job” to delete tickets immediately or just navigate away to let the schedule run. Remember: deleting tickets is permanent and cannot be undone!
↧

OTRS Tips & Tricks: Agent Permissions – Roles and Groups

September 9, 2011, 1:19 pm
$
0
0

OTRS offers two levels of control over agent permissions: Groups and Roles.

When you create an agent in OTRS, you have to define a set of permissions for that agent so they can begin using the system. After creating a new agent, you’re automatically sent to the Agents <-> Groups dialog for that agent. Here you can connect the agent into existing groups to create the permissions for the agent. OTRS automatically creates these groups by default:

  • admin – gives the agent full access to the admin panel
  • stats – gives the agent full access to the Statistics panel
  • users – gives the agent full access to the Customers panel

Groups will also be automatically created for additional modules you add to your OTRS System. You may also choose to create separate groups for your queues.

It’s possible to fully define agent permissions using the Agents <-> Groups dialog, and when you have just 2-3 agents and a few queues, this presents no problems. However, there are times when you need to set up OTRS for larger organizations, with tens or hundreds of agents and queues. In this situation, you don’t want to be defining group permissions for each agent by hand.

This is where roles come in. Let’s say you have five different types of people who will be using the system. The people are Administrators, Customer Service Agents, Technical Support, Engineers, and R&D. We can define roles that include the appropriate permissions for each set of people, and then using the Agents <-> Roles dialog, you can connect each person into the appropriate role with just one click.

Another benefit of using roles is that when you change queues, or create new queues, you only have to update the role permissions, instead of having to update each individual agent. See the image below for a visual representation of the difference between using groups and roles:

Directions:

Agents <-> Groups

To set permissions using the Agents <-> Groups method, create your agents via the Admin / Agents dialog. After clicking submit on the agent creation dialog you’ll be directed to the Agents <-> Groups screen, where you can define group permissions for each agent.

Agents <-> Roles

To set permissions using the Agents <-> Roles method, create the roles you need from the Admin / Roles panel. After creating the roles, go to Admin / Roles <-> Groups, this is where you define permissions for each role. Once you have defined your role permissions, go to Admin / Roles <-> Agents to easily connect your agents into the desired roles.

↧

OTRS Tips & Tricks: Ticket Escalations Part One – Queue Based Escalations

September 22, 2011, 1:28 pm
$
0
0

OTRS offers two ways to control ticket escalations: Queue based escalations, and SLA based escalations. Today we’re going to look at setting up queue based escalations.

Escalations are defined by setting a time limit by which your agents must respond to a ticket – if the ticket is not responded to or updated appropriately, it will escalate. When a ticket escalates, a few things happen:

  • The ticket appears in the Escalated Tickets window of the Dashboard, making escalated tickets highly visible even if the agent has not seen the email notification.
  • If the ticket is locked to an agent, the system unlocks it so that other agents can take action on the ticket.

Queue based escalations are excellent when you receives high priority requests from your customers that need to answered in a consistent and timely manner. When you set up queue based escalations, remember that ALL tickets in that queue will be affected by the escalation rules.

Directions:

Navigate to the Admin / Queues dialog, and select a queue that you would like to set up with escalations. You’ll see three fields that will be used to control escalation times:

Escalation – first response time: Applies to new tickets only. If the first response time is reached and no email or phone contact has been logged, the ticket is escalated.

Escalation – update time:  If an article is added, such as a follow-up by email or the customer portal, the escalation update time is reset. If there is no customer contact, either email or phone, added to a ticket before the update time is reached, the ticket is escalated.

Escalation – solution time: If the ticket state is not set to ‘closed’ before the solution time is reached, the ticket is escalated.

Escalation times are set in minutes, so if you want tickets to escalate after 2 hours, enter 120 into the appropriate field. To disable escalations, set the appropriate field to 0.

Create a Calendar: After setting up your escalation times, you have the option to choose a calendar to use for the escalations. Calendars define when the escalations can actually happen. For example, you can limit escalations to just business hours, so that tickets won’t continue to escalate. If you don’t define a calendar, tickets will escalate Mon-Fri, 8am-8pm, based on the default system calendar (as defined in SysConfig -> Framework -> Core::Time). The Calender selector is near the bottom of the queue dialog:

To edit the calender you want to use, go to Admin / SysConfig and search for ‘Calendar’. In the search results you’ll see Core::Time::Calender1, Core::Time::Calender2, etc. Edit one of these calendars to define the active escalation hours. When you’re done, click ‘Submit’, and make sure the correct calendar is selected in the queue where you defined your escalation times.

↧
↧

OTRS Tips & Tricks: Ticket Escalations Part Two – SLA Based Escalations

October 17, 2011, 1:32 pm
$
0
0

In our last Tips & Tricks article we looked at setting up queue based escalations. This week we’re going to look at setting up SLA based escalations.

Escalations are defined by setting a time limit by which your agents must respond to a ticket – if the ticket is not responded to or updated appropriately, it will escalate. When a ticket escalates, a few things happen:

  • The ticket appears in the Escalated Tickets window of the Dashboard, making escalated tickets highly visible even if the agent has not seen the email notification.
  • If the ticket is locked to an agent, the system unlocks it so that other agents can take action on the ticket.

SLA based escalations work in conjunction with Services, which in turn work in conjunction with Customers.

Let’s say that ACME Inc. is a new customer of ours and we will be providing them several services. One of these services is called High Priority Service. In our OTRS system, we have previously created High Priority Service and connected it to High Priority SLA to define escalation times. Now all we have to do is connect High Priority Service to the Customer record for each person from ACME Inc. who will be able to submit tickets.

If an individual from ACME Inc. creates a ticket through the customer portal, they will be able to choose through dropdown menus which Service and SLA apply to the ticket.

If an individual from ACME Inc. sends an email ticket, OTRS will recognize the Customer based on email address, but an internal agent will have to associate the correct service with the Ticket. Alternately, PostMaster Filters can be configured to set the Service and SLA based on a subject or body search.

If an individual from ACME Inc. opens a ticket via phone, the agent handling the phone call will be able to select the appropriate Service and SLA once they identify the Customer.

This example uses a B2B scenario, but the system works just as well in a B2C scenario, because tickets get created by individuals, not organizations. In OTRS, Customer records represent individuals. If you want to link all of the Customers to an organization, use the CustomerID field as the common field. In our example above, the CustomerID field for each individual would contain ‘ACME Inc.’.

Directions:

Define your Services: Navigate to the Admin / Services dialog, and define your service catalog; sub services are supported. We’ll connect Services with SLAs in the next step.

Define your SLAs: Navigate to the Admin / Service Level Agreements dialog, and define your SLAs. In this step, you need to select which Services the SLA will apply to. In the screenshot below you can see that the Security SLA we are creating applies to Security, Security::Access Control, and three other services. The ‘::’ indicates a sub service:

  • Escalation – first response time: Applies to new tickets only. If the first response time is reached and no email or phone contact has been logged, the ticket is escalated.
  • Escalation – update time:  If an article is added, such as a follow-up by email or the customer portal, the escalation update time is reset. If there is no customer contact, either email or phone, added to a ticket before the update time is reached, the ticket is escalated.
  • Escalation – solution time: If the ticket state is not set to ‘closed’ before the solution time is reached, the ticket is escalated.
  • Escalation times are set in minutes, so if you want tickets to escalate after 2 hours, enter 120 into the appropriate field. To disable escalations, set the appropriate field to 0.
  • Notify by – define when the system sends escalation ‘warning’ emails, that tell Agents a ticket will escalate soon. These are sent based on a percentage of the escalation time; if you set the escalation time to 120, and Notify by to 50%, an escalation warning email will get sent after 60 minutes. If you don’t want escalation warnings, leave the field blank. To use this feature, you must enable escalation notification emails in the GenericAgent.pm file (see below).

Enable Escalation Notification Emails: enabling escalation notifications causes an email to get sent for every ticket that escalates, and enables the sending of warning emails (defined above).

Who will receive the notifications: all agents who have at least read permission into the queue which contains the escalated ticket, and who also have that queue selected in their My Queues dialog. To learn more about agent notifications, see this article.

To enable escalation notifications, edit GenericAgent.pm located at /opt/otrs/Kernal/Config, and un-comment these lines:


When you’re done it should look like this:


Create a Calendar: You have the option to choose a calendar to use for the escalations. Calendars define when the escalations can actually happen. For example, you can limit escalations to just business hours, so that tickets won’t continue to escalate during off hours. If you don’t define a calendar, tickets will escalate Mon-Fri, 8am-8pm, based on the default system calendar (as defined in SysConfig -> Framework -> Core::Time). In the screenshot above you can see that we have defined and selected Calender 2 for 24/7 escalations.

To edit calenders, go to Admin / SysConfig and search for ‘Calendar’. In the search results you’ll see Core::Time::Calender1, Core::Time::Calender2, etc. Edit one of these calendars to define the active escalation hours. When you’re done, click ‘Submit’.

Connect your Customers: Once you have defined your Services and SLAs, you need to create Customers via Admin / Customers, and then connect each customer to the appropriate service via Admin / Customers <-> Services. From the Customers <-> Services panel, you can connect individual services to each customer, or you can define which services will be available to all customers by default by clicking ‘Edit default services’.

↧

OTRS Tips & Tricks: Managing Response Templates in OTRS

November 17, 2011, 12:38 pm
$
0
0

OTRS allows you to create Response templates, predefined messages that are linked to specific queues, which can be easily selected by agents when delivering a response to a customer. Response templates can significantly increase the speed of service delivered by your help desk agents.

If you’re using OTRS and you haven’t yet configured Response templates, here are a few questions in order to determine if they will be helpful in your help desk environment:

  • Do your help desk agents regularly send the same type of message to different customers?
  • Do your help desk agents regularly send the same attachments to different customers?
  • Does your help desk generate enough requests to make Response templates helpful?

Response templates are very easy to configure in OTRS; continue reading for step by step directions.

Directions

Create your Response templates:

Navigate to the Admin /  Responses dialog:

Click “Add response”

This will take you to the Add Response screen, where you define the name and body text of your Response template.

The Response template “Name” field is required, and will appear to your agents in the Ticket view ”Reply” dropdown. It will not be visible to your customers. The body text, or ”Response” field can be left blank to create an empty reply, or populated with your desired message.

When defining the body text of your Response template, you can use OTRS notification tags to insert information into the ticket. This reference is also available if you scroll to the bottom of the Add Response screen:

<OTRS_OWNER_*>
Ticket owner options (e. g. <OTRS_OWNER_UserFirstname>).

<OTRS_RESPONSIBLE_*>
Ticket responsible options (e. g. <OTRS_RESPONSIBLE_UserFirstname>).

<OTRS_CURRENT_*>
Options of the current user who requested this action (e. g. <OTRS_CURRENT_UserFirstname>).

<OTRS_TICKET_*>
Options of the ticket data (e. g. <OTRS_TICKET_TicketNumber>, <OTRS_TICKET_TicketID>, <OTRS_TICKET_Queue>, <OTRS_TICKET_State>).

<OTRS_CUSTOMER_DATA_*>
Options of the current customer user data (e. g. <OTRS_CUSTOMER_DATA_UserFirstname>).

<OTRS_CONFIG_*>
Config options (e. g. <OTRS_CONFIG_HttpType>).

For more information about OTRS Notification tags, see this article.

 

Connect your Response templates to Queues:

Navigate to the Admin / Responses <-> Queues dialog:

From the Response <-> Queues overview screen, select one of your created responses from the list:

Select the Queues that you want this Response to be available in:

Result:

Now when you navigate to an existing ticket in one of the Queues selected for the your new Response template, you will see the template in the “Reply” dropdown:

Note that you must have an external type article selected for the “Reply” dropdown to appear – Response templates cannot be used with internal type articles.

The next Tips & Tricks article focuses on creating pre-defined attachments for your Response templates.

↧

OTRS Tips & Tricks: Response Salutations, Signatures, and Attachments

December 28, 2011, 12:47 pm
$
0
0

In the last Tips & Tricks article, we looked at creating response templates and connecting them to specific queues. Today we’re going to look at how salutations, signatures, and attachments relate to responses in OTRS.

When you reply to a customer through the OTRS agent interface, the system uses a combination of elements to generate the reply. These include:

  • A predefined salutation at the top (i.e. Dear Customer…)
  • A predefined response body in the middle (this can be blank)
  • A predefined signature at the end of the message
  • An optional predefined attachment

The following image shows the reply that gets generated when the agent selects the predefined response ”Email Trouble” in our system. The agent can edit any part of this message on the fly before sending.:

 

Salutations & Signatures

Salutations and signatures are linked to queues in OTRS. This allows a unique greeting and signature for each queue (e.g. your service desk queue and your level 2 support queue are probably going to require different signatures.). If the initial email from the customer included first and last name information, this can be inserted into the salutation using notification tags. The system can also insert the name of the agent who is creating the reply into the signature.

 

Responses & Attachements

As we saw in the last article, when you define a response and connect it to a queue, it becomes available as a reply option on “external” type articles in a ticket. Predefined attachments in OTRS are linked to responses.

Now that we can see how these elements are related, let’s configure our salutations, signatures, and attachments.

Directions

Salutations

Navigate to the Admin /  Salutations dialog:

Click “Add salutation”:

This will take you to the new salutation screen, where you define the name and content of your salutation. You will probably want to use the notification tag <OTRS_CUSTOMER_REALNAME> – this will use the customer name from the email X-Headers, and if no name is available, it will insert the email address of the customer. The best practice for salutations is to keep it short and simple. Use your response templates for including further information about the ticket to the customer:

Navigate to Admin / Queues and edit each queue that you want to connect your new salutation to. Note: You can also edit the system standard salutation, which will allow you to bypass the this step, as the system standard is selected in each queue by default:

 

Signatures

Navigate to the Admin / Signatures dialog:

Click “Add signature”:

This will take you to the new signature screen, where you define the name and content of the signature. Remember that signatures are linked to queues, not individual agents. Take advantage of the notification tags <OTRS_Agent_UserFirstname> and <OTRS_Agent_UserLastname> to insert the appropriate agent name into each reply:

Navigate to Admin / Queues and edit each queue that you want to connect your new signature to. Note: You can also edit the system standard signature, which will allow you to bypass the this step, as the system standard is selected in each queue by default:

 

Attachments

Navigate to the Admin / Attachments dialog:

Click “Add attachment”:

This will take you to the new attachment screen, where you define the name and upload the attachment. Each attachment can only contain one file. (Max attachment size is 16 MB by default – this can be configured via the WebMaxFileUpload setting in Config Options: Framework -> Core::Web, however it is not advisable to send files bigger than 16 MB as most email servers will reject them):

Once you save the attachment, you need to connect it with a response. Navigate to Admin / Attachments <-> Responses:

Select the new attachment you created:

Select the responses that you want the attachment automatically connected to:

Now when you select the appropriate response template in the agent frontend, the attachment will automatically be included.

↧
Search

OTRS Tips & Tricks: Custom Branding the Customer Portal

March 16, 2012, 3:36 pm
$
0
0

Today we’re going look at how to quickly add custom branding to the customer portal of your OTRS Help Desk.

By default, the customer portal has the OTRS logo:

How to change the Customer Portal logo

Navigate to the Admin / SysConfig dialog:

Search for “logo”:

From the search results, select “Frontend::Customer”:

Enable the “CustomerLogo” checkbox:

Replace the URL with the web address of your logo image file. You can place the logo in the ‘skins’ directory on your OTRS server, or link to a 3rd party file. Use the style rules to tweak the position of the logo. The optimal size is 135×50 pixels:

Scroll to the bottom of the page and click “Update”:

Your OTRS customer portal will now show your custom logo:

↧
↧

Tweaking the Richtext Editor

October 1, 2012, 5:47 pm
$
0
0

OTRS uses the CKEditor for editing richtext in tickets, Changes, FAQs and other input fields. Typically customers ask for some features which are not switched on by default. An easy way for creating and editing HTML tables is one of them.

As there is no config setting in OTRS yet I will show a small hack to get an enhanced toolbar with some additional features and a different grouping of the items. The features I added are:

  • Table
  • Search & Replace
  • Select All
  • Subscript and Superscript
  • Show Blocks
  • Paste as Text and Paste From Word

After the modifications the CKEditor Full Toolbar looks like this

And the Simple Toolbar like this

In OTRS 3.1 you need to edit the file Kernel/Output/HTML/Standard/RichTextEditor.dtl where the toolbar is declared for ticket actions (RichText.ToolbarFull) and other like change or notifications (ToolbarSimple).  In upcoming OTRS 3.2 you can place the file in the Custom directory which will be more convenient on updates.

The code needs to be changed as follows

Core.Config.Set('RichText.ToolbarFull', [
['Bold', 'Italic', 'Underline', 'Strike', 'Subscript','Superscript' ],
['NumberedList', 'BulletedList', 'Table', 'Image', 'HorizontalRule', 'PasteText','PasteFromWord'],
['Outdent', 'Indent', '-', 'JustifyLeft', 'Justif yCenter', 'JustifyRight', 'JustifyBlock'],
['Link', 'Unlink'], 
['Find', 'Replace'],
['SpellCheck'], 
'/',
['Format', 'Font', 'FontSize', '-', 'TextColor', 'BGColor'],
['Undo', 'Redo', 'SelectAll', 'RemoveFormat'],
['ShowBlocks', 'Source', ]
   ]);
Core.Config.Set('RichText.ToolbarSimple', [
['Bold', 'Italic', 'Underline', 'Strike', 'Subscript','Superscript' ],
['NumberedList', 'BulletedList', 'Table', 'HorizontalRule','PasteText','PasteFromWord'],
['Outdent', 'Indent', '-', 'JustifyLeft', 'JustifyCenter',  'JustifyRight', 'JustifyBlock'],
['Link', 'Unlink'],
['Find', 'Replace'],
['SpellCheck'], 
'/', 
['Format', 'Font', 'FontSize', '-', 'TextColor', 'BGColor'],
['Undo', 'Redo', 'SelectAll', 'RemoveFormat'],
['ShowBlocks', 'Source', ]
    ]);
↧

About OTRS, MySQL, MyISAM and InnoDB storage engines

February 20, 2013, 1:48 am
$
0
0

The most popular database for use with OTRS is MySQL. This database comes with multiple different storage engines, the most prominent are MyISAM and the more modern InnoDB. That last storage engine is also faster and more reliable than MyISAM.

Recently we found some OTRS users running into issues because they had tables using different storage types in their database. This mostly happens because the friendly MySQL people changed the default storage engine from MyISAM to InnoDB with their version 5.5. So for instance, if you would upgrade your server from Ubuntu 10.04 to 12.04, MySQL would be upgraded from 5.1 to 5.5. This causes the default storage engine to change, but the upgrade would keep your existing tables in tact. Now when you want to create new table, for instance when you are upgrading OTRS or installing a module such as ITSM you can get an error message like this:

ERROR 1025 (HY000) at line 25: Error on rename of './otrs/#sql-143c_22' to
'./otrs/article_flag' (errno: 150)

To prevent this, we now have added a test to our database check script (and to the support module) that will notice this issue. We updated the upgrade instructions to let you run the check script before attempting the upgrade. Below is the output:

$ bin/otrs.CheckDB.pl
Trying to connect to database
DSN: DBI:mysql:database=otrs-demo;host=localhost;
DatabaseUser: root

Connected.
Your storage engine is InnoDB.
These tables use a different storage engine:

article
article_attachment
...
virtual_fs_preferences
web_upload_cache
xml_storage

 *** Please correct these problems! ***

In this case, in the output above, all tables had a different storage engine.Starting OTRS 3.2.2, we supply a script to upgrade your tables to InnoDB. Note that we only ‘upgrade’ from MyISAM to InnoDB, not the other way around. If your database is huge, you might want to schedule enough downtime for this operation. The only real way to know how much time this operation will take is to try it, so if you have a test environment, please try it there first. Of course you should also have a backup handy for just in case.

You can check for the database size in the support module, there you can also see the default storage engine and any tables that might have a different storage engine. See below:

Support Module checksAnd here is the procedure to change your database tables:

$ bin/otrs.MySQLInnoDBSwitch.pl
This will change the table type of your database tables to InnoDB.
Only run this if you know what you are doing, and if there is no load on the DB server.
This operation can take lots of time.
Please type "yes" to confirm.
yes
120 tables need to be converted.
Changing table article to engine InnoDB
Changing table article_attachment to engine InnoDB
Changing table article_flag to engine InnoDB
...
Done
↧
Viewing all 11 articles
Browse latest View live
Search