SLA zieht falschen Kalender

[Thomas Williamson]

Hallo Zusammen,

uns ist aufgefallen, dass bei SLAs der falsche Kalender gezogen wird und dadurch unser Kundensupport falsche Violation-Meldungen bekommen.
Wir verwenden KIX 18 (Build: 4648-0.1974-0)

Beispiel:
Hier das im Ticket ausgewählte SLA. In der History wird Calendar16 angezeigt. Und die Zeiten sagen GMT+03:00



Hier die Konfig des SLA und der darin hinterlegte Kalender:



Und hier die Konfiguration des Kalenders und die Kalender-Nummer



Als Gegenvergleich, hier Calendar16:




Hat sonst noch jemand diesen doch gravierenden Fehler?
Und noch viel wichtiger: hat jemand dafür eine Lösung?

Vielen Dank schon mal im voraus.
Thomas

[Thomas Williamson]

Ich hab noch ein paar weitere Tests gemacht und weitere Kalender mit weiteren SLAs und Service-Verträgen angelegt.
SLA mit Calendar35 zeigt im Ticket Calendar 28 an.
SLA mit Calendar36 zeigt im Ticket Calendar 29 an.
SLA mit Calendar37 zeigt im Ticket Calendar 30 an.
SLA mit Calendar69 zeigt im Ticket Calendar 65 an.
SLA mit Calendar75 zeigt im Ticket Calendar 72 an.

Hmm .. schade. Bis Calendar 37 hab ich gedacht, irgendwo werden einfach 7 abgezogen.
Aber dann hat sich der Unterschied doch verändert. :(


Und ich kann bestätigen, dass der im Ticket angezeigte Calendar auch der ist, der für das SLA dann herangezogen wird.
Ich hab die Zeitzone von Calendar72 auf Vietnam geändert und wenn ich dem Ticket das SLA mit Calender75 hinzufüge, wird GMT+7 angezeigt.

[Thomas Williamson]

Links der im SLA ausgewählte Kalender. Rechts der Kalender der letztlich im Ticket gezogen wird:

Calendar1 = 11
Calendar2 = 22
Calendar3 = 33
Calendar4 = 44
Calendar5 = 55
Calendar6 = 66
Calendar7 = 73
Calendar8 = 74
Calendar9 = 75
Calendar10 = 1
Calendar11 = 2
Calendar12 = 3
Calendar13 = 4
Calendar14 = 5
Calendar15 = 6
Calendar16 = 7
Calendar17 = 8
Calendar18 = 9
Calendar19 = 10
Calendar20 = 12
Calendar21 = 13
Calendar22 = 14
Calendar23 = 15
Calendar24 = 16
Calendar25 = 17
Calendar26 = 18
Calendar27 = 19
Calendar28 = 20
Calendar29 = 21
Calendar30 = 23
Calendar31 = 24
Calendar32 = 25
Calendar33 = 26
Calendar34 = 27
Calendar35 = 28
Calendar36 = 29


Keine Ahnung wie man das hinbekommt, aber es sieht so aus, als wäre die Sortierung in beiden Fällen identisch FALSCH:

[Thomas Williamson]

Hier die vollständige Liste aller Kalender.
Ich hoffe und glaube das wir keine zusätzlichen Kalender mehr anlegen müssen. Weil sonst vermutlich das "Matching" von Calendar 7 bis 9 nochmal geändert wird. Die Tanzen nämlich gerade etwas aus der Reihe. Vermutlich weil es noch keinen Kalender77, 88 und 99 gibt.

Calendar1 = 11
Calendar2 = 22
Calendar3 = 33
Calendar4 = 44
Calendar5 = 55
Calendar6 = 66
Calendar7 = 73
Calendar8 = 74
Calendar9 = 75
Calendar10 = 1
Calendar11 = 2
Calendar12 = 3
Calendar13 = 4
Calendar14 = 5
Calendar15 = 6
Calendar16 = 7
Calendar17 = 8
Calendar18 = 9
Calendar19 = 10
Calendar20 = 12
Calendar21 = 13
Calendar22 = 14
Calendar23 = 15
Calendar24 = 16
Calendar25 = 17
Calendar26 = 18
Calendar27 = 19
Calendar28 = 20
Calendar29 = 21
Calendar30 = 23
Calendar31 = 24
Calendar32 = 25
Calendar33 = 26
Calendar34 = 27
Calendar35 = 28
Calendar36 = 29
---
Calendar37 = 30
Calendar38 = 31
Calendar39 = 32
Calendar40 = 34
Calendar41 = 35
Calendar42 = 36
Calendar43 = 37
Calendar44 = 38
Calendar45 = 39
Calendar46 = 40
Calendar47 = 41
Calendar48 = 42
Calendar49 = 43
Calendar50 = 45
Calendar51 = 46
Calendar52 = 47
Calendar53 = 48
Calendar54 = 49
Calendar55 = 50
Calendar56 = 51
Calendar57 = 52
Calendar58 = 53
Calendar59 = 54
Calendar60 = 56
Calendar61 = 57
Calendar62 = 58
Calendar63 = 59
Calendar64 = 60
Calendar65 = 61
Calendar66 = 62
Calendar67 = 63
Calendar68 = 64
Calendar69 = 65
Calendar70 = 67
Calendar71 = 68
Calendar72 = 69
Calendar73 = 70
Calendar74 = 71
Calendar75 = 72
ENDE

[René Hartman]

Hallo Thomas,

Ich habe das in meinem Testsystem nachstellen können und habe das Problem an die Entwicklung weitergegeben.
Ich würde mich nochmal melden sobald ich weitere Infos bekommen habe.

Viele Grüße,
René

[Cedric Gärtner]

Hallo Thomas,

Der Bug wurde von uns behoben und wird voraussichtlich mit der V35 implementiert, sollte es dann nicht funktionieren melde dich bitte nochmal. 

Viele Grüße,
Cedric

[Thomas Williamson]

Hallo liebes KIX-Team,
Zwischenzeitlich war das Problem gefixt. Mittlerweile ist es wohl mit einem der letzten Patches wieder aufgetaucht. Genau das selbe Verhalten wie bisher.

Wir setzen Version KIX 18 (Build: 4714-3.2055-3) ein.

Bitte, wie kann so was sein?

Viele Grüße
Thomas

[Thomas Williamson]

Hallo liebes KIX-Team,

Aktuell sieht mein Workaround folgendermaßen aus:

• -- Update Calendar 1
  UPDATE sysconfig SET Name = 'TimeZone::Calendar01' WHERE Name = 'TimeZone::Calendar1';
  
  -- Update Calendar 2
  UPDATE sysconfig SET Name = 'TimeZone::Calendar02' WHERE Name = 'TimeZone::Calendar2';
  
  -- Update Calendar 3
  UPDATE sysconfig SET Name = 'TimeZone::Calendar03' WHERE Name = 'TimeZone::Calendar3';
  
  -- Update Calendar 4
  UPDATE sysconfig SET Name = 'TimeZone::Calendar04' WHERE Name = 'TimeZone::Calendar4';
  
  -- Update Calendar 5
  UPDATE sysconfig SET Name = 'TimeZone::Calendar05' WHERE Name = 'TimeZone::Calendar5';
  
  -- Update Calendar 6
  UPDATE sysconfig SET Name = 'TimeZone::Calendar06' WHERE Name = 'TimeZone::Calendar6';
  
  -- Update Calendar 7
  UPDATE sysconfig SET Name = 'TimeZone::Calendar07' WHERE Name = 'TimeZone::Calendar7';
  
  -- Update Calendar 8
  UPDATE sysconfig SET Name = 'TimeZone::Calendar08' WHERE Name = 'TimeZone::Calendar8';
  
  -- Update Calendar 9
  UPDATE sysconfig SET Name = 'TimeZone::Calendar09' WHERE Name = 'TimeZone::Calendar9';
• -- Update Calendar 1
  UPDATE sysconfig SET Name = 'TimeZone::Calendar01Name' WHERE Name = 'TimeZone::Calendar1Name';
  
  -- Update Calendar 2
  UPDATE sysconfig SET Name = 'TimeZone::Calendar02Name' WHERE Name = 'TimeZone::Calendar2Name';
  
  -- Update Calendar 3
  UPDATE sysconfig SET Name = 'TimeZone::Calendar03Name' WHERE Name = 'TimeZone::Calendar3Name';
  
  -- Update Calendar 4
  UPDATE sysconfig SET Name = 'TimeZone::Calendar04Name' WHERE Name = 'TimeZone::Calendar4Name';
  
  -- Update Calendar 5
  UPDATE sysconfig SET Name = 'TimeZone::Calendar05Name' WHERE Name = 'TimeZone::Calendar5Name';
  
  -- Update Calendar 6
  UPDATE sysconfig SET Name = 'TimeZone::Calendar06Name' WHERE Name = 'TimeZone::Calendar6Name';
  
  -- Update Calendar 7
  UPDATE sysconfig SET Name = 'TimeZone::Calendar07Name' WHERE Name = 'TimeZone::Calendar7Name';
  
  -- Update Calendar 8
  UPDATE sysconfig SET Name = 'TimeZone::Calendar08Name' WHERE Name = 'TimeZone::Calendar8Name';
  
  -- Update Calendar 9
  UPDATE sysconfig SET Name = 'TimeZone::Calendar09Name' WHERE Name = 'TimeZone::Calendar9Name';
• Über die Weboberfläche (https://meinkixserver/admin?moduleId=sysconfig) mache ich irgend eine Änderung z.B. Ändere den Namen für Calendar50. Denn vermutlich wegen irgend einer bescheuerten Cache-Funktion, werden sonst meine Änderungen auf der Datenbank nicht gezogen.
• Dann muss ich den SLAs nochmal den Calendar entfernen und wieder hinzufügen, weil offensichtlich der SLA Eintrag sich auch die CalendarID merkt.
• Und das selbe Spiel muss man dann auch nochmal bei dem Ticket machen, damit es die korrekten SLA-Parameter wie z.B. die Zeitzone zieht.

Nur so werden auch bei den SLAs die korrekten Calendar gezogen.


Jetzt musste ich aber feststellen, das meine Änderungen an der Datenbank nach jedem Neustart des Ticket-Systems offensichtlich wieder rückgängig gemacht werden.
Da dieses 🤬 Ticket-System sich an jedem zweiten Tag auch noch aufhängt und wir dann den Docker-Container wieder stoppen und starten müssen, können Sie sich vorstellen was für eine große Freude ich dabei jedes Mal habe.
Zum Glück muss Punkt 4 und 5 nicht jedes Mal erneut durchgeführt werden. Glaube ich zumindest. Muss ich noch überprüfen.