پایگاه دانش
نقشها و سطوح دسترسی
نقش میگوید یک نفر چه کاری میتواند بکند؛ اعطای نشانی میگوید آن کار را روی چه چیزی میتواند انجام دهد.
جزئیات
- برای هر شخص دو اعطا وجود دارد و پیش از هر اتفاقی باید هر دو با هم بخوانند. نقش، که در تنظیمات ← اعضا تعیین میشود، میگوید آن شخص در فضای کاری چه کاری میتواند انجام دهد: خواندن ایمیل، فرستادن آن، ویرایش قالبها، افزودن دامنه، ساختن کلید API. اعطای نشانی، که از کنترل «اشتراکگذاری» روی ردیف نشانی تعیین میشود، میگوید آن کار را روی کدام نشانیها میتواند انجام دهد، بهصورت فقطخواندنی یا خواندن و ارسال. کسی که نقشی با اجازهٔ ارسال دارد اما هیچ نشانی ندارد، از هیچجا نمیتواند بفرستد؛ کسی هم که همهٔ نشانیهای فضای کاری را با اعطای فقطخواندنی در اختیار دارد، از هیچکدامشان نمیتواند بفرستد.
- شش نقش بدون آنکه کسی آنها را بسازد وجود دارند و هر فضای کاری همان شش نقش را دارد؛ پس «Admin» اینجا همان معنایی را دارد که در مستندات و روی API دارد. Owner، Admin، Member و Viewer یک نردباناند: هر کدام هرچه را نقش بعدی دارد در خود دارد؛ پس پایینآوردن نقش یک نفر دامنهٔ دسترسی او را تنگتر میکند، نه اینکه آن را با بخشی متفاوت عوض کند. Developer و Billing پلههای این نردبان نیستند. Developer یکپارچهسازی میسازد و کلیدهای API، وبهوکها، قالبها و ارسال را در اختیار دارد، بیآنکه هیچیک از ایمیلهای فضای کاری را بخواند؛ و Billing پلن و صورتحسابها را میبیند، میتواند پلن و جزئیات پرداخت روی آنها را تغییر دهد، و تنظیمات صندوق را میخواند بیآنکه بتواند چیزی در آن بنویسد. دسترسیهای این نقشها قابل ویرایش است: فضای کاریای که ترجیح میدهد اعضایش قالبها را ننویسند تیک آن را برمیدارد، و تغییر در نخستین درخواستِ هر کسی که صراحتاً آن نقش را دارد اعمال میشود. کسی که نقشش هنوز از روی یک اعطای نشانیِ مربوط به پیش از پیدایش نقشها استنباط میشود، تا وقتی نقشی صریح به او داده نشود همان پیشفرضهای اولیه را نگه میدارد. نامهایشان هم قابل ویرایشاند: فضای کاریای که با Ops و On-call کار میکند آنها را تغییر نام میدهد و در واقع خودش را توصیف میکند، و نکته همین است.
- Owner از هر جهت استثناست: نه قابل ویرایش، نه قابل حذف، نه قابل واگذاری. این نقش توصیفکنندهٔ حسابی است که فضای کاری بر پایهٔ آن ساخته شده و همهٔ دسترسیها را دارد، از جمله دسترسیهایی که در نسخههای بعدی اضافه میشوند؛ به همین دلیل فهرست آن محاسبه میشود و ذخیره نمیشود. سپردن فضای کاری به شخصی دیگر یک انتقال است، نه تغییر نقش، و اینجا چیزی که چنین کاری بکند وجود ندارد.
- فراتر از اینها، هر فضای کاری نقشهای خودش را مینویسد، مجموعاً تا 24 نقش، با تیکزدن دسترسیها از همان ماتریس گروهبندیشده. تیکزدن، لازمهاش را هم در پی میآورد: «ویرایش قالبها» «خواندن قالبها» را کنار آن ذخیره میکند، چون نقشی که بتواند قالبی را ویرایش کند که نمیتواند بازش کند، تیکی است که کسی فراموشش کرده، نه سیاستی که کسی منظورش بوده باشد. حذف نقشی که افراد یا کلیدهای API آن را دارند میپرسد آنها را به کجا منتقل کند و بهجای حدسزدن امتناع میکند. کلیدی که نقشش ناپدید شده باشد به حالت بدون هیچ سقفی برمیگردد، که گستردهتر از نقشی است که همین حالا حذف شد.
- یک کلید API را میتوان در برابر یک نقش صادر کرد، و نقش یک سقف است، نه اعطای دوم: آنچه کلید میتواند انجام دهد اشتراک اسکوپهای خودش با دسترسیهای نقش است که در هر درخواست محاسبه میشود. کلیدی که با اجازهٔ ارسال ساخته شده و زیر سقف Viewer قرار گرفته نمیتواند بفرستد، و تنگکردن یک نقش آن دسترسی را بیدرنگ و بدون نیاز به چرخاندن کلید لغو میکند. دستیار هم به همین فهرست پایبند است و سرور MCP ابزارهای کلاینت را از روی دسترسیهای فراخوان میسازد؛ پس کلاینتِ یک Viewer اصلاً ابزار ارسال ندارد، و هر ابزار محدودشده هنگام ورود دوباره بررسی میشود، چون یک نشست میتواند پس از ساختهشدن فهرست، صندوق را عوض کند.