پرش به مستندات
SDK

اعضا

`members.list`، `get`، `add`، `update`، `remove`، `grantAddress` و `revokeAddress`.

همهٔ متدها

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)

برای هر فرد دو اعطا وجود دارد و نباید در هم ادغام شوند. role می‌گوید چه کاری مجاز است؛ addresses می‌گوید روی چه چیزی. هر دو باید هم‌داستان باشند: نقشی با emails:send همراه با access: "viewer" روی invoices@ یعنی کسی که می‌تواند ایمیل بفرستد اما نمی‌تواند از آن آدرس بفرستد.

هر متد userId را می‌گیرد، نه ایمیل را. add تنها استثناست، و خودِ دلیل این استثناست: فراخوان آن یک آدرس ایمیل دارد و هنوز هیچ شناسهٔ کاربری ندارد، که دقیقاً نیمهٔ نخست کاری است که آن فراخوانی انجام می‌دهد.

implied: true یعنی هیچ‌کس نقش را انتخاب نکرده است. آن فرد آدرس دارد و ردیف نقش ندارد، پس نقش از گسترده‌ترین اعطایی که دارد استنتاج شده است. آن را «هنوز تصمیم‌گیری نشده» بدانید، و update همان چیزی است که استنتاج را به تصمیم تبدیل می‌کند. تا آن زمان، گسترده‌تر کردن دسترسی آدرسی او بی‌صدا کارهایی را که مجاز است گسترده‌تر می‌کند.

مالک فضای کاری نخستین ردیف است و با isOwner: true نشانه‌گذاری می‌شود، در حالی که add، update و remove همچنان با member_is_owner او را رد می‌کنند. یک فضای کاری به‌اشتراک‌گذاشته‌نشده یک عضو گزارش می‌کند نه صفر عضو، پس وقتی صندلی‌ها را می‌شمارید isOwner را کنار بگذارید.

remove هر دو محور را می‌گیرد، یعنی نقش و همهٔ اعطاهای آدرس روی این فضای کاری، و addressesRevoked را گزارش می‌کند. revokeAddress مورد باریک است، برای کسی که تیمش عوض شده نه کسی که رفته است.

پارامترها

emailstringالزامی
چه کسی دعوت شود، trim‌شده و با حروف کوچک. هنوز لازم نیست حساب داشته باشد: همه دعوت می‌شوند و نقش و اعطاها هنگام پذیرش اعمال می‌شوند. کسی که از پیش در فضای کاری است `member_is_owner` (422) می‌گیرد.
roleIdstringالزامی
نقشی که خواهد داشت، 1 تا 128 نویسه، و باید نقشی روی همین فضای کاری باشد: شناسهٔ ناشناخته `role_not_found` (404 Not Found) است. نقش مالک قابل اعطا نیست و با `role_immutable` (409 Conflict) بازمی‌گردد، چون مالک کردن کسی یعنی انتقال فضای کاری و برای آن اینجا فراخوانی‌ای وجود ندارد.
addressIdsstring[]
آدرس‌هایی که در همان فراخوانی واگذار می‌شوند، حداکثر 64 شناسه که هرکدام 1 تا 128 نویسه است؛ شناسه‌ای که آدرسی روی این فضای کاری نباشد رد می‌شود. نقش نخست نوشته می‌شود و اعطاها یکی‌یکی از پی آن می‌آیند، پس یک شناسهٔ نادرست عضو را با آدرس‌هایی کمتر از آنچه خواسته‌اید ایجاد می‌کند. ارسال دوبارهٔ همان بدنه راه‌حل است، چون هر دو نوشتن upsert هستند.
access'member' | 'viewer'
با هر شناسه در `addressIds` چه می‌تواند بکند: `member` آدرس را می‌خواند و از آن می‌فرستد، `viewer` فقط می‌خواند. پیش‌فرض `member` است، همان سطحی که کنسول و مسیر قدیمی اشتراک‌گذاری همیشه به کار برده‌اند، تا یک فراخوانی از اسکریپت و از صفحه یک معنا بدهد؛ برای ترکیبی از سطوح، بعداً برای موارد متفاوت `grantAddress` را صدا بزنید.

پاسخ

object'member'
همیشه `member`. یک حذف با همین مقدار پاسخ می‌دهد، به‌همراه `userId` او، `deleted: true` و `addressesRevoked`، و هیچ‌یک از فیلدهای دیگرِ زیر.
userIdstring
شناسهٔ حساب او، و همان دستگیره‌ای که هر فراخوانی دیگر عضو در مسیر می‌گیرد: get، update، remove و هر دو فراخوانی آدرس. افزودن کسی تنها فراخوانی‌ای است که به‌جای آن با ایمیل کار می‌کند، چون کسی که همکاری را اضافه می‌کند آدرس او را می‌داند نه شناسه‌اش را.
emailstring
ایمیل روی حساب او، بازتاب‌شده همان‌گونه که آن ردیف ذخیره‌اش می‌کند. این منبع هرگز آن را نمی‌نویسد، و کوچک‌سازی حروف در `add` به آدرسی که برای جست‌وجو می‌فرستید مربوط است نه به آنچه بازمی‌گردد. پس از مالک، فهرست اعضا بر اساس همین فیلد مرتب می‌شود نه بر اساس زمان پیوستن افراد، چون این فهرست برای یافتن یک نفر خوانده می‌شود نه برای دیدن آنچه تغییر کرده است.
namestring | null
نام نمایشی او، گرفته‌شده از حسابش، جایی که آن ستون NOT NULL است. null در تایپ جنبهٔ احتیاطی دارد نه حالتی که از این API دیده شده باشد. این نام به خودِ او تعلق دارد نه به فضای کاری، پس هیچ‌چیز روی این منبع نمی‌تواند آن را تنظیم کند.
imagestring | null
آواتار او، گرفته‌شده از حسابش، و وقتی تنظیمش نکرده باشد null.
role.idstring | null
شناسهٔ نقشی که دارد، یا وقتی هیچ‌کس آن را انتخاب نکرده باشد null. `implied` را ببینید. یک null اینجا تنها موردی است که `role` به‌جای تصمیمِ کسی، یک استنتاج را گزارش می‌کند.
role.namestring
نام نقش. برای عضو implied این نامِ قالب داخلی‌ای است که دسترسی او به آن رسیده است، نه ردیفی روی این فضای کاری.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null
اینکه نقش کدام نقش داخلی است، یا برای نقشی سفارشی null. `owner` تنها روی ردیف خودِ مالک ظاهر می‌شود، در کنار `isOwner: true`؛ اختصاص آن نقش به هر کسی با `role_immutable` (409 Conflict) رد می‌شود.
isOwnerboolean
دقیقاً روی یک ردیف true است، همان حسابی که فضای کاری بر اساس آن کلید خورده است. او هرچه ردیف نقشش بگوید همهٔ مجوزها را دارد، نخست مرتب می‌شود، و `add`، `update` و `remove` همگی او را با `member_is_owner` رد می‌کنند. وقتی صندلی‌ها را می‌شمارید او را کنار بگذارید.
impliedboolean
وقتی true است که این فرد اعطای آدرس داشته باشد و ردیف عضویت نداشته باشد، یعنی نقشش به‌جای انتخاب شدن استنتاج شده است: هر اعطای `member` به Member داخلی می‌رسد و در غیر این صورت به Viewer. برای مالک هرگز true نیست. آن را به‌صورت «استنتاج‌شده از دسترسی» نمایش دهید. تا وقتی یک PATCH استنتاج را به تصمیم تبدیل نکند، گسترده‌تر کردن دسترسی آدرسی او بی‌صدا کارهایی را که مجاز است گسترده‌تر می‌کند.
permissionsPermission[]
مجوزهای نقش که روی عضو صاف شده‌اند، تا یک خواندن به پرسش «آیا مجاز است؟» بدون گرفتن نقش پاسخ دهد. برای عضو implied این مجوزها از قالب داخلی می‌آیند نه از ردیف نقش این فضای کاری، پس ویرایش نقش داخلی Member چیزی را که یک عضو implied دارد تغییر نمی‌دهد.
addressesMemberAddress[]
آدرس‌هایی که به او داده شده‌اند، مرتب‌شده بر اساس آدرس، هرکدام با سطح دسترسی خودش. برای کسی که نقش دارد و اعطایی ندارد خالی است، و یک عضو تازه تا وقتی آدرسی به او داده نشده همین شکل است، و این همان شکستِ درستی است که باید رخ دهد تا وقتی هنوز در حال تصمیم‌گیری دربارهٔ آنچه باید ببیند هستید.
addresses[].addressIdstring
شناسهٔ آدرس، و همان چیزی که `grantAddress` و `revokeAddress` می‌گیرند. شناسه‌ای که آدرسی روی این فضای کاری نباشد در هر دو رد می‌شود، نه اینکه لغوی گزارش شود که هرگز رخ نداده است.
addresses[].addressstring
آدرس کامل، با حروف کوچک، بازسازی‌شده از بخش محلی و دامنه‌اش.
addresses[].access'member' | 'viewer'
با همین یک آدرس چه می‌تواند بکند: `member` آن را می‌خواند و از آن می‌فرستد، `viewer` فقط می‌خواند. پیش از آنکه ارسالی رخ دهد هم این و هم نقش باید اجازه دهند، پس نقشی با `emails:send` روی یک اعطای `viewer` از هیچ‌جا نمی‌فرستد؛ نام ستون ذخیره‌شده `role` است و اینجا تغییر نام یافته تا یک object دو `role` از دو واژگان متفاوت را با خود حمل نکند.
createdAtstring | null
زمان نوشته شدن ردیف عضویت او، ISO-8601، و وقتی اصلاً ردیف عضویتی نباشد null. آن null همان جمعیتی را توصیف می‌کند که `implied: true`: کسانی که از پیش از پیدایش نقش‌ها آدرس دارند و از آن زمان هیچ‌کس نقشی به آنان نداده است.