دسترسیها
وضعیت سند
آماده بازبینی محصول — استخراجشده از سناریوها، User Flowها و Workflowهای ماژول راهاندازی ساختمان و عضویت.
۱. هدف و مرزبندی
این سند مشخص میکند چه Roleی با کدام Permission و در چه Scope میتواند Actionهای ماژول راهاندازی و عضویت را انجام دهد.
این سند شامل موارد زیر است:
- دسترسی به Setup Dashboard؛
- مدیریت واحدها و اشخاص؛
- تعیین ساختار مدیریت و کارکنان؛
- مدیریت Role Templateهای این ماژول؛
- ایجاد و مدیریت Invitation؛
- پایان و جایگزینی روابط و Roleها؛
- نقطه ورود تنظیمات مالی و امکانات؛
- دسترسی موقت پشتیبانی.
این سند شامل Permissionهای تفصیلی عملیات روزانه ماژول مالی، رزرو امکانات، ارتباطات، تعمیرات یا گزارشها نیست.
۲. تصمیم اصلی نقش
Important
«مدیر راهاندازی ساختمان» و «ادمین ساختمان» دو نام برای یک Role هستند و نباید دو Role Assignment جدا ایجاد کنند.
Role canonical
- Code:
BUILDING_ADMIN - عنوان هنگام راهاندازی: مدیر راهاندازی ساختمان
- عنوان پس از راهاندازی: ادمین ساختمان
- Scope: یک ساختمان
- روش ایجاد اولیه: پس از پرداخت موفق و ایجاد ساختمان
- روش انتقال: فقط از مسیر Support Ticket
- پایان خودکار پس از Setup: ندارد
تغییر عنوان نمایشی در Contextهای مختلف، Code یا Permissionهای Role را تغییر نمیدهد.
تفاوت با مدیر ساختمان
| Role | مسئولیت اصلی |
|---|---|
BUILDING_ADMIN |
پیکربندی Workspace، ساختار ساختمان، Role Templateها و راهاندازی |
BUILDING_MANAGER |
عملیات روزانه ساختمان و مدیریت جاری اشخاص و فرایندها |
در ساختمان کوچک یک شخص میتواند هر دو Role را داشته باشد، اما Roleها و Permissionهای آنها مستقل باقی میمانند.
۳. اصول دسترسی
- نبود Permission صریح به معنی رد دسترسی است.
- Permission مستقیم به Person یا Account داده نمیشود.
- Permission از Role Template فعال ساختمان به Role Assignment میرسد.
- Per-person Override در نسخه اولیه وجود ندارد.
- هر Action باید در Scope همان Building، Unit، Facility، Assignment یا Ticket بررسی شود.
- Role در وضعیت
PENDING_ACCEPTANCEهیچ Permission فعالی ندارد. - Import اشخاص یا ثبت موقعیت بدون متصدی Permission ایجاد نمیکند.
- مشاهده Action در UI به معنی مجازبودن اجرای آن نیست و Authorization در هر درخواست دوباره ارزیابی میشود.
۴. Actorها و Roleهای مرتبط
Roleهای داخل ساختمان
| Code | عنوان | نوع |
|---|---|---|
BUILDING_ADMIN |
ادمین ساختمان / مدیر راهاندازی | اصلی و الزامی |
BUILDING_MANAGER |
مدیر ساختمان | عملیاتی |
BOARD_CHAIR |
رئیس هیئتمدیره | حاکمیتی |
BOARD_MEMBER |
عضو هیئتمدیره | حاکمیتی |
TREASURER |
خزانهدار | نظارت مالی |
INSPECTOR |
بازرس | نظارتی |
ACCOUNTANT |
حسابدار | مالی |
FACILITY_MANAGER |
مدیر عملیات یا تأسیسات | عملیاتی |
CONCIERGE |
لابیمن | عملیاتی |
SECURITY_GUARD |
نگهبان | عملیاتی |
JANITOR |
سرایدار | عملیاتی |
TECHNICIAN |
تعمیرکار | Assignment-based |
CONTRACTOR |
پیمانکار | Assignment-based |
روابط عملیاتی بدون Permission مدیریتی
- مالک
- مستأجر
- ساکن
- عضو خانواده
این روابط Membership عملیاتی، Charge، Bill و SMS را ممکن میکنند، اما بهتنهایی Permission مدیریتی داخل اپ ایجاد نمیکنند.
Roleهای پلتفرم
| Code | عنوان | کاربرد |
|---|---|---|
PLATFORM_ADMIN |
ادمین پلتفرم | اعطا، لغو یا Break-glass دسترسی پشتیبانی |
SUPPORT_ADMIN |
پشتیبان مجاز | استفاده از Support Access Grant محدود |
۵. فرمول دسترسی مؤثر
Account Link معتبر
AND Building Membership فعال
AND Role Assignment فعال
AND Role Template شامل Permission
AND Scope با Resource منطبق
AND Guardهای Workflow برقرار
AND Policy تکمیلی اجازه دهد
AND Role یا Access Grant معلق یا منقضی نباشد
برای تصمیم شخص درباره Role پیشنهادی خودش، Invitation معتبر، تطبیق شماره موبایل و OTP جای Role مدیریتی را میگیرند.
flowchart TD
accTitle: ارزیابی دسترسی در ماژول راهاندازی و عضویت
accDescr: سامانه هویت، عضویت، نقش، Permission، Scope و Guard را برای هر Action بررسی میکند
START(["درخواست انجام Action"]):::start
IDENTITY{"Account Link یا هویت لازم معتبر است؟"}:::decision
MEMBERSHIP{"Membership لازم فعال است؟"}:::decision
ROLE{"Role Assignment فعال است؟"}:::decision
PERMISSION{"Role Template شامل Permission است؟"}:::decision
SCOPE{"Scope با Resource منطبق است؟"}:::decision
GUARD{"Guard و Policy برقرار است؟"}:::decision
SUSPENDED{"Role یا Grant معلق یا منقضی است؟"}:::decision
ALLOW(["اجازه Action و ثبت Audit لازم"]):::success
DENY(["رد امن دسترسی"]):::error
START --> IDENTITY
IDENTITY -->|"خیر"| DENY
IDENTITY -->|"بله"| MEMBERSHIP
MEMBERSHIP -->|"خیر"| DENY
MEMBERSHIP -->|"بله"| ROLE
ROLE -->|"خیر"| DENY
ROLE -->|"بله"| PERMISSION
PERMISSION -->|"خیر"| DENY
PERMISSION -->|"بله"| SCOPE
SCOPE -->|"خیر"| DENY
SCOPE -->|"بله"| GUARD
GUARD -->|"خیر"| DENY
GUARD -->|"بله"| SUSPENDED
SUSPENDED -->|"بله"| DENY
SUSPENDED -->|"خیر"| ALLOW
classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px;
classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px;
classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px;
classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;
۶. Permission Catalog
۶.۱. Setup و اطلاعات پایه
| Permission | عنوان | Scope | حساسیت | Guard اصلی |
|---|---|---|---|---|
setup.view |
مشاهده وضعیت راهاندازی | BUILDING |
عادی | Membership فعال |
setup.manage |
مدیریت وضعیت و بخشهای راهاندازی | BUILDING |
مهم | Building فعال |
building.profile.edit |
ویرایش اطلاعات پایه ساختمان | BUILDING |
مهم | فیلد در محدوده تنظیمات عمومی باشد |
setup.progress.override |
اصلاح اداری وضعیت پیشرفت | BUILDING |
حساس | فقط اقدام پشتیبانی Ticket-based |
setup.progress.override برای تکمیل مصنوعی بخش بدون داده معتبر نیست؛ فقط برای اصلاح وضعیت ناسازگار پس از بررسی پشتیبانی استفاده میشود.
۶.۲. واحدها، اشخاص و روابط
| Permission | عنوان | Scope | حساسیت | Guard اصلی |
|---|---|---|---|---|
unit.view |
مشاهده فهرست واحدها | BUILDING |
عادی | Scope ساختمان |
unit.manage |
ایجاد و ویرایش واحد | BUILDING |
مهم | داده واحد معتبر |
person.view |
مشاهده اشخاص ساختمان | BUILDING |
مهم | حداقلسازی داده |
person.manage |
ثبت و اصلاح Person Record | BUILDING |
مهم | جلوگیری از رکورد تکراری |
person.private.view |
مشاهده اطلاعات خصوصی لازم | BUILDING |
حساس | نیاز عملیاتی و Audit |
relationship.tenancy.manage |
پایان یا جایگزینی مستأجر و Household | UNIT |
مهم | Effective Date معتبر |
relationship.ownership.transfer |
انتقال مالکیت | UNIT |
بحرانی | مدرک، Effective Date و Audit |
relationship.staff.manage |
پایان یا جایگزینی کارکن و سرویسکار | BUILDING یا ASSIGNMENT |
مهم | تعیین تکلیف Task و Shift باز |
unit.import |
Import واحدها و اشخاص با Excel | BUILDING |
مهم | فایل بدون خطای مسدودکننده |
۶.۳. ساختار مدیریت، Role و Permission
| Permission | عنوان | Scope | حساسیت | Guard اصلی |
|---|---|---|---|---|
governance.view |
مشاهده ساختار مدیریت | BUILDING |
عادی | Membership فعال |
governance.manage |
تغییر مدل مدیریت و Roleهای حاکمیتی | BUILDING |
حساس | Audit و Role معتبر |
staff_structure.view |
مشاهده موقعیتهای کارکنان | BUILDING |
عادی | Membership فعال |
staff_structure.manage |
ایجاد و تغییر موقعیتهای کارکنان | BUILDING |
مهم | Role Template معتبر |
role_template.view |
مشاهده خلاصه Role Template | BUILDING |
عادی | Membership فعال |
role_template.manage |
تغییر Permissionهای Role Template | BUILDING |
حساس | نمایش افراد متأثر و Audit |
permission_sensitive.manage |
افزودن یا حذف Permission حساس | BUILDING |
بحرانی | تأیید صریح و Audit تقویتشده |
role_assignment.view |
مشاهده Role Assignmentها | BUILDING |
مهم | Scope ساختمان |
role_assignment.operational.manage |
تخصیص یا پایان Role عملیاتی | BUILDING |
حساس | Role Template فعال و Scope معتبر |
role_assignment.governance.manage |
تخصیص یا پایان Role حاکمیتی | BUILDING |
بحرانی | Building Admin و Audit |
Roleهای BUILDING_ADMIN و پلتفرم از طریق Permission عمومی Role Assignment قابل تخصیص نیستند.
۶.۴. Invitation
| Permission | عنوان | Scope | حساسیت | Guard اصلی |
|---|---|---|---|---|
invitation.view |
مشاهده Invitationها | BUILDING |
مهم | محدود به ساختمان |
invitation.send |
ایجاد و ارسال فردی یا گروهی | BUILDING |
مهم | موبایل، Role، Scope و موجودی معتبر |
invitation.resend |
ارسال مجدد | BUILDING |
مهم | فاصله ۲۴ ساعت و موجودی کافی |
invitation.edit_pending |
ویرایش Role یا Scope در انتظار | BUILDING |
حساس | فقط Roleهای Pending |
invitation.cancel |
لغو Envelope در انتظار | BUILDING |
حساس | دلیل برای Role حساس |
۶.۵. تنظیمات مالی و امکانات
| Permission | عنوان | Scope | حساسیت | Guard اصلی |
|---|---|---|---|---|
finance_setup.view |
مشاهده وضعیت راهاندازی مالی | BUILDING |
مهم | Membership فعال |
finance_setup.manage |
تعریف روش دریافت اولیه | BUILDING |
حساس | Financial Policy |
settlement_destination.manage |
ثبت یا تغییر مقصد تسویه | BUILDING |
بحرانی | تأیید نهایی Building Admin |
manual_payment.submit |
ثبت قبض کارتبهکارت یا حساببهحساب | UNIT |
مهم | رابطه معتبر با واحد و Bill قابل پرداخت |
manual_payment.review |
مشاهده صف قبضهای در انتظار | BUILDING |
حساس | Role مالی مجاز و حداقلسازی اطلاعات |
manual_payment.approve |
تأیید قبض و اعمال Payment روی مانده | UNIT یا BUILDING |
بحرانی | قبض معتبر، جلوگیری از تأیید تکراری و Audit |
manual_payment.reject |
رد قبض با دلیل | UNIT یا BUILDING |
حساس | قبض در وضعیت قابل بررسی |
facility.view |
مشاهده امکانات و وضعیت تنظیمات | BUILDING |
عادی | Membership فعال |
facility.configure |
ایجاد و تغییر Facility و قواعد پایه | FACILITY یا BUILDING |
حساس | Guardهای فعالسازی Facility |
ساخت، تأیید و Publish شارژ در Permission Catalog ماژول مالی تعریف میشود.
۶.۶. Audit، پشتیبانی و انتقال ادمین ساختمان
| Permission | عنوان | Scope | حساسیت | Guard اصلی |
|---|---|---|---|---|
audit.operational.view |
مشاهده رویدادهای عملیاتی مرتبط | BUILDING |
مهم | محدودسازی اطلاعات حساس |
audit.access.view |
مشاهده تغییرات Role و Permission | BUILDING |
حساس | Building Admin |
building_admin_transfer.request |
ثبت درخواست تغییر ادمین ساختمان | BUILDING |
حساس | Ticket و مدارک |
building_admin_transfer.execute |
اجرای جابهجایی اتمیک | TICKET و BUILDING |
بحرانی | فقط پشتیبانی مجاز |
support_access.grant |
ایجاد Support Access Grant | PLATFORM |
بحرانی | Platform Admin و Ticket |
support_access.use |
استفاده از Grant | TICKET و BUILDING |
بحرانی | Grant فعال و محدود |
support_access.revoke |
پایاندادن Grant | PLATFORM |
بحرانی | Platform Admin یا پایان خودکار |
۷. Default Role Matrix
علائم
| علامت | معنا |
|---|---|
D |
دسترسی پیشفرض |
C |
قابل اعطا در تنظیمات ساختمان |
V |
فقط مشاهده |
P |
وابسته به Policy |
T |
موقت و Ticket-based |
— |
بدون دسترسی |
ماتریس نقشهای اصلی
| Capability | Building Admin | Building Manager | Board Chair | Board Member | Treasurer | Inspector | Accountant |
|---|---|---|---|---|---|---|---|
| Setup Dashboard | D |
V |
— | — | — | — | — |
| Basic Building Profile | D |
C |
— | — | — | — | — |
| Units and Residents | D |
D |
V |
V |
V |
V |
V |
| Person Private Data | D |
D |
— | — | C |
C |
C |
| Tenant Replacement | D |
D |
— | — | — | — | — |
| Ownership Transfer | D |
C |
V |
— | V |
V |
— |
| Governance Structure | D |
V |
V |
V |
V |
V |
— |
| Role Template | D |
V |
— | — | — | V |
— |
| Sensitive Permission | D |
— | — | — | — | V |
— |
| Operational Role Assignment | D |
D |
— | — | — | V |
— |
| Governance Role Assignment | D |
— | V |
V |
V |
V |
— |
| Invitation Management | D |
D |
C |
— | — | — | C |
| Staff Structure | D |
D |
V |
— | — | V |
— |
| Finance Setup | D |
P |
V |
V |
P |
V |
P |
| Settlement Destination | D |
— | V |
— | V |
V |
C |
| Manual Payment Review | D |
P |
V |
— | D |
V |
D |
| Manual Payment Approval | D |
P |
— | — | D |
V |
D |
| Facility Configuration | D |
C |
V |
— | — | — | — |
| Operational Audit | D |
D |
V |
V |
V |
D |
V |
| Access Audit | D |
V |
V |
— | — | D |
— |
| Request Building Admin Transfer | D |
D |
D |
C |
— | D |
— |
| Execute Building Admin Transfer | — | — | — | — | — | — | — |
نقشهای کارکنان و ساکنان
| Role یا رابطه | Setup | واحدها و اشخاص | Role و Permission | Invitation Admin | تنظیمات مالی | Facility Config |
|---|---|---|---|---|---|---|
FACILITY_MANAGER |
— | V |
— | — | — | C |
CONCIERGE |
— | محدود | — | — | — | — |
SECURITY_GUARD |
— | محدود | — | — | — | — |
JANITOR |
— | محدود | — | — | — | — |
TECHNICIAN |
— | فقط Assignment | — | — | — | — |
CONTRACTOR |
— | فقط Assignment | — | — | — | — |
| مالک | — | فقط رابطه و واحد خود | — | — | — | — |
| مستأجر | — | فقط رابطه و واحد خود | — | — | — | — |
| ساکن | — | فقط رابطه و واحد خود | — | — | — | — |
| عضو خانواده | — | محدود و وابسته به رابطه | — | — | — | — |
کارکنان برای انجام Taskهای روزانه از Permission Catalog ماژولهای عملیاتی استفاده میکنند، نه از Permissionهای Setup.
مالک، مستأجر یا پرداختکننده مجاز واحد میتواند بدون Role مدیریتی، قبض واریز بانکی همان واحد را با Action خودخدمتی manual_payment.submit ثبت کند. این Action اجازه مشاهده قبض سایر واحدها یا تأیید Payment را ایجاد نمیکند.
۸. Guardهای Actionهای حساس
۸.۱. انتقال مالکیت
relationship.ownership.transfer فقط زمانی اجرا میشود که:
- Unit و مالک جاری معتبر باشند؛
- Effective Transfer Date ثبت شده باشد؛
- بازه رابطه جدید با رابطه جاری تداخل نامعتبر نداشته باشد؛
- مدرک یا Reference انتقال ثبت شده باشد؛
- مانده Unit Ledger نمایش داده شده باشد؛
- Actor و وضعیت قبل و بعد Audit شوند.
Building Manager بهصورت پیشفرض این Permission را ندارد و فقط با تنظیم صریح Building Admin میتواند دریافت کند.
۸.۲. تغییر Permission حساس
- فقط
BUILDING_ADMINدارای Permission پیشفرض است. - Permissionها در سطح Role Template تغییر میکنند، نه شخص.
- تعداد Role Assignmentهای فعال متأثر پیش از تأیید نمایش داده میشود.
- دلیل و Diff قبل و بعد Audit میشوند.
- تغییر نباید Role پلتفرم یا
BUILDING_ADMINجدید ایجاد کند.
۸.۳. مقصد تسویه
- ثبت اطلاعات میتواند با دسترسی مجاز انجام شود.
- فعالسازی یا تغییر مقصد تسویه نیازمند تأیید نهایی
BUILDING_ADMINاست. - دسترسی مالی
BUILDING_MANAGERبه Financial Policy وابسته است. - جزئیات تأیید و مالکیت حساب در ماژول مالی نهایی میشود.
۸.۴. Invitation
- ارسالکننده باید
invitation.sendداشته باشد. - Role و Scope پیشنهادی باید توسط Actor قابل مدیریت باشند.
- داشتن Permission ارسال Invitation بهتنهایی اجازه ساخت Role Template یا Role حاکمیتی جدید نمیدهد.
- لغو Role حساس نیازمند دلیل است.
- Resend روی همان Envelope انجام میشود.
- Action دعوت در Context همان واحد، شخص، تیم مدیریت یا موقعیت شغلی نمایش داده میشود؛ صفحه مرکزی Invitation وجود ندارد.
۸.۴.۱. قبض واریز بانکی
- مالک، مستأجر یا پرداختکننده مجاز فقط برای واحدهای در Scope خود
manual_payment.submitدارد. - مشاهده تصویر قبض و اطلاعات پیگیری به Roleهای مالی مجاز محدود است.
manual_payment.approveباید Payment یکتا ایجاد و سپس مانده Unit Ledger را کاهش دهد.- تأیید یا رد هر قبض با Actor، زمان، مبلغ، Bill مقصد و دلیل احتمالی Audit میشود.
- Role بدون
manual_payment.approveمیتواند در صورت داشتنmanual_payment.reviewقبض را ببیند، اما نمیتواند مانده را تغییر دهد.
۸.۵. تخصیص Role به خود
BUILDING_ADMIN میتواند یک Role مدیریتی مجاز را به خودش تخصیص دهد، به شرط:
- Membership فعال؛
- Role Template معتبر؛
- تأیید صریح؛
- Audit کامل؛
- عدم ایجاد Role پلتفرم یا Building Admin تکراری.
۹. Role Templateهای پیشفرض
اصول
- برای هر Role یک بسته پیشفرض تریپیلون وجود دارد.
- بسته پیشفرض در مسیر اصلی با خلاصه قابل فهم نمایش داده میشود.
- گزینه شخصیسازی ثانویه و کمتأکید است.
- تغییر Template بر همه افراد دارای همان Role در ساختمان اثر دارد.
- Per-person Override در نسخه اولیه وجود ندارد.
- بازگشت به بسته پیشفرض تریپیلون مجاز و Auditشده است.
سطح بستههای پیشنهادی
| نوع Role | رویکرد پیشفرض |
|---|---|
| Building Admin | پیکربندی ساختمان بدون دسترسی خودکار نامحدود مالی |
| Building Manager | عملیات روزانه بدون مدیریت Permission حساس |
| Governance | مشاهده و تصمیم حاکمیتی، بدون Setup Admin |
| Finance | Permissionهای مالی محدود به Policy |
| Operations | Task-based و Scope محدود |
| External | فقط Assignment یا Resource مرتبط |
۱۰. Self-service Actionهای شخص دعوتشده
Actionهای زیر Permission مدیریتی نیستند و فقط برای Subject همان Invitation مجازند:
- مشاهده Invitation معتبر خود پس از OTP؛
- مشاهده Role و Scope پیشنهادی خود؛
- پذیرش یا رد مستقل هر Role حساس؛
- گزارش «این ساختمان یا واحد متعلق به من نیست»؛
- مشاهده لغوشدن Invitation خود.
Guardها:
- تطبیق شماره موبایل تأییدشده با Contact Point دعوت؛
- Envelope فعال؛
- Role همچنان Pending و Scope معتبر؛
- جلوگیری از تصمیم برای Invitation شخص دیگر.
۱۱. دسترسی موقت پشتیبانی
اصل تجربه
مسیر اصلی محصول Self-service است. گزینه «انجام Setup توسط پشتیبانی» نباید در Setup Dashboard یا مسیر اصلی برجسته باشد.
مسیر پشتیبانی فقط:
- پس از درخواست کاربر؛
- از طریق Ticket یا کانال پشتیبانی ثبتشده؛
- برای حل پیچیدگی یا مشکل جدی؛
- با Scope و زمان محدود؛
- و با Audit کامل فعال میشود.
Support Access Grant
| فیلد | الزام |
|---|---|
| Requester | Building Admin یا درخواستکننده مجاز |
| Ticket | الزامی |
| Building Scope | یک ساختمان مشخص |
| Allowed Permissions | فهرست صریح و حداقلی |
| Reason | الزامی |
| Starts At | الزامی |
| Expires At | الزامی |
| Granted By | Platform Admin |
| Used By | Support Admin مشخص |
| Revocation | دستی یا خودکار |
Actionهای قابل انجام
- ثبت واحدها و اشخاص؛
- آمادهسازی ساختار مدیریت و کارکنان؛
- تنظیم Role Template، فقط در صورت مجوز صریح Ticket؛
- تعریف Facility و تنظیمات پایه؛
- اصلاح وضعیت ناسازگار Setup پس از بررسی.
Actionهای نیازمند مجوز صریح یا تأیید نهایی
- ارسال Invitation یا SMS؛
- افزودن Permission حساس؛
- انتقال مالکیت؛
- ثبت یا فعالسازی مقصد تسویه؛
- تغییر Building Admin.
Actionهای خارج از Support Setup
- Publish شارژ؛
- انجام پرداخت بهجای مشتری؛
- پذیرش Role بهجای شخص دعوتشده؛
- تأیید حقوقی یا Self-declaration بهجای مشتری؛
- Impersonation حساب Building Admin.
stateDiagram-v2
accTitle: چرخه دسترسی موقت پشتیبانی
accDescr: دسترسی پشتیبانی پس از Ticket و تأیید ایجاد میشود و با پایان زمان، لغو یا تکمیل کار خاتمه مییابد
state "درخواستشده" as REQUESTED
state "فعال" as ACTIVE
state "لغوشده" as REVOKED
state "منقضیشده" as EXPIRED
state "تکمیلشده" as COMPLETED
state "ردشده" as REJECTED
[*] --> REQUESTED
REQUESTED --> ACTIVE: تأیید Platform Admin و تعیین Scope
REQUESTED --> REJECTED: رد درخواست
ACTIVE --> COMPLETED: پایان موفق کار
ACTIVE --> REVOKED: لغو دستی
ACTIVE --> EXPIRED: رسیدن زمان پایان
REJECTED --> [*]
COMPLETED --> [*]
REVOKED --> [*]
EXPIRED --> [*]
Break-glass
در Incident امنیتی فوری، Platform Admin میتواند دسترسی اضطراری ایجاد کند. این اقدام:
- به Reason اجباری نیاز دارد؛
- کوتاهمدت و حداقلی است؛
- اعلان و Audit تقویتشده دارد؛
- پس از اقدام بازبینی میشود؛
- جایگزین Workflow عادی Support Ticket نیست.
۱۲. انتقال Building Admin
building_admin_transfer.requestمیتواند توسط Roleهای مجاز استفاده شود.building_admin_transfer.executeفقط در اختیار پشتیبانی مجاز و در Scope Ticket است.BUILDING_ADMINاز طریق Role Template معمولی قابل ساخت، حذف یا انتقال نیست.- پیش از پذیرش شخص جدید، Building Admin فعلی حفظ میشود.
- سلب Role قبلی و فعالسازی Role جدید اتمیکاند.
- Support Access Grant بهتنهایی اجازه اجرای انتقال را نمیدهد؛ Permission مخصوص و Ticket تأییدشده لازم است.
۱۳. Audit Matrix
| Action | Audit | دلیل یا مدرک | نمایش افراد متأثر |
|---|---|---|---|
| تغییر Role Template | الزامی | Diff | الزامی |
| تغییر Permission حساس | تقویتشده | دلیل | الزامی |
| تخصیص Role به خود | الزامی | تأیید صریح | یک شخص |
| ارسال گروهی Invitation | الزامی | Batch و هزینه | تعداد گیرندگان |
| لغو Invitation حساس | الزامی | دلیل لغو | Roleهای Pending |
| انتقال مالکیت | تقویتشده | مدرک یا Reference | مالک قبلی و جدید |
| پایان Household | الزامی | Effective Date | همه اعضای وابسته |
| Support Access Grant | تقویتشده | Ticket و Scope | Permissionهای Grant |
| تغییر Building Admin | تقویتشده | Ticket و مدارک | مدیر قبلی و جدید |
۱۴. Transitionهای دسترسی ممنوع
- Role Pending به Permission فعال پیش از پذیرش؛
- Permission مستقیم برای Person یا Account؛
- Per-person Override در نسخه اولیه؛
- استفاده Role یک ساختمان در ساختمان دیگر؛
- ساخت
BUILDING_ADMINجدید از مسیر Role Assignment عمومی؛ - اجرای انتقال مالکیت با Permission مدیریت مستأجر؛
- استفاده Support Grant پس از Expiry یا Revoke؛
- Impersonation کاربر برای انجام Setup؛
- استفاده از Permission مالی بدون Financial Policy معتبر؛
- حذف Person یا Account برای قطع دسترسی؛
- حذف Roleها و Scopeهای نامرتبط هنگام جایگزینی.
۱۵. تصمیمهای باز
| شناسه | موضوع | وضعیت |
|---|---|---|
OPEN-ACC-01 |
حداکثر مدت Support Access Grant | باید با سیاست امنیت پلتفرم تعیین شود |
OPEN-ACC-02 |
Roleهای مجاز برای درخواست تغییر Building Admin | در این سند پیشنهاد شده و نیازمند تأیید حقوقی Workflow است |
OPEN-ACC-03 |
اعطای facility.configure به Building Manager |
قابل تنظیم در هر ساختمان در نظر گرفته شده است |
OPEN-ACC-04 |
اعطای انتقال مالکیت به Building Manager | پیشفرض رد و فقط با اعطای صریح Building Admin |
OPEN-ACC-05 |
جزئیات تأیید مقصد تسویه | به طراحی ماژول مالی وابسته است |
۱۶. معیارهای پذیرش
- Building Admin و مدیر راهاندازی یک Role canonical هستند.
- Building Manager از Building Admin جداست.
- Permissionها به Role Template متصلاند، نه شخص.
- Per-person Override در نسخه اولیه وجود ندارد.
- Scope و Guard هر Permission حساس مشخصاند.
- Tenant Replacement از Ownership Transfer جدا شده است.
- Building Manager بهصورت پیشفرض Ownership Transfer ندارد.
- Role Pending هیچ Permission فعالی ندارد.
- Invitation Admin از تصمیم شخص درباره Invitation خودش جدا شده است.
- Support Access مسیر فرعی، موقت، Ticket-based و Auditشده است.
- Support Admin به Building Admin ساختمان تبدیل نمیشود.
- انتقال Building Admin فقط از Workflow پشتیبانی انجام میشود.
- Actionهای مالی تفصیلی به ماژول مالی واگذار شدهاند.
- مدت استاندارد Support Access Grant تعیین شود.
- Policy مالی و مقصد تسویه در ماژول مالی نهایی شود.
- ماتریس با Role × Module Matrix سراسری همگام شود.