دادن دسترسی رکورد به یک نقش
هدف
تعیین اینکه هر نقش با رکوردهای یک محیط چه می‌تواند بکند — به‌عنوان بخشی از راه‌حلی که برنامه را عرضه می‌کند، تا همان دسترسی به Test و Prod هم برسد.
پیش‌نیازها
- در مرکز کنترل مدیریت وارد شده‌اید.
- یک راه‌حل باز است (نگاه کنید به ساخت یک راه‌حل).
- جدول‌هایی که می‌خواهید دسترسی به آن‌ها را بدهید در محیط وجود دارند. هر جدول همراه با دادهٔ پشت خود ساخته می‌شود، پس هر جدولی که می‌بینید جدولی است که می‌توانید به آن دسترسی بدهید.
دو پر سش، نه یکی
هر سطر یک نقش به دو پرسش جداگانه پاسخ می‌دهد، و فهمِ همین جدایی بیشترِ فهمِ این صفحه است:
- مجوز — چه کاری می‌تواند بکند؟ ساخت، خواندن، ویرایش، حذف روی یک جدول.
- سیاست — روی کدام رکوردها؟ از رکوردهای خودم، از میان واحد من و زیرمجموعه‌ها، تا همهٔ رکوردها.
به همین دلیل هر خانهٔ جدول یک فهرست کشویی است نه یک چک‌باکس: چک‌باکس تنها به پرسش نخست می‌تواند پاسخ دهد.
دادن نقش به یک تیم
بالای جدول فهرستی از تیم‌های محیط است، هرکدام با یک چک‌باکس. هر کسی در تیمِ تیک‌خورده این نقش را اینجا دارد، افزون بر کسانی که نقش در صفحهٔ کاربران مستقیم به آن‌ها داده شده است. هر دو راه با هم به شمار می‌آیند: کسی که هم در تیمِ تیک‌خورده است و هم نقش را شخصاً دارد، آن را یک بار دارد.
این نیمهٔ دوم معنای گذاشتن کسی در یک تیم است. عضویت تیم از پیش تعیین می‌کرد یک مجوز به کدام رکوردها می‌رسد — سیاست‌های تیم‌های من — و اکنون می‌تواند تعیین کند چه مجوزهایی هم دارد.
این تصمیمِ خودِ سازمان شماست، پس هرگز در یک راه‌حل سفر نمی‌کند. یک بسته نقش و آنچه آن نقش مجاز است انجام دهد را می‌آورد؛ اینکه چه کسی آن را دارد دربارهٔ آدم‌های شماست و ناشر کاری با آن ندارد. پس این فهرست در هر راه‌حلی که ایستاده باشید یکی است، و حذف نصب به آن دست نمی‌زند.
در درخواست بعدی اثر می‌کند، مثل هر تغییر دیگری در این صفحه — از جمله وقتی کسی بعداً به تیم می‌پیوندد یا از آن بیرون می‌رود.
اختیارات پلتفرم — چیزهایی که دربارهٔ جدول نیستند
بالای جدول فهرست کوتاهی از چک‌باکس‌هاست: درون‌ریزی یک راه‌حل، برون‌بری یک راه‌حل، درون‌ریزی داده. این‌ها توانایی‌هایی هستند که جدولی پشتشان نیست، پس پرسش دوم دربارهٔ آن ها معنا ندارد — رکوردی نیست که سیاستی صافی‌اش کند. یا داده شده‌اند یا نه، و به همین دلیل چک‌باکس‌اند نه فهرست کشویی.
آن‌ها به‌تفکیک محیط نگه داشته می‌شوند، مثل هر چیز دیگری در این صفحه: نقشی که می‌تواند در Dev راه‌حلی را درون‌ریزی کند، با همین کار در Prod چنین اجازه‌ای پیدا نمی‌کند.
مدیریت کاربران و نقش‌ها اینجا نیست، و این عمدی است نه فراموش‌شده. کاربران و نقش‌ها در سطح مستأجر هستند — در هر محیطی که باشید وجود دارند — پس «اجازهٔ مدیریت کاربران، در Dev» جمله‌ای است که معنایی ندارد. آن‌ها نزد مدیر پلتفرم می‌مانند.
سطر «همهٔ جدول‌ها» یک اختیار را پوشش نمی‌دهد. معنایش هر جدول است، و پلتفرم جدول نیست. یک اختیار با تیک‌زدنش اعطا می‌شود.
گام‌ها
- راه‌حل‌ها را باز کنید و راه‌حلی را که برنامه‌تان در آن است باز کنید.
- در ناوبری راه‌حل، نقش‌ها را باز کنید.
- یا جدید را بزنید تا نقشی بسازید که این راه‌حل مالکش است، یا افزودن نقش موجود را بزنید تا به نقشی که سازمانتان از پیش دارد دسترس ی بدهید.
- در جدول، هر خانه را روی یک سیاست بگذارید، یا روی اعطا نشده رها کنید.
- نخستین سطر همهٔ جدول‌ها است. اعطای مجوز آنجا هر جدولی را دربر می‌گیرد — از جمله جدول‌هایی که بعداً می‌سازید، که اعطای سطر‌به‌سطر آن‌ها را دربر نمی‌گرفت.
- ذخیره را بزنید.
تغییر در درخواست بعدی اثر می‌کند. انتظاری در کار نیست.
چرا این کار درون یک راه‌حل است و چرا هرگز از محیط نمی‌پرسد
مجوز نام یک جدول را می‌برد و جدول‌ها به یک محیط تعلق دارند؛ و دسترسی‌ای که باید به Test و Prod برسد باید در یک بسته سفر کند. باز کردن یک راه‌حل هر دو را از پیش تعیین کرده است — هر راه‌حل به یک محیط تعلق دارد — پس این صفحه محیطی برای پرسیدن ندارد. برای دادن دسترسی متفاوت در جای دیگر، راه‌حل را برون‌ریزی و آنجا درون‌ریزی کنید، یا محیط را عوض کنید و در راه‌حل همان محیط کار کنید.
فهرست چه نقش‌هایی را نشان می‌دهد
یک نقش به دو دلیل در راه‌حل است و هر دو در فهرست دیده می‌شوند:
- راه‌حل مالکش است — با جدید اینجا ساخته شده، پس نام منطقی‌اش پیشوند ناشر را دارد
(
par_sales). - راه‌حل چیزی به آن اعطا می‌کند — نقشی که سازمانتان از پیش داشته و با افزودن نقش موجود آورده شده است.
افزودن یک نقش موجود به‌تنهایی چیزی نمی‌نویسد؛ همان لحظه که چیزی به آن اعطا و ذخیره کنید به
راه‌حل می‌پیوندد. اعطای چیزی به نقش sales خودتان هرگز آن را به ناشر نمی‌سپارد: اینکه نقشی به
یک بسته تعلق دارد یا نه با پیشوندش تعیین می‌شود، پس حذف نصب نمی‌تواند نقش شما را ببرد.
برداشتن از راه‌حل تنها اعطاهایی را که همین راه‌حل می‌کند پاک می‌کند. نقشی که راه‌حل مالکش است این‌گونه برداشته نمی‌شود — به بسته تعلق دارد، پس برداشتنش یعنی حذف نقش در صفحهٔ نقش‌های مرکز کنترل مدیریت.
لایه‌ای که ویرایش می‌کنید
خانه‌ها آنچه را این راه‌حل اعطا می‌کند نشان می‌دهند. هرجا لایه‌ای دیگر چیزی را اعطا کرده باشد که این راه‌حل خالی گذاشته، خانه همان را می‌گوید — از جای دیگری اعطا شده: … — به‌جای آنکه در هم بیامیزد. این تمایز مهم است چون صفحه همان چیزی را می‌نویسد که نشان می‌دهد: اگر پاسخ ادغام‌شده را نشان می‌داد، یک بار ذخیره ویرایش‌های محلی شما و اعطاهای راه‌حل‌های دیگر را وارد بستهٔ شما می‌کرد.
راه‌حل پیش‌فرض (Main) استثناست. بسته نیست، پس جدولش اعطاهای خودِ محیط شما را ویرایش می‌کند: در هیچ بسته‌ای سفر نمی‌کنند و بر هر چیزی که راه‌حل‌ها می‌دهند مقدم‌اند. تنظیم محلی‌ای که نمی‌خواهید عرضه شود همان‌جاست.
رونوشت‌گرفتن از یک نقش
دو نقش که در یکی دو خانه با هم فرق دارند رایج‌اند — «فروش» و «مدیر فروش»، «پشتیبانی» و «سرپرست پشتیبانی» — و دادن دسترسی‌های دومی خانه‌به‌خانه همان راهی است که به نقش امنیتی‌ای می‌رسد که جایی با خواهرش فرق دارد بی‌آنکه کسی خواسته باشد.
- نقشی را که می‌خواهید از آن آغاز کنید باز کنید.
- رونوشت نقش را انتخاب کنید.
- به نقش تازه یک نام نمایشی بدهید، نامی که در صفحهٔ نقش‌ها و فهرست کاربران خوانده می‌شود، مثلاً فروش میدانی (فقط خواندنی).
- به نقش تازه یک نام منطقی بدهید (پیشونددار، مانند هر مؤلفهٔ دیگری که این راه‌حل می‌سازد).
- رونوشت را بزنید، خانه‌هایی را که باید فرق کنند تنظیم کنید و ذخیره کنید.
رونوشت، دسترسی‌ها را همان‌طور که روی صفحه‌اند برمی‌دارد، از جمله ویرایش‌هایی که هنوز ذخیره نکرده‌اید — رونوشت‌گرفتن از نقشی که همین حالا تنظیمش می‌کردید باید همان چیزی را بردارد که می‌بینید.
دو کار را عمداً انجام نمی‌دهد:
- در محیط‌های دیگر رونوشت نمی‌گیرد. فقط همین یکی. همان نقش در توسعه و تولید معناهای متفاوتی دارد، پس رونوشت‌گرفتن از «کارهایی که این نقش مجاز است» تنها می‌تواند به‌معنای کارهایی باشد که اینجا مجاز است.
- دارندگان نقش را رونوشت نمی‌کند. آن‌ها افراد شما هستند و رونوشت‌گرفتن از یک نقش دلیلی برای رونوشت‌گرفتن از عضویتش نیست. نقش تازه را به هرکس که باید داشته باشد تخصیص دهید (به «تخصیص یک نقش به یک کاربر» مراجعه کنید).
محیط تازه با چه چیزی آغاز می‌شود
تنها نقش سازنده، با همه‌چیز روی همهٔ جدول‌ها و هر سه اختیار پلتفرم. هر نقش دیگری با هیچ آغاز می‌کند — حتی نقشی که کاربری از پیش دارد. این عمدی است: دسترسی چیزی است که کسی اعطا کرده، و «هیچ» تنها پیش‌فرضی است که اشتباه بودنش بی‌خطر است.
مدیر سازمان اصلاً در جدول نیست. او بنا به تعریف به همه‌چیز دسترسی دارد و این صفحه را دور می‌زند، تا برداشتنِ اشتباهِ یک دسترسی هرگز نتواند شما را از همان صفحه‌ای که آن را برمی‌گرداند بیرون بیندازد.
وقتی نقش را یک راه‌حل می‌آورد
یک راه‌حل نصب‌شده می‌تواند نقش‌های امنیتی با خود بیاورد — نقش و آنچه مجاز است انجام دهد — چون برنامه‌ای که بدون نقش‌هایش عرضه شود برنامه‌ای است که کسی نمی‌تواند از آن استفاده کند. آن اعطاها همان لحظه که نصب راه‌حل تمام می‌شود در جای خودند؛ کسی لازم نیست دوباره اعطایشان کند.
باز هم می‌توانید از راه‌حل Main تغییرشان دهید، و تغییر شما برنده است:
- یک خانه را تنگ‌تر یا گشاده‌تر کنید و آنچه اعمال می‌شود تنظیم شماست، هر چه راه‌حل گذاشته باشد.
- یک خانه را به «اعطا نشده» بازگردانید و اعطا نشده می‌ماند — اعطای راه‌حل بار بعد که صفحه را باز کنید بازنمی‌گردد.
- راه‌حل را به‌روز کنید و تغییرهای شما می‌مانند. درون‌ریزی، اعطاهای خودِ راه‌حل را تازه می‌کند و اعطاهای شما را دست‌نخورده می‌گذارد.
- نصب راه‌حل را حذف کنید و اعطاهایش با آن می‌روند. هر چه شما گذاشته‌اید می‌ماند؛ خانه‌ای که تغییر داده بودید به مقدارِ شما بازمی‌گردد، و خانه‌ای که تنها راه‌حل اعطا کرده بود «اعطا نشده» می‌شود.
اینکه چه کسی نقشی را در اختیار دارد هرگز بخشی از بسته نیست. آن‌ها آدم‌های شمایند و انتساب نقش همیشه کاری است که کسی همین‌جا انجام می‌دهد (نگاه کنید به انتساب یک نقش به یک کاربر).
سیاست‌ها، از تنگ‌ترین به گشاده‌ترین
هر یک از این‌ها برگزیدنی است و هر یک اعمال می‌شود:
| سیاست | تا کجا می‌رسد |
|---|---|
| هیچ رکوردی | هیچ. مجوزی که این‌گونه اعطا شود کاری نمی‌کند — تنها به کار خاموش کردن چیزی بدون برداشتن سطر می‌آید. |
| رکوردهای خودم | رکوردهایی که این کاربر شخصاً مالکشان است. |
| خودم و تیم‌هایم | مورد بالا، به‌علاوهٔ رکوردهایی که هر تیمِ او مالکشان است. |
| رکوردهای تیم‌هایم | رکوردهایی که تیمی از تیم‌های او مالکشان است. |
| واحد من | رکوردهایی که مالکشان درون واحد سازمانی خود اوست. |
| واحد من و زیرمجموعه‌ها | واحد او و هر واحدی زیر آن. |
| واحد من و بالادستی‌ها | واحد او و هر واحدی که به آن گزارش می‌دهد. |
| تمام شاخهٔ من | بالاترین واحد بالای او، و هر چه زیر آن است. |
| همهٔ رکوردها | تمام محیط. |
همه به‌جز همهٔ رکوردها به این بستگی دارند که مالکِ رکورد کیست و واحدها کجای سازمان می‌نشینند. مالک رکورد هنگام ساخت آن تعیین می‌شود و بعداً هم می‌توان آن را واگذار کرد (نگاه کنید به تغییر مالک یک رکورد)؛ واحدها و تیم‌ها جدول‌هایی در محیط‌اند، پس سازمانتان را آنجا می‌سازید و سیاست‌ها از آن پیروی می‌کنند.
واحدِ هر رکورد، واحدِ مالک آن است؛ هنگام ساختن رکورد تعیین می‌شود و هر بار که به کس دیگری سپرده شود دوباره. جابه‌جاییِ بعدیِ یک شخص به واحدی دیگر، رکوردهایی را که از پیش دارد جابه‌جا نمی‌کند؛ اگر باید همراه او بروند، آن‌ها را دوباره واگذار کنید. رکوردهای شخصی که واحدی ندارد به هیچ سیاستِ واحدی نمی‌رسند.
سیاستی که موتور نتواند ارزیابی‌اش کند زیر جدول فهرست می‌شود اما برگزیدنی نیست — اعطایی که موتور نتواند ارزیابی کند روی این صفحه دسترسی‌ای نشان می‌دهد که کاربر در واقع ندارد. امروز هر سیاست درون‌ساخته ارزیابی‌پذیر است، پس چیزی آنجا نمایش داده نمی‌شود.
کاربر با یک اعطای تنگ چه می‌بیند
فرمان‌هایی که نقش کاربر به آن‌ها نمی‌رسد به او نشان داده نمی‌شوند. در جدولی که اجازهٔ ساخت رکورد در آن را ندارد دکمهٔ جدید نیست؛ در جدولی که اجازهٔ حذف ندارد حذف نیست؛ و جدولی که می‌تواند بخواند اما تغییر دهد نه، رکوردهایش را فقط‌خواندنی و بدون ذخیره باز می‌کند. پس اعطای تنگ‌تر همچون برنامه‌ای ساده‌تر خوانده می‌شود نه دیواری از ردها — و مجوز هر بار روی سرور بررسی می‌شود، هرچه صفحه نمایش داده باشد.
عیب‌یابی
- «… is not a permission this environment can grant.» — جدول پس از نوشته شدن نقش حذف شده است. صفحه را دوباره باز کنید و اعطا را از نو تنظیم کنید.
- «… is listed twice.» — یک نقش هر مجوز را دقیقاً زیر یک سیاست دارد. خانه را یک بار تنظیم کنید.
- کاربر پس از اعطای نقش هنوز رکوردی نمی بیند. — ببینید توکن او واقعاً چه نقشی را حمل می‌کند؛ اعطا به «Sales» برای کاربری که ادعایش «sales» است کاری نمی‌کند. اگر نقش را به یک تیم داده‌اید، ببینید او در آن تیم هست — در بخش تیم‌ها.
- فهرست تیم‌ها روی صفحه نیست. — محیط هنوز تیمی ندارد، یا مدل سازمانی‌اش کاشته نشده است. در بخش تیم‌ها تیمی بسازید و نقش را دوباره باز کنید.
- همه‌چیز را برداشتم و حالا هیچ‌کس نمی‌تواند از برنامه استفاده کند. — همین کار را می‌کند. نقش را دوباره اعطا کنید؛ دسترسی خودتان به‌عنوان مدیر دست‌نخورده است.
- «شما اختیار … را در این محیط ندارید.» — کسی می‌کوشد یک صفحه‌گسترده را درون‌ریزی کند، یا راه‌حلی را درون‌ریزی/برون‌بری کند، و نقشش تیک آن را ندارد. در اختیارات پلتفرم بالای جدول تیکش بزنید.
- «… یک اختیار پلتفرم است، پس یا داده شده یا نه.» — اختیاری همراه با یک سیاست فرستاده شده است. هیچ‌چیز روی صفحه نمی‌تواند چنین کند؛ این از بستهٔ راه‌حلی می‌آید که سیاستی برایش نوشته است.
- جدول خالی است. — بالای پنجره محیطی برگزیده نشده، یا آن محیط هنوز جدولی ندارد.
- نقشی که افزوده بودم از فهرست ناپدید شده. — آن را بدون هیچ اعطایی ذخیره کرده‌اید. نقش وقتی در راه‌حل است که راه‌حل چیزی به آن اعطا کند؛ دوباره بیفزاییدش و چیزی به آن بدهید.
- در Dev به نقش دسترسی دادم و در Prod چیزی تغییر نکرد. — طبیعی است: دسترسی‌ها به‌تفکیک محیط هستند. راه‌حل را برون‌ریزی و در Prod درون‌ریزی کنید (نگاه کنید به درون‌ریزی یک راه‌حل به یک محیط) — که دقیقاً همان کاری است که گذاشتن اعطاها در یک راه‌حل برای آن است.
سناریوهای مرتبط
- نوشتن یک سیاست داده — وقتی هیچ‌کدام از سیاست‌های درون‌ساخته آنچه را می‌خواهید نمی‌گوید.
- گذاشتن یک کاربر در یک تیم — آنچه سیاست‌های تیمی می‌خوانند.
- ساخت یک نقش.
- دادن نقش به کاربر.