Hallo,

beim Laden des OTRS ReferenceIDoitObjects Modul über die Schaltfläche "Referenzierte Objekte in i-doit" wird im sich anschließend öffnenden Fenster die Tabelle/Tabs mit den I-DoIT Elementen nicht angezeigt. im Browser kommt der Javascript Fehler, dass das Object .dataTable nicht initialisiert sei.

Das Problem ist, dass in der Config (/opt/otrs/Kernel/Config/Files/ReferenceIDoitObjects.xml) des Moduls zwei Javascript Module verlangt werden:

<configitem name="Frontend::Module###AgentReferenceIDoitObjects" required="1" valid="1" configlevel="200">[…]
                <loader><css>ReferenceIDoitObjects.css</css>
                    <css>ui-theme/demo_table_jui.css</css>
                    <css>ui-theme/demo_table.css</css>
**                    <javascript>thirdparty/jquery-datatables-1.8.2/jquery.dataTables.min.js</javascript>
                    <javascript>thirdparty/jquery-ui-tabs-1.8.18/jquery.ui.tabs.js</javascript>**
                    <javascript>referenceidoitobjects.js</javascript></loader>
[…]</configitem>

Die beiden Dateien jquery.dataTables.min.js und jquery.ui.tabs.js werden aber nicht an den Browser gesendet, so dass die entsprechenden jQuery Typen nicht zur Verfügung stehen und der Fehler bei den DataTables entsteht.

OTRS übergibt die Modulspezifischen Javascript-Dateien nicht explizit sondern schnürt diese in eine einzelne Datei, die dann z.B. ModuleJS_35cc8daeb9b6d0adfdf557adca075a6e.js heißt und in der alle in der Config-Datei unter dem Tag <loader>angegebenen Dateien enthalten sind.

Leider werden diese Dateien aber NICHT mit in die ModuleJS_sdafhsdhfgsd.js Datei gepackt und fehlen.

Hat jemand eine Lösung?</loader>

Hintergrund:

Die Kopplung von I-DoIT mit OTRS erfolgt über das Generic Interface von OTRS, das mit SOAP arbeitet. SOAP übermittelt Benutzername und Kennwort via XML im SOAP-Paket.

OTRS bietet die Möglichkeit, über Single Sign On die Kennwortabfrage mit dem Microsoft Active Directory zu verknüpfen.
In diesem Fall wird der Apache Server so konfiguriert, dass er für OTRS ein HTTP Basic Authentication durchführt und über Kerberos das AD befragt:

In dem Fall sieht suche Apache Config etwa so aus:
    <location otrs="">AllowOverride None
    AuthType Kerberos
    AuthName "OTRS"
    Krb5Keytab /etc/apache2/keytabs/otrsserver.keytab
    KrbAuthRealms MEINE.DOMÄNE
    KrbMethodNegotiate on
    KrbSaveCredentials  off
    KrbMethodK5Passwd on
    Require valid-user
  ….

Eure OTRS-Config sieht so aus:
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@MEINE DOMÄNE;

Problem:

OTRS erwartet bei dieser Konfiguration eine gültige HTTP Basic Authentifizierung (Form Authentifizierung). Die Eingabe von Benutzername und Kennwort in die entsprechenden Eingabefelder der I-DoIT GUI für die Trouble Ticket Konfiguration reicht nicht aus. Es kommt der SOAP-Fehler: Authentifizierung fehlgeschlagen.

Lösung:

Benutzername und Kennwort müssen in der OTRS-URL übergeben werden.

Im I-DoIT GUI:
Administration -> Interfaces/External Data -> TroubleTicketSystem (TTS) -> Configuration

URL incl. Protocol: http://BENUTZERNAME:KENNWORT@otrs.host.name/otrs

Somit wird die Form-Authentifizierung gemacht und anschließend kann I-DoIT das OTRS Generic Interface nutzen.</location>

Fehlerbeschreibung:

Scenario: I-DoIT wird mit OTRS gekoppelt. Beide Applikationen liegen auf unterschiedlichen Servern. Das PHP-Script "i-doit_api_proxy.php" wird verwendet, da der Browser bei Nutzung von OTRS die XHR-Kommunikation im Javascript zu I-DoIT nicht zulässt (Siehe I-DoIT_OTRS-Extension 0.7 README).

Bei erzwungener Nutzung von SSL auf dem I-DoIT Server meckert Curl über nicht vorhandene CA SSL-Zertifikate zur Verifizierung des I-DoIT SSL Zertifikates.
Der Fehler wird nicht angezeigt, da das Script "i-doit_api_proxy.php" mit der heissen Nadel gestrickt wurde Das Script tut dann einfach nichts.

Lösung 1:

Speichern des Public Zertifikates auf dem OTRS-Server im CA-Store (Debian: /etc/ssl/certs),
hab ich nicht ausprobiert…

Lösung 2:

Deaktivieren der Zertifikatsüberprüfung im Script "i-doit_api_proxy.php".
Folgende Zeile bei "curl_setopts" ergänzen:
curl_setopt($l_curl_handle, CURLOPT_SSL_VERIFYPEER, 0);

Anschließend funktioniert das Proxy-Script auch, wenn der I-DoIT Server SSL verlangt.

Hallo,

ich habe einen kleinen Bug in der Extension OTRS ReferenceIDoitObjects gefunden. Dieser Verhindert die Aktualisierung des Dynamischen Feldes "IDoitObjects".

Beschreibung:

Wenn ich ein Ticket in OTRS öffne und auf den Button "Referenzierte Object in i-doit" drücke erscheint ein Fenster mit der Form zur Auswahl der zu verknüpfenden CIs aus I-DoIt.
Die anschliessende Bestätigung durch das Drücken von "Übermitteln" aktualisiert zwar die Logs der CIs in I-DoIT, aber in OTRS wird das Dynamische Feld "IDoitObjects" nicht aktualisiert.

Fehleranalyse:

Der Fehler entsteht dadurch, dass die Bezeichnung des versteckten Input Feldes "idoitMandator" falsch geschrieben ist, so dass das empfangene Perl-Modul das Feld nicht auswerten kann.

Gesendetes Input-Feld in der Form: form-data; name="idoitMandator"
Erwartetes Input-Feld im Perl-Modul: my $IDoitMandator = $Self->{ParamObject}->GetParam( Param => 'IDoitMandator' );

Die Angelegenheit ist Case-Sensitive, aus diesem Grunde erkennt das Perl-Modul den Eingabewert für IDoitMandator nicht und dies verhindert ein paar Zeilen später das Speichern der Werte in der Datenbank, da $IDoitMandator NULL ist:
    # Save dynamic fields for mandator and objects:
    if ($IDoitMandator) { … }

Lösung:

Die Bezeichnung des Form-Feldes muss korrigiert werden.

Gruß

Carsten