قوانین دسترسی
قوانین دسترسی راهی است که مدیر فضای کاری با آن تعیین می‌کند چه کسی چه کاری
بکند. هر قاعده یک مجوز (مثلاً createTask یا designWorkflow) را به یک نقش
می‌دهد یا از آن می‌گیرد. موتور قوانین دسترسی که این قاعده‌ها را ارزیابی می‌کند
(ADR-0005) تنها مرجع در همهٔ بخش‌هاست: دکمه‌های اقدام شما، منوی شما، اینکه کدام سند را
می‌توانید باز کنید یا در آن بنویسید، و حتی اینکه این سایت راهنما کدام صفحه‌ها و
نتیجه‌های جست‌وجو را نشانتان بدهد، همه را همین موتور تعیین می‌کند.
مدیریت قوانین دسترسی کار مدیر فضای کاری است و به مجوز manageUsers نیاز دارد.
نقش‌ها و چارت سازمانی را ببینید.
قوانین را کجا ویرایش می‌کنید
قوانین دسترسی صفحهٔ جداگانه ندارند؛ داخل تنظیمات ← نقش‌ها هستند، به شکل جدول دسترسی‌ها در سمت راست نقشِ انتخاب‌شده: یک ردیف برای هر مجوز، که بر اساس حوزه (کاربران، تنظیمات، گردش‌کارها، پروژه‌ها، وظایف، کتابخانه) گروه‌بندی شده، و یک ستون برای اثر قاعده.
خواندن و ویرایش جدول
هر خانهٔ مجوز یک کنترل سهحالت ه است:
- مجاز: اجازهٔ صریح.
- ممنوع: ممنوعیت صریح که همیشه بر «مجاز» در هر لایهٔ دیگر برتری دارد (اول «ممنوع» برنده است؛ پایین‌تر توضیح داده شده).
- — (بدون قاعده): این نقش نه اجازه داده و نه منع کرده؛ وقتی هیچ قاعده‌ای پیدا نشود، پیش‌فرض موتور «ممنوع» است.
تغییرات وقتی روی خانه‌ها کلیک می‌کنید فقط محلی نگه داشته می‌شوند و بعد با ذخیره تغییرات یکجا اعمال می‌شوند؛ جدول تفاوت‌ها را به‌صورت درخواست‌های اضافه/حذف روی موتور اصلی می‌فرستد و با هر کلیک چیزی نمی‌نویسد. حذف یک «مجاز» موجود خطر از دست رفتن دسترسی دارد و پیش از ارسال، تأیید می‌خواهد.
ردیف‌های قفل‌شده: قوانین پایه و قوانین آمده با بسته
بعضی ردیف‌ها نماد قفل دارند و از جدول قابل تغییر نیستند:
- قوانین پایهٔ از پیش‌تعریف‌شده: مجوزهایی که هر فضای کاری در ابتدا با آن‌ها ساخته
می‌شود (مثلاً
tenant_adminکهmanageUsersوmanageTenantSettingsرا دارد، وworkflow_adminکهdesignWorkflowوcreateTaskوstartRunو بقیهٔ مجوزهای طراحی گردش‌کار را دارد؛ این دو عمداً از هم جدا هستند، دلیلش در اصلاحیهٔ ۲۸ ژوئیهٔ ۲۰۲۶ بخش ۱ از ADR-0005 آمده است). - قوانین آمده با بسته:
defaultRulesای که یک بسته هنگام وارد شدن اضافه کرده است. این‌ها را بسته آورده و دستی داده نشده‌اند؛ برای تغییرشان باید بسته را به‌روز کنید یا بردارید، نه اینکه یک خانه را دستی ویرایش کنید.
همچنان می‌توانید کنار یک ردیف قفل‌شده، قاعدهٔ خودتان را اضافه کنید، از جمله یک «ممنوع» محدودتر روی همان مجوز که طبق اولویت «ممنوع» باز هم برنده است.
اولویت «ممنوع» چطور کار می‌کند
موتور مجموعه‌ای ثابت از لایه‌ها را به ترتیب ارزیابی می‌کند: پلتفرم، سازمان، مجوز گردش‌کار، زمینهٔ اجرا، منبع و مشخصات بلوک، و اولین «ممنوع» صریح در هر لایه‌ای برنده است، حتی اگر لایه‌های دیگر اجازه داده باشند. درخواستی که از همهٔ لایه‌ها بدون «ممنوع» رد شود مجاز است، و درخواستی که هیچ قاعده‌ای برایش پیدا نشود به‌طور پیش‌فرض ممنوع است. برای همین مدیر همیشه می‌تواند یک محدودیت باریک‌تر بنویسد (مثلاً «این یک نقش را ممنوع کن، حتی اگر بسته به‌طور کلی به آن اجازه داده») بدون اینکه لازم باشد اجازهٔ کلی‌تر را دست بزند.
جدا از قوانین مخصوص نقش، موتور قوانین باریک‌تری هم در سطح منبع و اجرا دارد که جدول به‌صورت ردیف قابل‌تغییر نشان نمی‌دهد؛ مثلاً مسئول یک وظیفه فقط تا وقتی مرحله‌اش باز است می‌تواند در اسناد همان وظیفه بنویسد، صرف‌نظر از نقش‌هایی که دارد. این‌ها وجود دارند تا یک واقعیتِ ساختاری («این وظیفهٔ شما است، همین حالا») بتواند بدون گسترش دادن یک مجوز نقش که همه‌جا اعمال می‌شود، اقدامی را مجاز کند. مدل کامل در ADR-0005 است.
سابقهٔ ممیزی
هر ارزیابی قوانین برای یک اقدام حساس به‌شکل یک رویداد ممیزی تغییرناپذیر ثبت می‌شود؛
«ممنوع»ها همیشه ثبت می‌شوند و «مجاز» برای اقدام‌های حساس (ان تشار یک تعریف، تأییدها،
افزودن افزونه) هم همیشه ثبت می‌شود. تغییرات قاعده‌های هر نقش
(policy.ruleAdded و policy.ruleRemoved) در سابقهٔ ممیزی همان نقش در صفحهٔ نقش‌ها،
کنار رویدادهای ساخت و به‌روزرسانی نقش دیده می‌شوند.
مطالب مرتبط
- نقش‌ها و چارت سازمانی — نقش‌هایی که این قاعده‌ها برایشان اعمال می‌شود و جایی که جدول در آن قرار دارد.
- گروه‌های کاربری — دادن نقش به‌صورت گروهی.
- مدیریت بسته‌ها — قاعده‌های یک بسته چطور به شکل مجوز قفل‌شده می‌آیند.
- مفاهیم کلیدی — مجوزها و موتور قوانین دسترسی.
اشتباهی دیدید؟ درخواست تغییر بدهید.