Hallo Stefan,

1. Das weiß ich leider nicht mehr, es war auf jeden Fall noch eine 10.0.X Version, denke ich.
2. Es handelt sich nicht um eine Docker Installation
3. Es werden Mails versendet (wie bspw. eine Auto-Respose, wenn Tickets in System eingehen an diejenigen, die die Tickets abschickten), aber es werden keine Follow-Up oder andere Nachrichten verschickt, obwohl man die Benachrichtigung aktiv hat.
   
4. Im System Log steht nichts von Relevanz
   
5. Die Tickets in der Historie zeigen ganz klar, dass es keine verschickten Benachrichtigungen gibt, aber Tickets in der Vergangenheit (vor dem Update am 15.07 von mir) zeigen diese ganz klar.
   (BILD: AKTUELLES BEISPIELTICKET)
   

   (BILD: BEISPIELTICKET VOR DEM UPDATE)
   

Ich hoffe, ich konnte damit die Kernfragen beantworten.
Leider weiß ich nicht, was noch genau eingestellt werden muss in den Settings. Ich bin mir nicht sicher, was sich da geändert hat, denn die Settings unseres OTOBOs haben sich nicht verändert, lediglich, dass es nicht mehr funktioniert, hat sich verändert.

Gruß
Jan

Ich habe gerade einen alten Installtionsordner gefunden. Da steht 10.0.13 mit dran.

Sprich, zu der ersten Frage:
10.0.13 -> 10.1.4
Das ist der Update-Schritt gewesen.

Leider konnte ich das Problem noch nicht beheben.
In den Systemkonfigurationen kann man auch unter Core->Log ein Debug logfile in „minimumlog“ setzen, aber selbst in dem Logfile, das bei uns auf dem Server liegt, wird nichts relevantes hineingeschrieben.

Außerdem habe ich eine neue Ticket Notification erstellt, wo möglichst alle Flags gesetzt sind, damit ich benachrichtig werde zu jedem Umstand, egal was passiert. Alle anderen Notifications wurden abgeschaltet und abgewählt und dennoch bekomme ich leider nichts rein.

Ich dachte zunächst, das Problem könnte gefixt werden, indem man die alten Ticketnotifications neu erstellt, denn ein paar Unterpunkte sahen bei einem neuen Template der TicketNotifications anders aus als bei den bestehenden, die wir besitzen.
Allerdings triggert nicht einmal die neue TicketNotification, obwohl ich mich explizit angegeben habe und obwohl alle möglichen Trigger festgelegt sind, nahzu egal, was im System passiert.

Gibt es noch andere Möglichkeiten, die ich in Betracht ziehen könnte, auszuprobieren?

Vielen Dank!

Gruß
Jan

Hallo Stefan,

ich habe im Syslog unter dem debug level das hier gefunden: „Permission denied“ für den TickteScheduler.

Im „SchedulerTaskWorker“ findet man „root@localhost“ unter dem Punkt:

Ich habe nochmal geschaut, aber die Cron/Deamon jobs stößt man laut Manual nie per „sudo“ an.
Hilft das hier irgendwie weiter?

Meine Maschine läuft unter Ubuntu-20.04 LTS.

Hi Kevin,

ich habe das auch noch einmal überprüft. Mein OTOBO ist so konfiguriert, dass es die LogDatei in das SysLog schreibt, und da ist auch alles zu finden, vor allem das Bild von oben „Permission denied on TicketID“, was ständig kommt. Ich weiß leider nicht genau, woher das kommt oder wie ich das beheben kann. Vielleicht ist nach dem Update eine Persmission nicht richtig gesetzt worden?

Bei dir gibts diese Nachricht nicht und dennoch werden keine Benachrichtigungen geschickt?
In meiner TicketHistory steht normalerweise, dass Benachrichtungen getriggert werden. In meinen aktuellen Tickets ist das nicht der Fall.

Ich habe auf einer VM OTOBO frisch via Docker installiert, und bei der ersten Systemnachricht, bei der ich den Owner wechseln konnte, wurde in der Tat sofort in der TicketHistory ein Trigger gesetzt, dass eine Benachrichtigung geschickt werden würde. (Wegen fehlender Email Anbindung gibts aber natürlich den Fehler, dass nichts geschickt werden kann).
Nur in meinem bestehenden System funktioniert es also nicht mehr, warum auch immer.

Gruß
Jan

PS:
„Mich bei Antworten per E-Mail benachrichtigen“ geht leider auch nicht hier im Forum, ich bekomme nie Emails, wenn es unter meinen Beitrag eine neue Antwort gibt (Außer wenn ich irgendetwas übersehen habe da)

Ich habe noch in dem Fehler bei „SchedulerTaskWorker“ das hier gefunden.

Gehört das so oder habe ich da noch was übersehen?

So, ich denke, damit kann ich meinen letzten Beitrag zu diesem speziellen Thema schreiben:

Das Problem schien wirklich ein Rechteproblem zu sein. Die „Permission denied“ Probleme konnte ich beheben, sprich, es war reiner Zufall, dass das wirklich das Problem war.

Ich habe Folgendes getan:

root> systemctl stop apache2
root> systemctl stop cron

root> su - otobo
otobo> cd /opt/otobo/
otobo> bin/Cron.sh stop
otobo> bin/otobo.Daemon.pl stop

root> /opt/otobo/bin/otobo.SetPermissions.pl

root> su - otobo
otobo> perl /opt/otobo/bin/otobo.CheckModules.pl --list

root> su - otobo
otobo> /opt/otobo/bin/otobo.Console.pl Admin::Package::ReinstallAll
otobo> /opt/otobo/bin/otobo.Console.pl Admin::Package::UpgradeAll
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Config::Rebuild

root> su - otobo
otobo> cd /opt/otobo/
otobo> bin/otobo.Daemon.pl start

otobo> bin/Cron.sh startroot> systemctl start apache2
root> systemctl start cron

Ich hoffe, dass ich damit irgendjemanden helfen konnte.
Mein System:
Ubuntu 20.04 LTS
OTOBO 10.1.4
Installation normal (Nicht Docker)

Gruß

Jan

Closed