-
AutorBeiträge
-
-
25. Oktober 2021 um 8:24 Uhr - Views: 3057 #12047
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 -
25. Oktober 2021 um 8:41 Uhr #12049
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
-
25. Oktober 2021 um 9:42 Uhr #12050
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
-
25. Oktober 2021 um 10:02 Uhr #12055
Bei dem Console-Befehl steht ein “permission denied” – da müssten Sie erstmal überprüfen, wie die Rechte genau gesetzt sind, bitte.
-
-
25. Oktober 2021 um 9:53 Uhr #12052
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
-
25. Oktober 2021 um 9:59 Uhr #12054
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
-
25. Oktober 2021 um 10:09 Uhr #12058
Hallo Jan,
das ist prinzipiell die richtige Stelle an der Du schauen solltest. Aber erstmal musst Du das “permission denied”-Problem beheben.
-
25. Oktober 2021 um 10:15 Uhr #12059
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? -
25. Oktober 2021 um 10:20 Uhr #12060
setz mal noch ein “cat ” vor die Mail, also
cat /opt/otobo/var/spool/mail-…. | perl bin/otobo.Console.pl Maint::PostMaster::Read
-
25. Oktober 2021 um 10:31 Uhr #12061
Das kommt dabei heraus!
-
25. Oktober 2021 um 10:37 Uhr #12062
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?
-
25. Oktober 2021 um 10:46 Uhr #12063
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. -
25. Oktober 2021 um 11:19 Uhr #12064
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/*
und
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.
-
25. Oktober 2021 um 12:31 Uhr #12067
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:
-
25. Oktober 2021 um 12:36 Uhr #12068
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.
-
25. Oktober 2021 um 13:39 Uhr #12069
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]
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.