Customizing states

Every state has a name (status-name) and a status type (status-type). The name of a state can be anything you want and can you can specify this via the admin area of OTRS in the section for states. The state types can not be changed via the web interface, the database has to be modified if you'd want to add new types or if the name of types has to be changed. We would generally recommend not to modify the default state types as this can cause unexpected results. For instance escalation calculations and the unlock feature are based on certain state types.

In the section for states in the admin area of OTRS the name of already existing states can be changed or new states can be added. If the state "new" has been changed via the web interface, this change also has to be configured via the config file Kernel/Config.pm or via the SysConfig interface. The following settings have to be modified to ensure that OTRS works with the changed state for "new":

    [...]
    # PostmasterDefaultState
    # (The default state of new tickets.) [default: new]
    $Self->{PostmasterDefaultState} = 'new';

    # CustomerDefaultState
    # (default state of new customer tickets)
    $Self->{CustomerDefaultState} = 'new';
    [...]

If a new state type should be added the ticket_state_type table in the OTRS database needs to be modified with a database client program.

linux:~# mysql -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 23 to server version: 5.0.16-Debian_1-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use otrs;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> insert into ticket_state_type (name,comments) values ('own','Own
state type');
Query OK, 1 row affected (0.00 sec)

mysql> quit
Bye
linux:~#

Now it is possible to use the new state type you just created in the section for states in the admin area. After a state has been linked with this new state type also the configuration of OTRS has to be changed to ensure that the new state is used. Just modify the following options via SysConfig:

Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateDefault - to define the default next state for new phone tickets.

Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateType - to define the available next states for new phone tickets.

Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateDefault - to define the default next state for new email tickets.

Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateType - to define the available next states for new email tickets.

Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound > AgentTicketPhoneOutbound###State - to define the default next status for new phone articles.

Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound > AgentTicketPhoneOutbound###StateType - to define the available next statuses for new phone articles you can here define the status types.

Ticket:Frontend::Agent::Ticket::ViewMove:Ticket::DefaultNextMoveStateType - to define the available next statuses in the AgentTicketMove screen you can here define the status types.

Ticket -> Frontend::Agent::Ticket::ViewBounce > StateDefault - to define the default next state after bouncing a ticket.

Ticket -> Frontend::Agent::Ticket::ViewBounce > StateType - to define the available next statuses in the bounce screen you can here define the status types.

Ticket -> Frontend::Agent::Ticket::ViewBulk > StateDefault - to define the default next status in a bulk action.

Ticket -> Frontend::Agent::Ticket::ViewBulk > StateType - to define the available next statuses in the bulk action screen you can here define the status types.

Ticket -> Frontend::Agent::Ticket::ViewClose > StateDefault - to define the default next status in a close action.

Ticket -> Frontend::Agent::Ticket::ViewClose > StateType - to define the available next statuses in the close screen you can here define the status types.

Ticket -> Frontend::Agent::Ticket::ViewCompose > StateDefault - to define the default next status in the Compose (reply) screen.

Ticket -> Frontend::Agent::Ticket::ViewCompose > StateType - to define the available next statuses in the Compose (reply) screen you can here define the status types.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - to define the default next status in a Forward action.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - to define the available next statuses in the Forward screen you can here define the status types.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - to define the default next status in a Forward action.

Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - to define the available next statuses in the Forward screen you can here define the status types.

Ticket -> Core::PostMaster > PostmasterDefaultState - to define the status of tickets created from emails.

Ticket -> Core::PostMaster > PostmasterFollowUpState - to define the status of tickets after a follow-up has been received.

Ticket -> Core::PostMaster > PostmasterFollowUpStateClosed - to define the status of tickets after a follow-up has been received and the ticket was closed already.

Ticket -> Core::Ticket > ViewableStateType - to define the status types that are displayed at various places in the system, for instance in the Queueview.

Ticket -> Core::Ticket > UnlockStateType - to define the state types for unlocked tickets.

Ticket -> Core::Ticket > PendingReminderStateType - to define the state type for reminder tickets.

Ticket -> Core::Ticket > PendingAutoStateType - to define the state type for Pending Auto tickets.

Ticket -> Core::Ticket > StateAfterPending - to define the state a ticket is set to after the Pending Auto timer of the configured state has been expired.