Zur Dokumentation springen
Python

Mitglieder

`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address` und die Einladungsmethoden daneben.

Jede Methode

members.py
from openemail import openemail roles = openemail.roles.list_all()support = next(role for role in roles if role['name'] == 'Support')viewer = next(role for role in roles if role['builtin'] == 'viewer') invitation = openemail.members.add({    'email': '[email protected]',    'roleId': support['id'],    'addressIds': ['2b81de07-…'],    'access': 'member',}) people = openemail.members.list_all()sam = next(person for person in people if person['email'] == '[email protected]')member = openemail.members.get(sam['userId']) openemail.members.update(sam['userId'], {'roleId': viewer['id']}) openemail.members.grant_address(sam['userId'], {    'addressId': 'c40a95f2-…',    'access': 'viewer',})openemail.members.revoke_address(sam['userId'], 'c40a95f2-…') 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. Die Ausnahme ist eine Rolle mit addresses:all: Sie erreicht jede Adresse, was auch immer addresses auflistet, denn dieses Array enthält nur direkte Zuteilungen. Prüfen Sie also permissions, bevor Sie es als die ganze Reichweite einer Person lesen.

Jede Methode erwartet die userId, nicht die E-Mail-Adresse. add ist die einzige Ausnahme, weil es eine Adresse einlädt: Die Person hat erst dann eine userId, wenn sie annimmt, und list_invitations verfolgt die Einladung bis dahin.

'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. revoke_address ist die enge Variante, für jemanden, der das Team gewechselt hat, statt für jemanden, der gegangen ist.

Parameter

emailstrerforderlich
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).
roleIdstrerforderlich
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.
addressIdslist[str]
Adressen, die die Einladung mitführt, höchstens 64 IDs mit je 1 bis 128 Zeichen, vergeben, wenn sie angenommen wird. Jede ID wird geprüft, bevor irgendetwas geschrieben wird, eine ID, die keine Adresse dieses Workspace ist, führt also dazu, dass der ganze Aufruf mit 422 `member_not_found` abgelehnt wird, und nichts wird gesendet. Dieselbe Adresse innerhalb von zehn Minuten erneut einzuladen ergibt 409 `invitation_too_soon`.
accessLiteral['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 `grant_address` für die abweichenden Adressen aufrufen.

Antwort

objectLiteral['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.
userIdstr
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.
emailstr
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.
namestr | None
Der Anzeigename der Person, aus ihrem Konto übernommen, wo die Spalte NOT NULL ist. Das `None` 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.
imagestr | None
Der Avatar der Person, aus ihrem Konto übernommen, und null, wenn sie keinen gesetzt hat.
role.idstr | None
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.namestr
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.builtinLiteral['owner', 'admin', 'member', 'viewer', 'developer', 'billing'] | None
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.
isOwnerbool
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.
impliedbool
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.
permissionslist[Permission]
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.
addresseslist[MemberAddressResource]
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[].addressIdstr
Die ID der Adresse, und das, was `grant_address` und `revoke_address` erwarten. Eine ID, die keine Adresse dieses Workspace ist, wird bei beiden abgelehnt, statt einen Entzug zu melden, der nie stattgefunden hat.
addresses[].addressstr
Die vollständige Adresse, in Kleinbuchstaben, zusammengesetzt aus ihrem lokalen Teil und ihrer Domain.
addresses[].accessLiteral['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.
createdAtstr | None
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.

Einladungen

invitations.py
from openemail import openemail waiting = openemail.members.list_all_invitations() for invitation in waiting:    if invitation['expired']:        openemail.members.resend_invitation(invitation['id']) openemail.members.revoke_invitation('winv_6bb640f5b99e47deb758f1f5')

add antwortet mit einer Einladung, und dies sind die Aufrufe, die ihr folgen: list_invitations, list_all_invitations und iterate_invitations lesen die, die noch niemand angenommen hat, resend_invitation sendet eine erneut mit einem neuen Link und vierzehn weiteren Tagen, und revoke_invitation zieht sie zurück. Eine ausstehende Einladung gewährt nichts, bis sie angenommen wird.

resend_invitation lehnt dieselbe Adresse innerhalb von zehn Minuten ein zweites Mal mit 409 invitation_too_soon ab, und revoke_invitation lehnt eine zuerst angenommene mit 409 invitation_accepted ab.

Bestätigungscodes

add, update, remove, grant_address und revoke_address verlangen von einem OAuth-Zugriffstoken einen Bestätigungscode, bevor sie etwas ändern, resend_invitation und revoke_invitation nicht. Der Aufruf löst einen OpenEmailApiError aus, dessen is_step_up_required True ist: Fordern Sie mit security.begin_step_up() einen Code an, prüfen Sie den, den die Person Ihnen gibt, mit security.verify_step_up({'code': ...}), und rufen Sie dann erneut auf. Eine Bestätigung gilt 60 Minuten, und ein API-Schlüssel wird nie gefragt.

Referenz