Habe in der Zwischenzeit etwas mehr herausgefunden, die Admin-API liefert hier bereits den falschen Wert:
wget http://[::1]:8080/api/v1/service/syncPolicy/xxx@example.com -O -
-> enthält "allowstoragecard":0
. Allerdings liefert die default policy der Domain (.../syncPolicy/default
) gegenteilig den erwarteten Wert "allowstoragecard":1
.
Beim betroffenen User direkt in der Datenbank (Tabelle users
) ist in der Spalte sync_policy
ein leeres Objekt ({}
) eingetragen. Änderungen über die grommunio admin UI an der Sync Policy ändern eindeutig genau diesen Eintrag in der Datenbank, aber es gibt keine sichtbare Option in der UI um das allowstoragecard
Property zu editieren!? Ich verstehe auch nicht ganz, wieso aus dem merge einer default Policy mit Wert 1 und einem leeren Objekt ein Resultat mit Wert 0 wird, aber hängt eventuell mit dem spezifischen Attribut zusammen?
Ich konnte nun mit den selben HTTP Requests wie sie die Admin UI absendet (PATCH an https://admin:8443/api/v1/domains/<domid>/users/<id>
) auch das allowstoragecard
für den Benutzer auf 1
setzen. Dürfte den selben Effekt gehabt haben, als wenn ich es direkt in der Datenbank ändere, zumindest sehe ich die Änderungen unmittelbar in der DB (nur über die API probiert, falls sich hier irgendwelche Nebeneffekte beim Update verstecken) -> in sync_policy
in der DB steht nun {"allowstoragecard":1}
und bei Abfrage über den syncPolicy service von oben erhalte ich auch den erwarteten Wert.
Warum der initiale Wert in der Datenbank effektiv falsch war obwohl er im Normalfall nicht editierbar scheint ist mir weiterhin ein Rätsel. Hat hier jemand mehr Einblick wie das zustande kommen kann bzw. wo der eigentliche Fehler liegen könnte (um dies in Zukunft zu vermeiden)? Der betroffene User ist via LDAP importiert (ev. relevant?), wobei kein manuelles Mapping von Attributen auf eine sync policy o.ä. konfiguriert wäre.