Fehlermeldung durch Deaktivierung von Status?

[m.greune]

Hallo, 


ich habe in unserem KIX 18 den Status "pending reminder" deaktiviert, da wir ihn nicht brauchen. Nun sehe ich im log immer wieder folgende Meldung: 



[Wed Jun 22 17:10:13 2022][Error][Kernel::System::Ticket::TicketSearch::Database::State::Search][136] No states found for StateType pending reminder!
[Wed Jun 22 17:10:13 2022][Error][Kernel::System::Daemon::DaemonModules::BaseTaskWorker::_HandleError][56] There was an error executing Execute() in Kernel::System::Console::Command::Maint::Ticket::PendingCheck: ERROR: kix.Console.pl-Maint::Ticket::PendingCheck-33 Perl: 5.28.1 OS: linux Time: Wed Jun 22 17:10:13 2022

Message: No states found for StateType pending reminder!

Traceback (6625):
   Module: Kernel::System::Ticket::TicketSearch::Database::State::Search Line: 136
   Module: Kernel::System::Ticket::TicketSearch::Database::_CreateAttributeSQL Line: 487
   Module: Kernel::System::Ticket::TicketSearch::Database::TicketSearch Line: 255
   Module: Kernel::System::Ticket::TicketSearch::TicketSearch Line: 127
   Module: Kernel::System::Console::Command::Maint::Ticket::PendingCheck::Run Line: 131
   Module: (eval) Line: 462
   Module: Kernel::System::Console::BaseCommand::Execute Line: 456
   Module: (eval) Line: 152
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Cron::Run Line: 131
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Run Line: 252
   Module: (eval) Line: 441
   Module: main::_RunModule Line: 441
   Module: main::_Run Line: 353
   Module: main::Start Line: 190
   Module: /opt/kix/bin/kix.Daemon.pl Line: 114

Könnte es hier noch ein Problem mit einem Job etc. geben? Ich habe die Jobs bereits durch geschaut, konnte aber nichts finden wo der Status gebraucht werden würde.


Vielen Dank und viele Grüße 
Marvin

[Torsten Thau]

Hallo,


bei Euch gibt es also gar keine Status des Typs "pending reminder" Das ist in der Tat in der Prüfung auf solche Status nicht bedacht. Für's erste kannst Du diese Meldung ignorieren.


CU, Torsten

[m.greune]

Hallo Torsten,


gibt es diesbezüglich schon Pläne für eine Anpassung? Ich habe heute meine Mailadresse für die Cronjobs hinterlegt und bekomme nun alle fünf Minuten eine Mail mit folgendem Inhalt:

Code: [Auswählen]

ERROR: kix.Console.pl-Maint::Ticket::PendingCheck-92 Perl: 5.28.1 OS: linux Time: Tue Nov  8 16:50:19 2022
 
 Message: No states found for StateType pending reminder!
 
 Traceback (948):
   Module: Kernel::System::Ticket::TicketSearch::Database::State::Search Line: 136
   Module: Kernel::System::Ticket::TicketSearch::Database::_CreateAttributeSQL Line: 497
   Module: Kernel::System::Ticket::TicketSearch::Database::TicketSearch Line: 255
   Module: Kernel::System::Ticket::TicketSearch::TicketSearch Line: 127
   Module: Kernel::System::Console::Command::Maint::Ticket::PendingCheck::Run Line: 131
   Module: (eval) Line: 462
   Module: Kernel::System::Console::BaseCommand::Execute Line: 456
   Module: (eval) Line: 152
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Cron::Run Line: 131
   Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Run Line: 252
   Module: (eval) Line: 441
   Module: main::_RunModule Line: 441
   Module: main::_Run Line: 353
   Module: main::Start Line: 190
   Module: /opt/kix/bin/kix.Daemon.pl Line: 114
 

Kann ich das irgendwie unterbinden, ohne andere negative Auswirkungen davon zu haben?


Viele Grüße 
Marvin

[Torsten Thau]

Hallo Marvin,


das einfachste dürfte wohl sein den Status "pending reminder" wieder zu aktivieren. Das zweiteinfachste diese Mails zu filtern.


Für alles weitere muss der Code im Backend angepasst werden, damit es auch bei keinen pending-reminder-Status klappt.


CU, Torsten

[m.greune]

Hallo Torsten,


okay, dann muss ich mal gucken, was ich da mache. Eigentlich ist das beides nicht so das, was ich dagegen tun würde, aber ich find schon einen Workarround :D


Gibt es technische Unterschiede zwischen "pending auto" und "pending reminder"? Wenn ich einen unserer Status auf "pending reminder" ändere, könnte das ja schon helfen, aber wird der Status dann anders behandelt?


Viele Grüße 
Marvin

[m.greune]

Hallo Torsten,


ich bin gerade auf das hier gestoßen: [size=78%]Status - KIX 18 Administration (DE) (kixdesk.com)[/size]


Versteh ich das richtig, dass ich alle Status, die nicht nach dem warten geschlossen werden sollen, auf "pending reminder" stellen muss? Und dann ggf. per Job eine passende Folgeaktion oder einen passenden Folgestatus einstellen muss? Und nur die Status, die nach Ablauf der Zeit geschlossen werden sollen, auf "pending auto" stelle?
Falls dem so ist, habe ich die Status falsch eingestellt und das Ursprüngliche Problem löst sich von alleine.


Viele Grüße 
Marvin

[Torsten Thau]

Hi,


also der Unterschied zwischen dem Statustyp (1) "pending reminder" und (2) "pending auto" ist der, dass wenn der Wartzeitpunkt erreicht wird, (1) eine Erinnerungsnachricht erzeugt und im Status verbleibt und bei (2) ein Folgestatus gesetzt wird. Welcher Folgestatus das ist, ist in SysConfig "Ticket::StateAfterPending" definiert. Ist dort zum Quellstatus kein Folgestatus definiert, gibt's auch einen Fehler.


Da ein Status eine "kurze Zusammenfassung" des Bearbeitungsstandes sein soll sind natürlich versch. Begriffe (== Status) hilfreich die sich gleich verhalten (== Statustypen). So könnte bspw. "pending customer" auch "nur" erinnern, dass man auf eine Rückmeldung vom Kunde wartet aber das "pending reminder" ausdrückt dass man das Thema selbst zurück gestellt hat.


Zurück zur Frage: wenn Dein Ticket nach Erreichen des Erinnerungszeitraums NICHT geschlossen werden soll, setze am Ticket einfach den Status "pending reminder" (sofern der auch noch vom Statustyp "pending reminder" ist) und sofern der Status nicht geändert wird, erinnert das Ticket jeden Tag.


Wenn dein Ticket nach Erreichen des Wartezeitpunktes wieder auf "open" gehen soll, wäre meine Empfehlung statt "pending reminder" zu ändern, einen Status "pending reopen" einzurichten vom Typ "pending auto" und in der obigen SysConfig noch den Eintrag "pending reopen":"open" zu ergänzen.


...wenn das die Frage war... 🧐


CU, Torsten

[m.greune]

Hallo Torsten,


ich habe nur überlegt, ob ich die Fehlermeldung beheben kann, indem ich einen meiner Status anpasse um einen "pending reminder" zu haben. Ich dachte dies wäre eine Option, nachdem ich den Punkt "Status" in der Anleitung gefunden habe, der mir etwas bezüglich des "warten auto" verwirrt hat :D. Nach deiner Beschreibung ist es aber dann leider doch keine Option. Meine vier selbst angelegten Status "waiting for order", "waiting for third parties", "waiting for user appointment" und "waiting for user response" sind nämlich alle Auto-Status, die eine Folgeaktion haben.


Meine Frage ist damit aber beantwortet :)


Viele Grüße 
Marvin

[m.greune]

Hallo Torsten,


leider muss ich doch noch mal nachfragen, da bei mir der Satus scheinbar nicht angepasst wird. Ich habe den Sysconfig-Schlüssel Ticket::StateAfterPending nun nach ursprünglicher Änderung wieder auf den Standardwert gesetzt. Den Status "pending auto close" habe ich aktiviert. Setze ich diesen Status und trage eine Zeit ein, passiert beim Erreichen der Zeit gar nichts. Im Ticket sieht das dann so aus:





Die Frontend-Konfigurationsänderungen der Sysconfig habe ich geladen und im Log sehe ich auch nichts. Ist das ein Bug und gibt es hier in meinem System einen Fehler?


Die Funktion, die auf den Sysconfig-Schlüssel Ticket::StateAfterPending zugreift, funktioniert auch ohne extra angelegten Job?


Viele Grüße 
Marvin






Edit: Ein kleines Update dazu: Heute morgen war der Status nun korrekt. Die Wartezeit stand gestern Abend auf 17:56 Uhr. Geschlossen wurde das Ticket laut History um 21:01.

[Torsten Thau]

Hallo,


bei allen Status in pending-Typen gilt zu beachten, dass die Prüfung ob der Zeitpunkt erreicht wurde periodisch stattfindet (entspr. SC "Daemon::SchedulerCronTaskManager::Task###TicketPendingCheck") erst dann werden Erinnerungen versendet oder Folgestatus gesetzt. Es kann also durchaus zu so einer Anzeige kommen, dass der Zeitpunkt schon überschritten wurde, wenn der nächste Check erst in X Minuten stattfindet.


CU, Torsten