Calendar API nach Update funktioniert nicht mehr

[sh4rxy]

Hab es mittlerweile hinbekommen. Nachdem ich penibel drauf geachtet habe, dass einige Werte wie Summary und tzid jetzt auch in „“ eingefasst werden, was vorher nicht notwendig war und die Zeitwerte jetzt um Unix-Format übermittelt werden, was vorher ebenfalls nicht notwendig war klappt es dann mit der Methode create. Jetzt will aber die Methode set nicht, die spuckt mir ebenfalls den Fehler 9009 aus , selbst wenn ich alles genauso mache wie der Browser.

 

[KlausHH]

Ich schließe mich dem Thema mal an. Habe es auch dank eurer Hinweise nun geschafft, dass Termine wieder angelegt werden können. Hier muss man tatsächlich sehr auf die Anführungszeichen achten.
Bei einem Update scheitere aber auch immer noch. Hier erhalte ich ebenfalls den Fehler 9009. zurück.

 

[Ghost108]

wie sieht denn euer Update befehl aus?

 

[KlausHH]

So sieht es aktuell bei mir aus. Für das create funktioniert der Code ohne Probleme. Beim Update kommt der 9009 Fehler.

$data = [
            'api' => 'SYNO.Cal.Event',
            'method' => !empty($update) ? 'set' : 'create',
            'version' => '5',
            'summary' => '"' . $summary . '"',
            'description' => '"' . $description . '"',
            'cal_id' => '"' . $cal_id . '"',
            'dtstart' => strtotime($start_datetime),
            'dtend' => strtotime($end_datetime),
            'transp' => 'TRANSPARENT',
            'is_repeat_evt' => 'false',
            'is_all_day' => 'false',
            'original_cal_id' => '"' . $original_cal_id . '"',
            'tz_id' => '"Europe/Berlin"',
            'location_info' => '{"address":"","gps":{"lat":-1,"lng":-1},"map_type":"","name":"","place_id":""}',
            'participant' => '[]',
            'attachments' => '[]',
            'color' => '""',
            'dav_etag' => '""',
            'repeat_setting' => 'null',
            'notify_setting' => '[]',
            '_sid' => $sid,
        ];

        if(!empty($update)) {
            $data['evt_id'] = $evt_id;
        }

 

[sh4rxy]

So ähnlich sieht es bei mir auch aus. Nur halt in einem body-String verpackt. Was mich wundert, vorher brauchte ich für eine Änderung der Einträge lediglich die evt_id und die Parameter die ich ändern wollte übermitteln. Das waren in meinem Fall nur die Zeiten von dtstart und dtend. Aber das reicht der API wohl nun nicht mehr. Verstehe nicht warum man nun auch die Kalender ID mitgeben muss. Die evt_id ist doch ein eindeutiges Identifizierungsmerkmal des Kalendereintrages.

In einem anderem Forum konnte ich herausfinden, dass der Fehlcode 9009 auf einen ungültigen Parameter hinweist. Also irgendein Parameter scheint noch problematisch zu sein. Laut Browser Debugging ist der Wert in „dav_etag“ jedes Mal anders, ich weiß aber nicht wie man den ausliest bzw. wie der Browser an den Wert kommt beim ändern eines Eintrages.

{
    "9001":"error:exceed_attach_quota",
    "9002":"error:exceed_event_quota",
    "9003":"error:copy_to_sub_event_failed",
    "9004":"error:update_newer_version_event",
    "9005":"error:update_non_existent_event",
    "9006":"error:database_operation_failed",
    "9007":"error:no_permission",
    "9008":"error:daemon_connnect_failed",
    "9009":"error:invalid_parameter",
    "9010":"error:apply_setting_failed",
    "9011":"error:default_fail_handler",
    "9012":"error:edit_event_failed",
    "9013":"error:socket_connect_failed",
    "9014":"error:invalid_ics_data",
    "9015":"error:version_mismatch",
    "9016":"error:deprecate_api",
    "9017":"error:fake_email_converting",
    "9018":"error:email_is_duplicated",
    "9019":"error:team_contact_upgrading",
    "9020":"error:fake_email_update_failed",
    "9021":"error:repeated_event_boundary_backfilling",
    "9022":"error:repeated_event_boundary_backfill_failed"
}

 

[Ghost108]

Mal ChatGPT gefragt?

 

[sh4rxy]

Tatsächlich ja, aber bislang ohne Erfolg

 

[Ghost108]

So sieht es aktuell bei mir aus. Für das create funktioniert der Code ohne Probleme. Beim Update kommt der 9009 Fehler.

$data = [
            'api' => 'SYNO.Cal.Event',
            'method' => !empty($update) ? 'set' : 'create',
            'version' => '5',
            'summary' => '"' . $summary . '"',
            'description' => '"' . $description . '"',
            'cal_id' => '"' . $cal_id . '"',
            'dtstart' => strtotime($start_datetime),
            'dtend' => strtotime($end_datetime),
            'transp' => 'TRANSPARENT',
            'is_repeat_evt' => 'false',
            'is_all_day' => 'false',
            'original_cal_id' => '"' . $original_cal_id . '"',
            'tz_id' => '"Europe/Berlin"',
            'location_info' => '{"address":"","gps":{"lat":-1,"lng":-1},"map_type":"","name":"","place_id":""}',
            'participant' => '[]',
            'attachments' => '[]',
            'color' => '""',
            'dav_etag' => '""',
            'repeat_setting' => 'null',
            'notify_setting' => '[]',
            '_sid' => $sid,
        ];

        if(!empty($update)) {
            $data['evt_id'] = $evt_id;
        }

vllt darf dav_etag nicht leer sein? bin mir aber nicht sicher. Führe selbst keinen Uodate Task durch

 

[sh4rxy]

Ich vermute ja auch , dass es mit dem „dav_etag“ zusammen hängt. Das ist der einzigste Parameter den ich nicht rekonstruieren kann, weil ich nicht weiß wie man an den Wert kommt.

 

[Ghost108]

was ist denn, wenn man einfach einen zufällig generierten string bei jedem update als dav_etag mitgibt?

 

[sh4rxy]

Das werde ich heute Abend mal testen

 

[KlausHH]

Perfekt, es lag tatsächlich am dav_etag

Meine Lösung sieht nun wie folgt aus:
Ich hole mir meine aktuellen Kalendereinträge über die Url /webapi/entry.cgi mit folgenden Angaben. Wichtig war hier, dass ich auf version 3 gehe, weil erst da bei mir der dav_etag mit zurückgeliefert wird.

$data = [
            'start' => strtotime('-5 days'),
            'end' => strtotime('+90 days'),
            'list_repeat' => 'false',
            'cal_id_list' => $cal_id_list,
            'api' => 'SYNO.Cal.Event',
            'method' => 'list',
            'version' => '3',
            '_sid' => $sid,
        ];

Beim Updaten übergebe ich dann die folgenden Daten. Hier war wichtig, dass alle Parmeter existieren und ggf. die "" hinzugefügt werden müssen. Zum Update zwingend dann den dav_etag setzen.

$data = [
            'api' => 'SYNO.Cal.Event',
            'method' => !empty($update) ? 'set' : 'create',
            'version' => '5',
            'summary' => '"' . $summary . '"',
            'description' => '"' . $description . '"',
            'cal_id' => '"' . $cal_id . '"',
            'dtstart' => strtotime($start_datetime),
            'dtend' => strtotime($end_datetime),
            'transp' => 'TRANSPARENT',
            'is_repeat_evt' => 'false',
            'is_all_day' => 'false',
            'original_cal_id' => '"' . $original_cal_id . '"',
            'tz_id' => '"Europe/Berlin"',
            'location_info' => '{"address":"","gps":{"lat":-1,"lng":-1},"map_type":"","name":"","place_id":""}',
            'participant' => '[]',
            'attachments' => '[]',
            'color' => '""',
            'dav_etag' => '""',
            'repeat_setting' => 'null',
            'notify_setting' => '[]',
            '_sid' => $sid,
        ];

        if(!empty($update)) {
            $data['evt_id'] = $evt_id;
           $data['dav_etag'] = '"' . $existingSlot['dav_etag'] . '"';
        }

Danke für den Austausch und die gemeinsame Lösungsfindung

 

[sh4rxy]

Ok super. Gut zu wissen. Jetzt muss ich leider einen Umweg nehmen, weil sich mein Weg die Daten zu ändern innerhalb eines Excel Makros abspielt. Die Einträge werden anhand von Arbeitszeiten aus einem Excel Sheet erstellt und dabei wird direkt die evt_id mit in eine Zelle geschrieben. Zum ändern der Werte wurde dann aus der Spalte die entsprechende evt_id ausgelesen und dieser Eintrag dann geändert. Ich muss nun also einen Zwischenschritt einbauen. Es gibt doch die Methode „get“ oder ? Dann muss ich eventuell diese nehmen und versuchen damit an den dav_etag zu der entsprechenden evt_id zu kommen. Wenn das nicht geht muss ich alles komplett umkrempeln um mit der „list“-Methode zu arbeiten. Echt nervig , das hat jetzt zwei Jahre lang ohne Probleme alles funktioniert, warum verkomplizieren die das nun so

 

[KlausHH]

Müsstest du aber nicht zumindest bei neuen Einträgen nun auch den dav_etag beim Schreiben mit zurück erhalten? Dann könntest du zumindest für zukünftig neue Termine diesen mit in eine extra Spalte schreiben und musst nicht alles umbauen.

 

[sh4rxy]

Sehr guter Ansatz, dann teste ich erstmal in diese Richtung

 

[sh4rxy]

Super, hat funktioniert. Lasse mir den dav_etag nun direkt beim erstellen in eine separate Spalte schreiben und lese von dort aus für die Update-Methode aus. Funktioniert nun endlich alles wieder.

Worüber ich aber kurz gestolpert bin :
Wenn ein Eintrag geändert wird, wird auch ein neuer dav_etag erzeugt. Daran hing ich kurz fest da ich beim Testen die Einträge nur einmal erfolgreich ändern konnte und kein zweites mal mehr. Ich lasse nun den dav_etag wert einfach bei einem Update direkt überschreiben und somit klappen dann auch alle zukünftigen Updates wieder.

Vielen Dank euch