پرش به محتویات

آدم‌ها، عضویت‌ها، نقش‌ها و دسترسی‌ها

اصل مدل

Important

رکورد شخص در ساختمان، رابطه او با واحد، حساب کاربری و دسترسی اپ چهار مفهوم مستقل هستند. شخص می‌تواند پیش از ورود به اپ، عضو عملیاتی ساختمان باشد و Charge، Bill یا پیامک دریافت کند.

موجودیت‌های اصلی

موجودیت مسئولیت
Person Record هویت و اطلاعات پایه شخص ثبت‌شده در ساختمان
Contact Point شماره موبایل یا مسیر ارتباطی ثبت‌شده برای شخص
Account حساب سراسری از قبل ثبت‌شده یا Provisionشده برای شماره موبایل شناخته‌شده
Account Link اتصال Account تأییدشده به Person Record و Membership موجود
Building Membership حضور عملیاتی شخص در یک ساختمان، مستقل از ورود به اپ
Unit Relationship رابطه شخص با واحد به‌عنوان مالک، مستأجر، ساکن یا عضو خانواده
Invitation Envelope دعوت یک شخص به یک ساختمان همراه با یک یا چند Role پیشنهادی
Role Assignment انتساب Role به Membership در Scope مشخص
Role Template بسته Permissionهای یک نوع کار در یک ساختمان
Permission اجازه انجام Action مشخص
Scope محدوده ساختمان، واحد، Facility، شیفت یا Assignment

تفکیک Membership از Account

  • Building Membership می‌تواند پیش از ایجاد یا اتصال Account وجود داشته باشد.
  • نبود Account مانع ثبت رابطه شخص با واحد نیست.
  • Charge و Bill می‌توانند بر اساس Membership و Unit Relationship ایجاد شوند.
  • اعلان پیامکی می‌تواند از Contact Point ثبت‌شده استفاده کند.
  • ورود عادی Account جدید ایجاد نمی‌کند.
  • شماره موبایل برای اجرای جریان عضویت باید از قبل با Account، Person Record یا Invitation شناخته شده باشد.
  • دسترسی داخل اپ فقط پس از OTP و فعال‌شدن Account Link ممکن است.
  • Account Link نباید Person Record یا Membership تکراری ایجاد کند.
  • اگر موبایل در هیچ رکوردی شناخته نشده باشد، کاربر به مسیریابی ثبت ساختمان جدید در SET-01 هدایت می‌شود.

رابطه‌های عملیاتی

رابطه‌های زیر برای ثبت عملیاتی ساختمان به پذیرش Invitation وابسته نیستند:

  • مالک
  • مستأجر
  • ساکن
  • عضو خانواده

ثبت این روابط:

  • شخص را در فهرست ساختمان قرار می‌دهد؛
  • امکان تخصیص Charge و ارسال اعلان پیامکی را فراهم می‌کند؛
  • به‌تنهایی Permission داخل اپ ایجاد نمی‌کند.

Roleهای دسترسی‌دار

Roleهای مدیریتی، مالی و عملیاتی تا پذیرش صریح فعال نمی‌شوند؛ از جمله:

  • مدیر ساختمان
  • رئیس و عضو هیئت‌مدیره
  • خزانه‌دار
  • بازرس
  • حسابدار
  • نگهبان، لابی‌من و سایر کارکنان

Role Assignment این Roleها پیش از پذیرش در وضعیت PENDING_ACCEPTANCE باقی می‌ماند و Permission اعمال نمی‌کند.

Invitation Envelope

Invitation Envelope:

  • به یک شخص و یک ساختمان متصل است؛
  • می‌تواند چند Role و Scope پیشنهادی داشته باشد؛
  • برای جلوگیری از SMS تکراری با یک پیام اطلاع‌رسانی ارسال می‌شود؛
  • وضعیت Delivery را جدا از وضعیت پذیرش نگه می‌دارد؛
  • تاریخ انقضای کسب‌وکاری ندارد؛
  • توسط مدیر قابل لغو است.

لینک پیامک Token دائمی دسترسی نیست. مشاهده و استفاده از Invitation در هر زمان به OTP و بررسی وضعیت جاری Envelope وابسته است.

پذیرش و رد

  • رابطه عادی شخص با واحد به پذیرش یا رد وابسته نیست.
  • پذیرش Invitation باعث Account Link و فعال‌شدن Roleهای نیازمند پذیرش می‌شود.
  • در Envelope چندRole، هر Role حساس به‌صورت مستقل پذیرفته یا رد می‌شود.
  • رد Role حساس، Building Membership یا Unit Relationship شخص را حذف نمی‌کند.
  • شخصی که Invitation را نادیده می‌گیرد همچنان می‌تواند Charge، Bill و SMS دریافت کند.

اگر شخص تعلق خود به ساختمان یا واحد را رد کند، Account Link آن رابطه فعال نمی‌شود، Contact Point در وضعیت DISPUTED قرار می‌گیرد و ارسال محتوای حساس به شماره مورد اختلاف تا بررسی مدیر متوقف می‌شود. سابقه مالی واحد حذف نمی‌شود.

تخصیص چند Role

  • یک Membership می‌تواند چند Role Assignment داشته باشد.
  • یک Invitation Envelope می‌تواند چند Role پیشنهادی را حمل کند.
  • Roleهای داخل Envelope می‌توانند Scopeهای متفاوت داشته باشند.
  • Permission هر Role فقط در Scope همان Role Assignment اعمال می‌شود.

ورود و Current Context

پس از ورود با OTP:

  1. سامانه Account یا شناسه دیجیتال از قبل موجود را پیدا می‌کند.
  2. اگر موبایل ناشناخته باشد، Account جدید ایجاد نمی‌کند و کاربر را به SET-01 هدایت می‌کند.
  3. Account موجود را به Person Record و Membershipهای منطبق متصل می‌کند.
  4. Role Assignmentهای فعال و Pending را بررسی می‌کند.
  5. Current Context معتبر را انتخاب می‌کند.
  6. Roleهای نیازمند پذیرش را برای تصمیم مستقل کاربر نمایش می‌دهد.

تغییر ساختمان یا Role، Current Context را عوض می‌کند و Account جدیدی نمی‌سازد.

نقشه مفهومی

flowchart LR PERSON["رکورد شخص"] --> CONTACT["راه ارتباطی"] PERSON --> MEMBERSHIP["عضویت عملیاتی ساختمان"] PERSON --> UNIT_REL["رابطه با واحد"] UNIT_REL --> UNIT["واحد"] MEMBERSHIP --> BUILDING["ساختمان"] ACCOUNT["حساب کاربری"] --> ACCOUNT_LINK["اتصال حساب"] ACCOUNT_LINK --> PERSON ACCOUNT_LINK --> MEMBERSHIP INVITE["بسته دعوت"] --> PERSON INVITE --> BUILDING INVITE --> PROPOSED_ROLE["نقش‌های پیشنهادی"] MEMBERSHIP --> ROLE_ASSIGNMENT["انتساب نقش"] PROPOSED_ROLE --> ROLE_ASSIGNMENT ROLE_ASSIGNMENT --> ROLE_TEMPLATE["قالب نقش"] ROLE_TEMPLATE --> PERMISSION["دسترسی"] ROLE_ASSIGNMENT --> SCOPE["محدوده"]

وضعیت‌های مفهومی

Invitation Envelope

  • DRAFT
  • READY_TO_SEND
  • SENT
  • PENDING_ACCEPTANCE
  • ACCEPTED
  • REJECTED
  • CANCELED

Role Assignment

  • PENDING_ACCEPTANCE
  • ACTIVE
  • INACTIVE
  • UNLINKED
  • LINKED
  • DISPUTED

Account

  • PENDING_VERIFICATION
  • ACTIVE
  • DISABLED

وضعیت PENDING_VERIFICATION می‌تواند هنگام ثبت یک شماره موبایل شناخته‌شده Provision شود، اما تا OTP دسترسی ایجاد نمی‌کند. ورود، برای موبایل کاملاً ناشناخته Account جدید نمی‌سازد.

قواعد ارسال گروهی

  • ارسال گروهی از فهرست ساکنان، هیئت‌مدیره و کارکنان مجاز است.
  • ارسال موفق هر گیرنده مستقل از سایر گیرندگان ثبت می‌شود.
  • شکست بخشی از Batch باعث Rollback ارسال‌های موفق نمی‌شود.
  • Retry فقط برای موارد ناموفق انجام می‌شود.
  • Resend از Envelope موجود استفاده می‌کند و Envelope تکراری نمی‌سازد.

قواعد Resend و Cancel

  • Resend فقط Delivery Attempt جدید روی Envelope موجود ایجاد می‌کند.
  • حداقل فاصله Resend برای یک شخص و Envelope، ۲۴ ساعت است.
  • Resend خودکار در نسخه فعلی وجود ندارد.
  • Resend به بررسی هزینه و موجودی پنل پیامکی وابسته است.
  • Role و Scope در وضعیت Pending می‌توانند پیش از Resend ویرایش و نسخه‌بندی شوند.
  • Cancel فقط Roleهای Pending همان Envelope را غیرقابل پذیرش می‌کند.
  • Cancel، Membership، Unit Relationship، Charge، Bill یا سابقه شخص را حذف نمی‌کند.
  • Role فعال از مسیر Cancel Invitation غیرفعال نمی‌شود.
  • دلیل Cancel برای Roleهای مدیریتی، مالی و کارکنان الزامی است.
  • Resend، Edit و Cancel باید در Audit Trail ثبت شوند.

پایان و جایگزینی رابطه

  • Person و Account در زمان خروج از ساختمان حذف نمی‌شوند.
  • Unit Relationship یا Role Assignment با Effective End Date پایان می‌یابد.
  • رابطه یا Role شخص جدید به‌صورت رکورد مستقل ایجاد می‌شود.
  • تاریخچه شخص قبلی نباید با اطلاعات شخص جدید بازنویسی شود.
  • پایان یک Scope نباید Roleها یا Membershipهای نامرتبط فرد را غیرفعال کند.
  • Current Context پس از پایان آخرین Scope معتبر اصلاح می‌شود.

Tenant Household

  • مستأجر و اعضای خانواده وابسته او یک Tenant Household را تشکیل می‌دهند.
  • با پایان رابطه مستأجر، تمام روابط وابسته Household در همان Effective Date آرشیو می‌شوند.
  • اگر عضو خانواده رابطه مستقل دیگری داشته باشد، فقط رابطه وابسته به Household پایان می‌یابد.
  • آرشیو Household، Account سراسری افراد را غیرفعال نمی‌کند.

جایگزینی کارکن و سرویس‌کار

  • Role Assignment فرد قبلی با End Date غیرفعال می‌شود.
  • Role Assignment فرد جدید مستقل از رکورد قبلی ایجاد می‌شود.
  • Task، Shift، Facility Approval و Assignmentهای باز باید پیش از نهایی‌شدن جایگزینی Reassign یا Close شوند.
  • جایگزینی نباید Scope یا Roleهای دیگر فرد قبلی را تغییر دهد.

نمونه

مهدی رضایی می‌تواند پیش از نصب اپ، به‌عنوان مالک و ساکن واحد ۸ ثبت شده و Charge پیامکی دریافت کند. پس از ورود با OTP، Account او به همان Person Record متصل می‌شود. اگر هم‌زمان برای Role مدیر ساختمان دعوت شده باشد، این Role فقط بعد از پذیرش فعال می‌شود.

بازگشت