SDK

Mitglieder

`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` und `revokeAddress`.

Alle Methoden

members.ts

const people = await openemail.members.list()const member = await openemail.members.get(people[0]!.userId) const sam = await openemail.members.add({  email: '[email protected]',  roleId: support.id,  addressIds: ['2b81de07-…'],  access: 'member',}) await openemail.members.update(sam.userId, { roleId: viewerRoleId }) await openemail.members.grantAddress(sam.userId, {  addressId: 'c40a95f2-…',  access: 'viewer',})await openemail.members.revokeAddress(sam.userId, 'c40a95f2-…') await openemail.members.remove(sam.userId)

Zwei Berechtigungen pro Person, und sie dürfen nicht zusammengeworfen werden. role ist, was jemand tun darf; addresses ist, woran er es tun darf. Beide müssen übereinstimmen: Eine Rolle mit emails:send und access: "viewer" auf invoices@ beschreibt jemanden, der Mail senden darf und sie nicht von dieser Adresse senden darf.

Jede Methode erwartet die userId, nicht die E-Mail-Adresse. add ist die einzige Ausnahme, und darin liegt zugleich der Grund für die Ausnahme: Ihr Aufrufer hat eine E-Mail-Adresse und noch keine Benutzer-ID, und genau darin besteht die erste Hälfte dessen, was dieser Aufruf tut.

implied: true bedeutet, dass niemand die Rolle gewählt hat. Die Person hat Adressen und keine Rollenzeile, die Rolle wurde also aus ihrer weitesten Berechtigung abgeleitet. Behandeln Sie das als „noch nicht entschieden“; update macht aus der Ableitung eine Entscheidung. Bis dahin erweitert jede Ausweitung ihres Adresszugriffs stillschweigend auch das, was sie tun darf.

Der Workspace-Eigentümer ist die erste Zeile, markiert mit isOwner: true, während add, update und remove ihn weiterhin mit member_is_owner ablehnen. Ein nicht geteilter Workspace meldet ein Mitglied statt keines, schließen Sie isOwner daher aus, wenn Sie Plätze zählen.

remove nimmt beide Achsen, die Rolle UND jede Adressberechtigung in diesem Workspace, und meldet addressesRevoked. revokeAddress ist die enge Variante, für jemanden, der das Team gewechselt hat, statt für jemanden, der gegangen ist.

Parameter

emailstringerforderlich: Wen Sie einladen, getrimmt und in Kleinbuchstaben. Ein Konto muss noch nicht bestehen: Eingeladen wird jeder, und Rolle wie Berechtigungen greifen, sobald die Einladung angenommen wird. Jemand, der bereits im Workspace ist, ergibt `member_is_owner` (422).
roleIdstringerforderlich: Die Rolle, die die Person erhält, 1 bis 128 Zeichen, und sie muss eine Rolle dieses Workspace sein: eine unbekannte ID ergibt `role_not_found` (404). Die Eigentümerrolle lässt sich nicht vergeben und kommt als `role_immutable` (409) zurück, denn jemanden zum Eigentümer zu machen ist eine Workspace-Übertragung, und dafür gibt es hier keinen Aufruf.
addressIdsstring[]: Adressen, die im selben Aufruf übergeben werden, höchstens 64 IDs mit je 1 bis 128 Zeichen; eine ID, die keine Adresse dieses Workspace ist, wird abgelehnt. Zuerst wird die Rolle geschrieben, danach folgen die Berechtigungen einzeln, eine fehlerhafte ID hinterlässt das Mitglied also mit weniger Adressen als angefordert. Die Lösung ist, denselben Body erneut zu senden, da beide Schreibvorgänge ein Upsert ausführen.
access'member' | 'viewer': Was die Person mit jeder ID in `addressIds` tun darf: `member` liest die Adresse und sendet als sie, `viewer` liest sie nur. Standard ist `member`, die Stufe, die die Konsole und der ältere Freigabepfad seit jeher verwenden, sodass derselbe Aufruf aus einem Skript dasselbe bedeutet wie von einem Bildschirm; eine gemischte Vergabe erreichen Sie, indem Sie anschließend `grantAddress` für die abweichenden Adressen aufrufen.

Antwort

object'member': Immer `member`. Eine Entfernung antwortet mit demselben Wert, der `userId` der Person, `deleted: true` und `addressesRevoked`, und mit keinem der übrigen Felder weiter unten.
userIdstring: Die Konto-ID der Person, und der Bezeichner, den jeder andere Mitglieder-Aufruf im Pfad erwartet: get, update, remove und beide Adress-Aufrufe. Jemanden hinzuzufügen ist der einzige Aufruf, der stattdessen mit einer E-Mail-Adresse arbeitet, denn wer eine Kollegin oder einen Kollegen hinzufügt, kennt deren Adresse und nicht deren ID.
emailstring: Die E-Mail-Adresse des Kontos, so zurückgegeben, wie diese Zeile sie speichert. Diese Ressource schreibt sie nie, und die Umwandlung in Kleinbuchstaben bei `add` betrifft die Adresse, die Sie zur Suche senden, nicht das, was zurückkommt. Nach dem Eigentümer ist die Mitgliederliste danach sortiert und nicht nach dem Beitrittszeitpunkt, denn die Liste wird gelesen, um eine bestimmte Person zu finden, nicht um zu sehen, was sich geändert hat.
namestring | null: Der Anzeigename der Person, aus ihrem Konto übernommen, wo die Spalte NOT NULL ist. Das null im Typ ist defensiv gesetzt und kein Zustand, den diese API nachweislich erzeugt. Der Name gehört der Person und nicht dem Workspace, nichts an dieser Ressource kann ihn also setzen.
imagestring | null: Der Avatar der Person, aus ihrem Konto übernommen, und null, wenn sie keinen gesetzt hat.
role.idstring | null: Die ID der Rolle, die die Person hat, oder null, wenn sie niemand gewählt hat. Siehe `implied`. Ein null an dieser Stelle ist der eine Fall, in dem `role` eine Ableitung meldet und nicht eine Entscheidung, die jemand getroffen hat.
role.namestring: Der Name der Rolle. Bei einem abgeleiteten Mitglied ist es der Name der eingebauten Vorlage, auf die sein Zugriff aufgelöst wurde, und keine Zeile in diesem Workspace.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null: Welche eingebaute Rolle es ist, oder null bei einer eigenen Rolle. `owner` erscheint nur in der Zeile des Eigentümers selbst, zusammen mit `isOwner: true`; diese Rolle jemandem zuzuweisen wird mit `role_immutable` (409) abgelehnt.
isOwnerboolean: true in genau einer Zeile, dem Konto, auf das der Workspace geschlüsselt ist. Dieses Konto hat jede Berechtigung, ganz gleich was seine Rollenzeile sagt, es wird zuerst einsortiert, und `add`, `update` und `remove` lehnen es alle mit `member_is_owner` ab. Schließen Sie es aus, wenn Sie Plätze zählen.
impliedboolean: true, wenn diese Person Adressberechtigungen und keine Mitgliedszeile hat, ihre Rolle also abgeleitet und nicht gewählt wurde: Jede Berechtigung `member` löst auf die eingebaute Rolle Member auf, sonst auf Viewer. Beim Eigentümer nie true. Zeigen Sie es als „durch Zugriff abgeleitet“ an. Bis ein PATCH aus der Ableitung eine Entscheidung macht, erweitert jede Ausweitung ihres Adresszugriffs stillschweigend auch das, was sie tun darf.
permissionsPermission[]: Die Berechtigungen der Rolle, flach auf das Mitglied gelegt, sodass ein einziger Lesevorgang die Frage „darf die Person das?“ beantwortet, ohne die Rolle zu laden. Bei einem abgeleiteten Mitglied stammen sie aus dem eingebauten TEMPLATE und nicht aus der Rollenzeile dieses Workspace, das Bearbeiten der eingebauten Rolle Member ändert also nicht, was ein abgeleitetes Mitglied hat.
addressesMemberAddress[]: Die Adressen, die der Person zugeteilt wurden, nach Adresse sortiert, jede mit ihrer eigenen Zugriffsstufe. Leer bei jemandem, der eine Rolle und keine Berechtigungen hat, genau so sieht ein neues Mitglied aus, bis ihm eine Adresse zugeteilt wird, und das ist der richtige Fehlerfall, solange Sie noch entscheiden, was die Person sehen soll.
addresses[].addressIdstring: Die ID der Adresse, und das, was `grantAddress` und `revokeAddress` erwarten. Eine ID, die keine Adresse dieses Workspace ist, wird bei beiden abgelehnt, statt einen Entzug zu melden, der nie stattgefunden hat.
addresses[].addressstring: Die vollständige Adresse, in Kleinbuchstaben, zusammengesetzt aus ihrem lokalen Teil und ihrer Domain.
addresses[].access'member' | 'viewer': Was die Person mit genau dieser einen Adresse tun darf: `member` liest sie und sendet als sie, `viewer` liest sie nur. Dieser Wert und die Rolle müssen einen Sendevorgang beide erlauben, bevor er zustande kommt, eine Rolle mit `emails:send` über einer `viewer`-Berechtigung sendet also von nichts; die gespeicherte Spalte heißt `role` und wird hier umbenannt, damit ein Objekt nicht zwei `role`s aus zwei verschiedenen Vokabularen trägt.
createdAtstring | null: Wann die Mitgliedszeile geschrieben wurde, ISO-8601, und null, wenn es überhaupt keine Mitgliedszeile gibt. Dieses null beschreibt dieselbe Gruppe wie `implied: true`: Personen, die Adressen aus der Zeit vor den Rollen halten und denen seither niemand eine Rolle gegeben hat.