Weiteres ResponseFormat für z.B. Ticketsystemkopplungen

[maxbacks]

Anpassung durchgeführt mit OTRS 2.3.2

Standardmäßig kann man nur ein einzelnes ResponseFormat konfigurieren, in dem normalerweise der alte Nachrichtentext wiederholt wird. Dies ist für Kunden, die nur per Email kommunizieren sinnvoll, damit diese die Antwort besser zuordnen können.
Möchte man nun aber mit einem Kunden die Ticketsysteme koppeln und den alten Nachrichtentext nicht wiederholen, da diese Information sowieso beim Kunden im Ticketsystem vorhanden ist, muss nun ein zweites ResponseFormat her.

Diese Anpassung möchte ich nun erklären:

1. Neues ResponseFormat in der Config.pm eintragen:

Code: Select all

 $Self->{'Ticket::Frontend::ResponseFormat1'} =  '$QData{"Salutation"}

$QData{"StdResponse"}
';

2. In MySQL eine weitere Zeile in der Tabelle "customer_preferences" eintragen
Hier wird eingestellt, bei welchem Kunden ein anderes Format gewählt wird

Code: Select all

INSERT INTO `customer_preferences` (`user_id`, `preferences_key`, `preferences_value`) VALUES ('maxbacks', 'UserResponseFormat', '1');

3. In <otrs_home>/Kernel/Modules/AgentTicketCompose.pm anpassen
Hier wird entschieden, welches Format gewählt wird. Den Teil "eigene Anpassung" hinter dem "# get response format" einfügen und den Rest bis "# get form id" auskommentieren

Code: Select all

    # get response format

###### selbstanpassung
   if ( $Self->{Subaction} eq ''||'0' ) {
   $Self->{ResponseFormat} = $Self->{ConfigObject}->Get('Ticket::Frontend::ResponseFormat');
   }
   else {
    $Self->{ResponseFormat} = $Self->{ConfigObject}->Get("Ticket::Frontend::ResponseFormat$Self->{Subaction}");
   }
###### ende selbstanpassung
#    $Self->{ResponseFormat} = $Self->{ConfigObject}->Get('Ticket::Frontend::ResponseFormat')
#        || '$Data{"Salutation"}
#$Data{"OrigFrom"} $Text{"wrote"}:
#$Data{"Body"}
#
#$Data{"StdResponse"}
#
#$Data{"Signature"}
#';

    # get form id

4. In <otrs_home>/Kernel/Output/HTML/LayoutTicket.pm anpassen
Hier wird der Link generiert, in dem das jeweilige Format steckt. Nun wieder den Code zwischen "Selbstanpassung" hinter "# get StdResponsesStrg" einfügen, um die Informationen aus der MySQL Tabelle zu holen. Diese Informationen müssen nun durch die Zeile mit " . '<input type="hidden" name="Subaction" value="$NewResponseFormat"/>'" und " . "Subaction=$NewResponseFormat&"" in den Link, bzw. Formular gebracht werden

Code: Select all

      #     # get StdResponsesStrg

###### selbstanpassung
my $SQL = "select customer_preferences.preferences_value from customer_preferences,ticket where ticket.id = $Param{TicketID} and ticket.customer_user_id = customer_preferences.user_id and customer_preferences.preferences_key = 'UserResponseFormat'";
my $NewResponseFormat;
$Self->{DBObject}->Prepare(SQL => $SQL, Limit => 1);
while (my @Row = $Self->{DBObject}->FetchrowArray()) {
    $NewResponseFormat = $Row[0];
}
###### ende selbstanpassung

    if ( $Self->{ConfigObject}->Get('Ticket::Frontend::StdResponsesMode') eq 'Form' ) {

        # build html string
        $Param{StdResponsesStrg}
            .= '<form action="'
            . $Self->{CGIHandle}
            . '" method="post">'
            . '<input type="hidden" name="Action" value="AgentTicketCompose"/>'
            . '<input type="hidden" name="Subaction" value="$NewResponseFormat"/>'
            . '<input type="hidden" name="ArticleID" value="'
            . $Param{ArticleID} . '"/>'
            . '<input type="hidden" name="TicketID" value="'
            . $Param{TicketID} . '"/>'
            . $Self->OptionStrgHashRef(
            Name => 'ResponseID',
            Data => $Param{StdResponsesRef},
            ) . '<input class="button" type="submit" value="$Text{"Compose"}"/></form>';
    }
    else {
        my %StdResponses = %{ $Param{StdResponsesRef} };

        for ( sort { $StdResponses{$a} cmp $StdResponses{$b} } keys %StdResponses ) {

            # build html string
            $Param{StdResponsesStrg}
                .= "\n<li><a href=\"$Self->{Baselink}"
                . "Action=AgentTicketCompose&"
                . "Subaction=$NewResponseFormat&"
 [...]

Fertig

[maxbacks]

Bitte um Hilfe bei der Weiterentwicklung

So wie es jetzt ist, muss jedes weitere Format über die if-Anweisung manuell hinzugefügt werden. Kann mir jemand dabei helfen, die if-Anweisung anzupassen?

Wenn UserResponseFomat != 0 {
nehm $Self->{ConfigObject}->Get('Ticket::Frontend::ResponseFormat[Die nummer, die in der Tabelle steht] ');

gelöst, habe den Beitrag geändert

[Daniel Obee]

Zur Problematik empfehle ich auch mal, das Modul von OTRS anzuschauen: http://www.otrs-forum.de/viewtopic.php?f=21&t=3792

Die Lösung, das Response-Format queueabhängig zu steuern halte ich immer noch für die eleganteste. Müsste man halt für die 2.4 anpassen, was wir bereits in Auftrag gegeben haben.

Gruß
Daniel

[maxbacks]

Danke für den Verweis! Nur dann musst du für gekoppelte Systeme eine eigene Queuestruktur verwenden..

Ich hatte zudem das Problem, dass die Statusmeldungen auch so extrem lang gezogen wurden. Somit habe ich die deutschen Sprachfiles kopiert und für die russischen eingesetzt. Nun konnte ich die Standardbenachrichtigungen des Kunden aufs wesendliche reduzieren und den einen Kunden für die Kopplung zuweisen.

Wie nutzt Ihr die verschiedenen ResponseFormate im Arbeitsablauf, bzw. warum benötigt ihr dieses Feature Queuebasierend?

[Daniel Obee]

Der Bedarf kam bei uns aus einem völlig anderen Bereich. Wir nutzen unser System im 'Großeinsatz' in einem Call Center. Und bei uns gibt es 'Beschwerde'-queues, wo User Verstöße der anderen User über Kontaktformular melden können. Die kommen mit dem Absender des Gemeldeten rein, so dass wir dem gleich den Verstoß und mögliche Folgen mitteilen können.

Wenn wir Mails aus diesen Tickets an den Bösewicht schreiben, wäre es natürlich fatal, würden wir die Ursprungsmail des Melders zitieren. Daher hatten wir das Feature so entwickeln lassen. Zudem können wir für verschiedene Länder die Zitateinleitung sprachlich anpassen. Das schöne ist, dass man - so wie das Feature gebaut ist - ein globales Format hat und dann nur die Ausnahmen neu definieren muss.

Für euren konkreten Anwendungsfall ist es natürlich evtl. sinnvoller, das kundenbasiert zu organisieren, es sei denn, das kommt so selten vor, dass es sich lohnt für den/die Kunden eigene Queues zu haben.

Gruß
Daniel