BUG! Fehler bei der Ticketerstellung (Kernel::System::PostMaster::NewTicket)

[Jan Eckhardt]

Guten Tag,

ich habe ein Problem mit dem OTOBO System.

Nachdem ich mein OTRS 6 System nach OTOBO einwandfrei migrieren konnte, haben in den letzten Tests die eintreffenden Tickets nicht erstellt werden können. Der Versand funktionierte mit dem Daemon / Cron Job oder einem erzwungenen TicketSend Befehl via Konsole.

Mein Problem:
Eintreffende Tickets erscheinen nicht – und unter dem “Communication Log” bekomme ich folgende Aussage:

 

Die von OTOBO angegebene Bug-Reporting Seite existiert nicht mehr (404).

Mein OTOBO: 10.0.13, Ubuntu 20, MariaDB
Mein altes ORTS: OTRS 6.0.30, CentOS 7, MariaDB

[Stefan Rother]

Guten Morgen Herr Eckhardt,

dieses Verhalten ist absolut unüblich und ich denke auf den ersten Blick, dass es sich nicht um einen Bug handelt, sondern um ein Konfigurationsproblem oder um einen Bug in einem Zusatzpaket (Welche Pakete sind bei Ihnen installiert?)

Bitte öffnen sie eine Konsole und pipen Sie eine gespeicherte Nachricht die nicht importiert werden konnte nochmal ins System:

root> su - otobo

otobo> /opt/otobo/var/spool/problem-email-irgendeine | bin/otobo.Console.pl Maint::PostMaster::Read

Anschließend posten Sie hier bitte nochmal den Fehler und die gesamte Ausgabe.

Die OTOBO Bugs finden Sie nun unter https://github.com/RotherOSS/otobo/issues, gibt es irgendwo noch einen veralteten Link den wir anpassen müssen?

Vielen Dank,

Stefan

Team OTOBO

 

[Jan Eckhardt]

Hallo Herr Rother,

hier ist der Report, den ich aus der Konsole auslesen konnte.

 

Ansonsten konnte ich keine weiteren Links finden, die ins Leere gehen.
Ich habe keine Addons installiert, wie es bei OTRS6 der Fall war (Znuny QuickClose + Repo)

Des Weiteren ist dies die liste per Ausgage durch: bin/otobo.CheckModules.pl –all

 

Ich bedanke mich noch einmal für die schnelle Antwort!

 

Gruß

Jan

[Sven Oesterling]

Bei dem Console-Befehl steht ein “permission denied” – da müssten Sie erstmal überprüfen, wie die Rechte genau gesetzt sind, bitte.

[Renée Bäcker]

Ist im Systemprotokoll noch etwas zu finden, *warum* die Tickets nicht erstellt werden?

 

@Stefan: Hier ist der Link zu finden: https://github.com/RotherOSS/otobo/blob/79b86ace5c3fa6bdaf949bcf371cc23f5443c0a1/Kernel/System/PostMaster/NewTicket.pm#L600

[Jan Eckhardt]

Hallo Renèe,

in welchem Systemprotokoll kann ich denn nachgucken für die Informationen, die du gerne haben möchtest?

Unter “System Log” habe ich noch das hier, was essenziell ähnlich zu dem Report von oben ist.

Die Message ist CommunicationLog(ID:12,AccountType:-,AccountID:-,Direction:Incoming,Transport:Email,ObjectLogType:Connection,ObjectLogID:33)::Kernel::System::Console::Command::Maint::PostMaster::Read => Got no email on STDIN!

 

Gruß

Jan

[Renée Bäcker]

Hallo Jan,

das ist prinzipiell die richtige Stelle an der Du schauen solltest. Aber erstmal musst Du das “permission denied”-Problem beheben.

[Jan Eckhardt]

Ich bin mir leider nicht sicher, wie ich das “Permission Denied” Problem beheben kann.
Die Unterordner und auch die Spool Mails sind mit den Rechten eigentlich richtig vergeben, oder nicht?

[Renée Bäcker]

setz mal noch ein “cat ” vor die Mail, also

cat /opt/otobo/var/spool/mail-…. | perl bin/otobo.Console.pl Maint::PostMaster::Read

[Jan Eckhardt]

Das kommt dabei heraus!

 

[Renée Bäcker]

Die Spalte ‘ticket_answered’ die da angemeckert wird gibt es originär in der Tabelle ticket nicht. Hattest Du irgendwelche Anpassungen im OTRS? Vielleicht nicht über Addons sondern über eigene Änderungen direkt in irgendwelchen Dateien?

[Jan Eckhardt]

Ich kann das nicht wirklich nachvollziehen.

Ich habe das damalige OTRS nicht aufgesetzt, jedoch die komplette Migration von 3.36 auf 6.0.30 getätigt und überwacht.
Was für Anpassungen alles gemacht wurden davor, kann ich nicht ganz in Erfahrung bringen.

Letztlich ist dann wohl ein Eintrag in der MySQL / Datenbank kaputt.
Ich weiß, dass wir in der Vergangenheit Probleme mit Anhängen von Datenbanksätzen aus 2014 hatten, bspw. Dort haben einfach Inhalte irgendwann gefehlt scheinbar.

Was könnte man nun tun? Gibt es eine Möglichkeit die SQL Einträge nachzuholen oder wieder aufzubauen?
Nach meines Erachtens wurde die damalige OTRS-Lösung nach Dokumentation aufgebaut. Leider bin ich gezwungen diese uralte Datenbank immer wieder mitzuziehen. Zumindest gab es keine Probleme diesbezüglich von OTRS 5.0.42 auf OTRS 6.0.30, was der letzte Schritt ja war, bevor ich zu OTOBO wechseln könnte. Nun verbleiben wir auf dem funktionsfähigen OTRS 6 für den Moment, bis OTOBO vielleicht doch bei uns noch laufen könnte.

[Renée Bäcker]

Du könntest in der Datenbank einfach einen Default setzen.

Schau Dir mal mit

DESCRIBE ticket

die Tabelle an. Dann könntest Du mit

ALTER TABLE ticket MODIFY ticket_answered … DEFAULT 0;

einen Standardwert setzen. Das “…” musst Du durch die Spaltendefinition (bsp. “NOT NULL INTEGER”, deswegen erst das DESCRIBE) ersetzen. Löschen würde ich die Spalte nicht, da die ja vermutlich mal eine Funktion hatte.

Du solltest mal in dem /opt/otrs/-Verzeichnist (auf dem OTRS 6) einfach mal ein

grep -r ticket_answered /opt/otrs/Kernel/*

and

grep -r ticket_answered /opt/otrs/Custom/*

machen. Vielleicht findest Du dann heraus wo das herkommt und welche Funktion das hat. Vielleicht wird die Spalte auch in GenericAgents o.ä. verwendet.

[Jan Eckhardt]

So, ich habe jetzt mit:

ALTER TABLE ticket ALTER COLUMN ticket_answered SET DEFAULT 0;

einen Default value gesetzt.
Nachdem ich ein Test-Ticket reingeschickt und manuell ge-fetched habe im Adminbreich.

Nun sagt das Communication Log immer noch, dass das Ticket nicht erstellt werden kann, …

allerdings sagt das Error log jetzt NICHT mehr, dass ticket_answered auf einen Fehler läuft, sondern Folgendes:

[Jan Eckhardt]

Das hier ist noch einmal die Einsicht in das
DESCRIBE ticket;

bezüglich der “ticket_answered” Sache von oben, das sich jetzt wohl gefixt hat.

[Jan Eckhardt]

Ich habe dasselbe ebenfalls mit “group_id” gemacht, dass ich den Default Wert auf 0 gesetzt habe, denn meine Error Logs spuckten ab jetzt “group_id” aus und nicht mehr “ticket_answered”.
Als ich das tat, klappte plötzlich alles wieder!

 

Ich bedanke mich für alle Hilfe soweit!

 

[SOLVED]

[Autor]

Beiträge