SDK
Członkowie
`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` i `revokeAddress`.
Wszystkie metody
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)Dwa nadania na osobę i nie wolno ich zwijać w jedno. role to, co wolno jej robić; addresses to, do czego wolno jej to robić. Oba muszą się zgadzać: rola z emails:send przy access: "viewer" na invoices@ to ktoś, kto może wysyłać pocztę i nie może wysyłać jej z tego adresu.
Każda metoda przyjmuje userId, a nie adres e-mail. add jest jedynym wyjątkiem i jest zarazem powodem tego wyjątku: jej wywołujący ma adres e-mail i jeszcze żadnego identyfikatora użytkownika, co stanowi całą pierwszą połowę tego, co to wywołanie robi.
implied: true znaczy, że nikt roli nie wybrał. Osoba ma adresy i żadnego wiersza roli, więc rolę wywnioskowano z najszerszego nadania, jakie ma. Traktuj to jako „jeszcze nierozstrzygnięte”, a update jest tym, co zamienia wnioskowanie w decyzję. Do tego czasu poszerzanie jej dostępu do adresów po cichu poszerza to, co wolno jej robić.
Właściciel przestrzeni roboczej jest pierwszym wierszem, oznaczonym isOwner: true, a add, update i remove i tak odrzucają go z member_is_owner. Nieudostępniona przestrzeń robocza raportuje jednego członka, a nie zero, więc licząc stanowiska, wyklucz isOwner.
remove obejmuje obie osie, rolę I każde nadanie adresu w tej przestrzeni roboczej, i raportuje addressesRevoked. revokeAddress jest tym wąskim, dla kogoś, kto zmienił zespół, a nie dla kogoś, kto odszedł.
Parametry
emailstringwymagane- Kogo zaprosić, przycięte i zamienione na małe litery. Nie musi jeszcze mieć konta: zaprasza się każdego, a rola i nadania lądują, gdy przyjmie zaproszenie. Ktoś już w przestrzeni roboczej to `member_is_owner` (422).
roleIdstringwymagane- Rola, którą będzie mieć, od 1 do 128 znaków, i musi to być rola w tej przestrzeni roboczej: nieznany identyfikator to `role_not_found` (404). Roli właściciela nie da się nadać i wraca jako `role_immutable` (409), bo uczynienie kogoś właścicielem to przeniesienie przestrzeni roboczej, a na to nie ma tu wywołania.
addressIdsstring[]- Adresy do przekazania w tym samym wywołaniu, najwyżej 64 identyfikatory po 1 do 128 znaków; identyfikator, który nie jest adresem w tej przestrzeni roboczej, jest odrzucany. Rola jest zapisywana pierwsza, a nadania idą pojedynczo, więc zły identyfikator zostawia utworzonego członka z mniejszą liczbą adresów, niż prosiłeś. Naprawą jest ponowne wysłanie tej samej treści, bo oba zapisy są typu upsert.
access'member' | 'viewer'- Co wolno jej robić z każdym identyfikatorem w `addressIds`: `member` czyta adres i wysyła jako on, `viewer` tylko czyta. Domyślnie `member`, czyli poziom, którego konsola i starsza ścieżka udostępniania używały od zawsze, więc to samo wywołanie znaczy to samo ze skryptu i z ekranu; nadaj mieszankę, wywołując potem `grantAddress` dla tych, które mają się różnić.
Odpowiedź
object'member'- Zawsze `member`. Usunięcie odpowiada tą samą wartością, ich `userId`, `deleted: true` i `addressesRevoked`, i żadnym z pozostałych pól poniżej.
userIdstring- Identyfikator ich konta i uchwyt, który każde inne wywołanie członków przyjmuje w ścieżce: get, update, remove i oba wywołania adresowe. Dodanie kogoś to jedyne wywołanie działające zamiast tego na adresie e-mail, bo ten, kto dodaje współpracownika, zna jego adres, a nie identyfikator.
emailstring- Adres e-mail na ich koncie, odesłany w postaci, w jakiej przechowuje go tamten wiersz. Ten zasób nigdy go nie zapisuje, a zamiana na małe litery w `add` dotyczy adresu wysyłanego do wyszukania, a nie tego, co wraca. Po właścicielu lista członków jest sortowana po nim, a nie po dacie dołączenia, bo listę czyta się, żeby znaleźć jedną osobę, a nie zobaczyć, co się zmieniło.
namestring | null- Ich nazwa wyświetlana, wzięta z konta, gdzie kolumna jest NOT NULL. Null w typie jest zabezpieczeniem, a nie stanem, który to API kiedykolwiek wytworzyło. Należy do nich, a nie do przestrzeni roboczej, więc nic w tym zasobie nie może jej ustawić.
imagestring | null- Ich awatar, wzięty z konta, i null, gdy żadnego nie ustawili.
role.idstring | null- Identyfikator roli, którą mają, albo null, gdy nikt jej nie wybrał. Zobacz `implied`. Null tutaj to jedyny przypadek, w którym `role` raportuje wnioskowanie, a nie czyjąś decyzję.
role.namestring- Nazwa roli. Dla członka z wnioskowania jest to nazwa wbudowanego szablonu, do którego rozwiązał się ich dostęp, a nie wiersz w tej przestrzeni roboczej.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null- Którą wbudowaną rolą ona jest, albo null dla roli własnej. `owner` pojawia się wyłącznie na wierszu samego właściciela, obok `isOwner: true`; przypisanie tej roli komukolwiek jest odrzucane z `role_immutable` (409).
isOwnerboolean- True na dokładnie jednym wierszu, koncie, na którym zawieszona jest przestrzeń robocza. Ma wszystkie uprawnienia niezależnie od tego, co mówi jego wiersz roli, sortuje się pierwszy, a `add`, `update` i `remove` odrzucają go z `member_is_owner`. Wyklucz go, licząc stanowiska.
impliedboolean- True, gdy ta osoba ma nadania adresów i nie ma wiersza członka, więc jej rolę wywnioskowano, a nie wybrano: dowolne nadanie `member` rozwiązuje się do wbudowanej roli Member, w przeciwnym razie do Viewer. Nigdy true dla właściciela. Pokaż to jako „wynika z dostępu”. Dopóki PATCH nie zamieni wnioskowania w decyzję, poszerzanie jej dostępu do adresów po cichu poszerza to, co wolno jej robić.
permissionsPermission[]- Uprawnienia roli spłaszczone na członka, żeby jeden odczyt odpowiadał na pytanie „czy wolno im?” bez pobierania roli. Dla członka z wnioskowania pochodzą z wbudowanego SZABLONU, a nie z wiersza roli tej przestrzeni roboczej, więc edycja wbudowanej roli Member nie zmienia tego, co ma taki członek.
addressesMemberAddress[]- Adresy, które im nadano, posortowane po adresie, każdy z własnym poziomem dostępu. Puste dla kogoś, kto ma rolę i żadnych nadań, i tak właśnie wygląda nowy członek, dopóki nie nada mu się adresu; to właściwy stan, dopóki jeszcze decydujesz, co powinien widzieć.
addresses[].addressIdstring- Identyfikator adresu, przyjmowany przez `grantAddress` i `revokeAddress`. Identyfikator, który nie jest adresem w tej przestrzeni roboczej, jest w obu odrzucany, zamiast raportować cofnięcie, którego nie było.
addresses[].addressstring- Pełny adres, małymi literami, odtworzony z części lokalnej i domeny.
addresses[].access'member' | 'viewer'- Co wolno im robić z tym jednym adresem: `member` czyta go i wysyła jako on, `viewer` tylko czyta. I to, i rola muszą zezwolić na wysyłkę, żeby do niej doszło, więc rola z `emails:send` nad nadaniem `viewer` wysyła z niczego; zapisana kolumna nazywa się `role`, a tutaj jest przemianowana, żeby jeden obiekt nie niósł dwóch pól `role` zaczerpniętych z dwóch słowników.
createdAtstring | null- Kiedy zapisano ich wiersz członka, ISO-8601, i null, gdy wiersza członka w ogóle nie ma. Ten null opisuje tę samą populację co `implied: true`: ludzi, którzy mają adresy sprzed istnienia ról i którym od tamtej pory nikt roli nie nadał.