Mitglieder
`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address` und die Einladungsmethoden daneben.
Jede Methode
support_role_id = "role_8b1f4c2e9a7d3b60e5f1a2c4"viewer_role_id = "role_2c7e9a1f4b8d3e60c5a7f1b9" invitation = client.members.add( email: "[email protected]", roleId: support_role_id, addressIds: ["2b81de07-9c3f-4a61-b8e2-5d07f4c19a36"], access: "member")puts invitation[:id], invitation[:expiresAt] people = client.members.list_allputs people.map { |person| "#{person[:email]} #{person[:userId]}" } sam_id = "q7Vd3kX9mT2pLw8RzN4bYc6HfJ1sGa5E"member = client.members.get(sam_id)puts member.dig(:role, :name), member[:implied] client.members.update(sam_id, roleId: viewer_role_id) address_id = "c40a95f2-1e7b-4d38-a6c9-82f05b3d7e14"client.members.grant_address(sam_id, addressId: address_id, access: "viewer")client.members.revoke_address(sam_id, address_id) removed = client.members.remove(sam_id)puts removed[:addressesRevoked]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, die jede Adresse erreicht, egal was addresses auflistet, denn dieses Array enthält nur direkte Freigaben. Prüfen Sie daher permissions, bevor Sie addresses als die gesamte Reichweite einer Person lesen.
Jeder Aufruf zu einer Person nimmt deren userId als erstes Argument, nicht ihre E-Mail. Lesen Sie sie daher aus list oder list_all ab, wie es das Beispiel tut. add ist die einzige Ausnahme, weil es eine Adresse einlädt: Die Person hat erst eine userId, wenn sie annimmt, und list_invitations verfolgt die Einladung bis dahin. Die Felder eines Request-Bodys behalten die camelCase-Namen der API (roleId:, addressIds:, addressId:) und werden als Keywords oder als einzelner Hash übergeben.
list gibt eine OpenEmail::Page zurück, list_all gibt alle Mitglieder in einem einzigen Array zurück, und iterate übergibt jedes Mitglied an einen Block oder gibt ohne Block einen Enumerator zurück. Ein Mitglied kommt als Hash mit Symbol-Schlüsseln zurück, und role ist ein Hash darin, member.dig(:role, :name) liest also den Namen der Rolle.
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, einem 422, ausgelöst als OpenEmail::ValidationError. Ein nicht geteilter Workspace meldet ein Mitglied statt keines. Schließen Sie isOwner daher aus, wenn Sie Plätze zählen: client.members.list_all.count { |member| !member[:isOwner] }.
remove nimmt beide Achsen, die Rolle UND jede Adressfreigabe 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
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), ausgelöst als `OpenEmail::NotFoundError`. 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.
addressIdsArray<String>- 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`.
accessString- 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
objectString- 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 als erstes Argument nimmt: `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 or nil- Der Anzeigename der Person, aus ihrem Konto übernommen, wo die Spalte immer einen Wert enthält. Das nil im Typ ist defensiv 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 or nil- Der Avatar der Person, aus ihrem Konto übernommen, und nil, wenn sie keinen gesetzt hat.
role.idString or nil- Die id der Rolle, die die Person hat, gelesen als `member.dig(:role, :id)`, oder nil, wenn sie niemand gewählt hat. Siehe `implied`. Ein nil 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, der sein Zugriff entspricht, und keine Zeile in diesem Workspace.
role.builtinString or nil- Welche eingebaute Rolle es ist, `owner`, `admin`, `member`, `viewer`, `developer` oder `billing`, oder nil 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 Adressfreigaben und keine Mitgliedszeile hat, ihre Rolle also abgeleitet und nicht gewählt wurde: Jede Freigabe mit `member` macht daraus die eingebaute Rolle Member, sonst Viewer. Beim Eigentümer nie true. Zeigen Sie es als „durch Zugriff abgeleitet“ an. Bis ein `update` aus der Ableitung eine Entscheidung macht, erweitert jede Ausweitung ihres Adresszugriffs stillschweigend auch das, was sie tun darf.
permissionsArray<String>- 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 der eingebauten VORLAGE und nicht aus der Rollenzeile dieses Workspace. Das Bearbeiten der eingebauten Rolle Member ändert also nicht, was ein abgeleitetes Mitglied hat.
addressesArray<Hash>- 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 `grant_address` und `revoke_address` nehmen. 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[].accessString- 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 Versand beide erlauben, bevor er zustande kommt, eine Rolle mit `emails:send` über einer `viewer`-Freigabe sendet also von nichts. Die gespeicherte Spalte heißt `role` und wird hier umbenannt, damit ein Hash nicht zwei `role`-Schlüssel aus zwei verschiedenen Vokabularen trägt.
createdAtString or nil- Wann die Mitgliedszeile geschrieben wurde, als String nach ISO 8601, und nil, wenn es überhaupt keine Mitgliedszeile gibt. Dieses nil 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
waiting = client.members.list_all_invitations waiting.each do |invitation| client.members.resend_invitation(invitation[:id]) if invitation[:expired]end client.members.revoke_invitation("winv_6bb640f5b99e47deb758f1f5")add antwortet mit einer Einladung, und dies sind die Aufrufe, die ihr folgen. list_invitations gibt eine OpenEmail::Page mit denen zurück, die noch niemand angenommen hat, list_all_invitations gibt alle in einem einzigen Array zurück, und iterate_invitations übergibt jede an einen Block oder gibt einen Enumerator zurück. 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. Beide werden als OpenEmail::ConflictError ausgelöst, conflict? ist also true, und code unterscheidet sie.