Hallo zusammen,
ich habe für mich schon viele Informationen aus OtterHub gewonnen und habe nun selber mit OTRS ein Problem bei dem ich nicht weiter komme und noch keine Antwort gefunden habe:
Wenn ich bei einem ConfigItem (unabhängig der Klasse) ein Datumsfeld(Install, Garantie oder Rechnung) über die SOAP-Schnittstelle des GenericInterface ändere oder anlege wird das Datum vorerst richtig übergeben.
Wenn ich nun das ConfigItem in OTRS aufrufe, werden alle Informationen richtig angezeigt.
Sobald ich nun aber auf "Bearbeiten" klicke, öffnet sich die Bearbeitungsmaske und alle Informationen außer den Datums-Feldern werden richtig angezeigt. Die Datums-Felder setzten sich allerdings automatisch auf den aktuellen Tag
Das Problem taucht nur in Verbindung mit ConfigItems auf, die ich über SOAP angelegt habe oder bei denen ich z.B. das Installationsdatum nachträglich über SOAP geändert habe.
Wenn ich nun ein ConfigItem händisch anlege, bei dem ich das Rechnungsdatum auf ein beliebiges Datum z.B. (19.12.2016) setzte und dieses Item anschließend über SOAP bzgl. des Install- und Garantiedatum ändere
<InstallDate>19.12.2016 11:29:00</InstallDate>
<WarrantyExpirationDate>19.12.2016 11:29:00</WarrantyExpirationDate>
so wird für alle 3 Daten bei Aufruf des Items in OTRS das richtige Datum angezeigt (19.12.2016).
Sobald ich nun wieder auf "Bearbeiten" klicke, öffnet sich die Maske und das Datum für InstallDate und WarrantyExpirationDate steht wieder auf dem aktuellen Tag (heute also 04.07.2018), das Rechnungsdatum ändert sich allerdings nicht in der Maske und bleibt auf 19.12.2016.
Hat jemand eine Idee oder einen Hinweis für mich wo die tatsächliche Ursache des Problems liegen könnte?
Da ConfigItems bei uns teils automatisch angelegt werden, in weiteren Schritten aber von Mitarbeitern noch editiert werden, ist es ärgerlich wenn eingetragene Datums-Angaben nach dem Bearbeiten nicht mehr korrekt sind, und die entsprechenden Mitarbeiter extra prüfen müssen, ob das Datum richtig übernommen wurde oder nicht, da für sie nicht ersichtlich ist, welches Item und vorallem welches Feld durch die Webservice-Schnittstelle geändert wurde oder eben nicht.
Wenn ihr weitere Infos hinsichtlich meines Problems benötigt liefere ich euch diese gerne. Die bei uns verwendete OTRS-Version ist 5.0.14.
Über konkrete Lösungen oder auch Ideen/Hinweise zur Problemlösung wäre ich euch sehr dankbar
Datum spring bei "Bearbeiten" auf aktuellen Tag - Webservice
-
- Znuny guru
- Posts: 5018
- Joined: 13 Mar 2011, 09:54
- Znuny Version: 6.0.x
- Real Name: Renée Bäcker
- Company: Perl-Services.de
- Contact:
Re: Datum spring bei "Bearbeiten" auf aktuellen Tag - Webservice
Müsste das Format nicht eher als YYYY-MM-DD übergeben werden und nicht als DD.MM.YYYY
Perl / Znuny development: http://perl-services.de
Free Znuny add ons from the community: http://opar.perl-services.de
Commercial add ons: http://feature-addons.de
Free Znuny add ons from the community: http://opar.perl-services.de
Commercial add ons: http://feature-addons.de
Re: Datum spring bei "Bearbeiten" auf aktuellen Tag - Webservice
Hallo reneeb,
vielen Dank für deine Antwort! Habe jetzt länger für die Fehlersuche gebraucht und natürlich musste es an etwas simplen liegen.
Das Datum-Format YYYY-MM-DD ist das richtige, hätte ich auch selber drauf kommen können
Was mich irritiert, ist dass andere Formate angenommen wurden und nur beim "Bearbeiten" dann Probleme gemacht haben, bei der Ansicht auf das ConfigItem aber nicht weiter aufgefallen sind.
Auch wenn kein Datum ausgefüllt wird (z.B: </WarrantyExpirationDate> in der SOAP-Message) würde ich erwarten, dass entweder die Message nicht akzeptiert wird oder eben ein leeres Datum gesetzt wird, aber nicht beim "Bearbeiten" dann das von heute eingetragen wird.
Mit dem Verhalten kann ich aber arbeiten und dein Tipp war ausschlaggebend dafür, dass ich endlich weiter komme - Vielen Dank dafür!
vielen Dank für deine Antwort! Habe jetzt länger für die Fehlersuche gebraucht und natürlich musste es an etwas simplen liegen.
Das Datum-Format YYYY-MM-DD ist das richtige, hätte ich auch selber drauf kommen können
Was mich irritiert, ist dass andere Formate angenommen wurden und nur beim "Bearbeiten" dann Probleme gemacht haben, bei der Ansicht auf das ConfigItem aber nicht weiter aufgefallen sind.
Auch wenn kein Datum ausgefüllt wird (z.B: </WarrantyExpirationDate> in der SOAP-Message) würde ich erwarten, dass entweder die Message nicht akzeptiert wird oder eben ein leeres Datum gesetzt wird, aber nicht beim "Bearbeiten" dann das von heute eingetragen wird.
Mit dem Verhalten kann ich aber arbeiten und dein Tipp war ausschlaggebend dafür, dass ich endlich weiter komme - Vielen Dank dafür!