Die Rolle eines Mitglieds ändern
Die Rolle und sonst nichts. Adressen sind die andere Achse und haben eigene Aufrufe.
Führt den echten Aufruf gegen Ihren Workspace aus, mit Ihrem eigenen Schlüssel.
PATCH /members/{userId}
Die Rolle und sonst nichts. Adressen sind die andere Achse und haben eigene Aufrufe.
Beispiel
Benötigt members:write. roleId ist das einzige Feld, und es ist erforderlich. Dieser Aufruf benennt den gewünschten Zustand statt einer anzuwendenden Änderung, sodass ein zweiter Aufruf bei derselben Person mit derselben Rolle landet.
curl -X PATCH "$OE/members/7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "roleId": "role_2b81de079c1f0a4b7e05d386" }'{ "object": "member", "userId": "7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a", "email": "[email protected]", "name": null, "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": [ "emails:send", "emails:read", "threads:read", "threads:write", "labels:read", "labels:write", "contacts:read" ], "addresses": [ { "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "address": "[email protected]", "access": "viewer" } ], "createdAt": "2026-08-30T15:44:02.000Z"}Adressen sind von hier aus NICHT patchbar, und die Auslassung ist Absicht: Sie sind eine Menge mit einer Zugriffsebene pro Element, und ein PATCH mit einem Array müsste „ganz ersetzen“ bedeuten, was jedes Mal ein stiller Massenentzug ist, wenn ein Client eine veraltete Liste schickt. Die beiden Adressaufrufe fügen einzeln hinzu und entfernen einzeln, sodass das Geschehene immer das Erbetene ist.
So hört auch ein Altbestands-Grant-Inhaber auf, implied zu sein: Er hat keine Mitgliederzeile, dies legt eine an, und von da an sind seine Berechtigungen das, was jemand gewählt hat, statt dessen, was sein Adresszugriff zufällig implizierte. Beachten Sie, wie implied in der Antwort oben auf false umspringt und createdAt erscheint. An seinen Adressen ändert sich nichts.
Die owner-Rolle kann nicht vergeben werden (role_immutable, ein 409), was der Aufrufer auch halten mag. Jemanden zum Inhaber zu machen ist eine Workspace-Übertragung, die andere Folgen hat und in dieser API nicht existiert.
Ihre neue Rolle wird mit ihrer nächsten Anfrage wirksam, und mit der nächsten Anfrage jedes API-Schlüssels, der durch sie begrenzt wird.