Files
docs/archive/99-ARCHIVE/REMAINING-TASKS-OLD-2024-12-02.md
T
masoodafar-web 5965b98728 update
2026-01-03 18:27:49 +03:30

48 KiB
Raw Blame History

کارهای باقی‌مانده - پروژه FourSat

⚠️ توجه: این فایل منسوخ شده است

📄 فایل جدید (تجمیع کامل):
👉 REMAINING-TASKS-CONSOLIDATED.md 👈

فایل جدید شامل:

  • تجمیع کامل تسک‌های CMS
  • تجمیع کامل تسک‌های BackOffice.BFF
  • تجمیع کامل تسک‌های BackOffice UI
  • تجمیع کامل تسک‌های FrontOffice.BFF
  • تجمیع کامل تسک‌های FrontOffice UI
  • اولویت‌بندی دقیق
  • تخمین زمان واقعی
  • جزئیات کامل هر تسک

تاریخ به‌روزرسانی: 1403/09/11 (2024-12-02)


📊 خلاصه سریع (برای مراجعه سریع)

🔴 اولویت فوری:

  1. Payment Gateway Integration (70% → 100%) - 1 هفته
  2. CRUD های اضافی (Tag, Product Bulk, Order) - 3 روز
  3. Manual Payment System - 2 روز

🟡 اولویت متوسط:

  1. VAT System - 2 روز
  2. Public Messages - 1 روز

🟢 اولویت پایین:

  1. RBAC (Role-Based Access) - 1.5 هفته
  2. Club Shop - 2 هفته (موکول شده)

📋 BackOffice UI (منتظر CMS):

  • صفحه مدیریت تراکنش‌ها - 2 روز
  • نمایش VAT - 1 روز
  • Menu Filtering (RBAC) - 1 روز
  • Public Messages UI - 1 روز
  • Manual Payment UI - 1 روز
  • Withdrawal Reports - 2 روز

📱 FrontOffice (آخرین اولویت):

  • FrontOffice.BFF APIs - 2 هفته
  • FrontOffice UI Pages - 3 هفته

زمان کل: 9 هفته (45 روز کاری)


برای جزئیات کامل، لطفاً به REMAINING-TASKS-CONSOLIDATED.md مراجعه کنید.


🎯 اولویت‌بندی توسعه

مسیر پیشنهادی:

1️⃣ CMS (Microservice/Backend)
   → تکمیل کامل تمام APIها و Business Logic
   → ✅ داکیومنت کامل هر تغییر
   
2️⃣ BackOffice.BFF (Gateway مدیریت)
   → تطبیق با تغییرات CMS
   → اضافه کردن Handlerهای جدید
   → ✅ داکیومنت یکپارچه‌سازی
   
3️⃣ BackOffice (Admin UI)
   → تطبیق با BFF
   → پیاده‌سازی صفحات جدید
   → ✅ داکیومنت UI Components
   
4️⃣ FrontOffice.BFF (Gateway مشتری)
   → پیاده‌سازی APIهای مشتری
   
5️⃣ FrontOffice (Customer UI)
   → رابط کاربری نهایی

⚠️ قانون طلایی: داکیومنت همزمان

  • بعد از هر تسک: داکیومنت آپدیت شود
  • قبل از commit: مقایسه داکیومنت با کد
  • هر feature: داکیومنت Business Logic
  • هر API: داکیومنت Request/Response
  • هر تغییر: داکیومنت در implementation-progress.md

📊 خلاصه وضعیت

تکمیل شده (7 فاز)

  • Domain Layer
  • Club Membership
  • Binary Network Tree
  • Commission & Worker (MVP)
  • Protobuf gRPC Services
  • History & Configuration
  • Database Migration & Seed Data

🟡 نیمه‌کامل (1 فاز)

  • Withdrawal & Settlement (40%)

شروع نشده (4 فاز/ویژگی)

  • Club Shop & Product Integration
  • Testing (موکول شده)
  • 🆕 سیستم مالیات بر ارزش افزوده (VAT)
  • 🆕 مدیریت نقش‌ها و دسترسی‌ها (RBAC)

🆕 ویژگی‌های جدید اضافه شده

🧾 سیستم مالیات بر ارزش افزوده (VAT System)

اولویت: 🟡 متوسط | زمان: 2 روز

توضیح: یک فیلد ساده VatPercentage که در سفارشات ذخیره و در سمت مشتری (FrontOffice) نمایش داده می‌شود.

شامل:

  • فیلد VatPercentage در Entity سفارش
  • مقدار پیش‌فرض در Configuration (مثلاً 10%)
  • نمایش در UI مشتری: "شامل 10% مالیات بر ارزش افزوده"

🔐 مدیریت نقش‌ها و دسترسی‌ها (RBAC)

اولویت: 🟡 متوسط | زمان: 1.5 هفته

توضیح: سیستم کنترل دسترسی مبتنی بر نقش (Role-Based Access Control) با 3 نقش اصلی:

  1. SuperAdmin (سوپر ادمین):

    • دسترسی کامل به تمام بخش‌ها
    • مدیریت کاربران و نقش‌ها
    • تنظیمات سیستم
  2. Admin (ادمین):

    • دسترسی به اکثر بخش‌ها
    • مدیریت محتوا و سفارشات
    • بدون دسترسی به تنظیمات حساس
  3. Inspector (بازرس):

    • فقط مشاهده (Read-Only)
    • بدون هیچ عملیات ویرایش/حذف/ایجاد
    • دسترسی محدود به:
      • Dashboard
      • گزارش‌ها
      • مشاهده سفارشات
      • مشاهده درخت شبکه
      • تنظیمات
      • مدیریت کاربران
      • عملیات مالی

پیاده‌سازی:

  • استخراج نقش از JWT Token در Frontend
  • محدودسازی منوها بر اساس نقش
  • غیرفعال کردن دکمه‌ها و فیلدها برای Inspector
  • Authorization در Backend APIs
  • صفحه مدیریت نقش‌ها (فقط SuperAdmin)

🏗️ تسک‌های هر سرویس (به ترتیب اولویت)

1️⃣ CMS (Microservice) - اولویت اول

مرجع کامل: totalDoc/CMS-API-COVERAGE.md (مقایسه دقیق CMS vs BFF)

🔴 فاز 1: Transaction System - 3 روز

وضعیت: 0% - ضروری برای Launch

توضیح: سیستم تراکنش‌های مالی برای دریافت نتیجه پرداخت از Gateway و ادامه عملیات در CMS

⚠️ نکته مهم - جریان پرداخت:

1. User کلیک "خرید پکیج" در CMS
2. CMS: CreateTransaction (Status: Pending, RefId)
3. Redirect به Gateway/PYMS با RefId
4. Gateway: اتصال به بانک → پرداخت
5. Gateway: Callback به CMS با RefId + نتیجه
6. CMS: VerifyTransaction → تایید + فعال‌سازی

خلاصه: درگاه اینترنتی در Gateway/PYMS است. CMS فقط نتیجه را دریافت و عملیات بعدی (فعال‌سازی، اضافه PV، Wallet) را انجام می‌دهد.

تسک‌ها در CMS:

  • Proto: transactions.proto موجود است
  • Entity: Transaction (با فیلدهای ReferenceId, Amount, Status, Gateway)
  • Commands:
    • CreateTransactionCommand
    • VerifyTransactionCommand (callback از درگاه)
    • RefundTransactionCommand
  • Queries:
    • GetTransactionQuery
    • GetAllTransactionsByFilterQuery
    • GetTransactionByReferenceQuery
    • GetUserTransactionsQuery
  • داکیومنت: CMS/payment-gateway-integration.md

تأثیر روی سایر سرویس‌ها:

  • BackOffice.BFF: 7 Handler جدید
    • TransactionHandler (CRUD)
    • VerifyPaymentHandler
    • RefundHandler
    • GetUserTransactionsHandler
  • BackOffice: صفحات جدید
    • لیست تراکنش‌ها (با فیلتر)
    • جزئیات تراکنش
    • عملیات Refund

سطوح دسترسی:

  • SuperAdmin: همه عملیات + Refund
  • Admin: مشاهده تراکنش‌ها (بدون Refund)
  • Inspector: فقط مشاهده

🟡 فاز 2: Shopping Cart System - 2 روز

وضعیت: 0%

توضیح: سیستم سبد خرید برای مدیریت سبدهای کاربران

تسک‌ها در CMS:

  • Proto: usercarts.proto موجود است
  • Commands:
    • AddToCartCommand
    • UpdateCartItemCommand
    • RemoveFromCartCommand
    • ClearCartCommand
    • MergeCartCommand (مهمان → لاگین)
  • Queries:
    • GetUserCartQuery
    • GetAllCartsQuery (برای مدیریت)
  • داکیومنت: CMS/shopping-cart-system.md

تأثیر روی سایر سرویس‌ها:

  • BackOffice.BFF: 6 Handler جدید
  • BackOffice: صفحه مدیریت سبدهای خرید (مشاهده سبدهای فعال)

سطوح دسترسی:

  • SuperAdmin: مشاهده + پاک کردن سبدهای متروکه
  • Admin: مشاهده سبدها
  • Inspector: فقط مشاهده

🟡 فاز 3: Products & Orders تکمیل - 2 روز

وضعیت: 70% (ناقص)

توضیح: تکمیل APIهای محصولات و سفارشات

تسک‌ها در CMS:

Products (Tags):

  • Proto: tag.proto, producttag.proto موجود است
  • Commands:
    • CreateTagCommand
    • UpdateTagCommand
    • DeleteTagCommand
    • AssignTagToProductCommand
  • Queries:
    • GetAllTagsQuery
    • GetProductsByTagQuery

Products (Bulk):

  • BulkUpdateProductsCommand (به‌روزرسانی دسته‌ای قیمت/موجودی)
  • GetLowStockProductsQuery (هشدار کم موجودی)
  • ToggleProductStatusCommand (فعال/غیرفعال)

Orders:

  • CancelOrderCommand
  • UpdateOrderStatusCommand
  • GetOrdersByDateRangeQuery
  • ApplyDiscountToOrderCommand
  • CalculateOrderPVQuery

تأثیر روی سایر سرویس‌ها:

  • BackOffice.BFF: 12 Handler جدید
  • BackOffice: صفحات
    • مدیریت Tags
    • به‌روزرسانی دسته‌ای محصولات
    • لغو سفارش
    • اعمال تخفیف

سطوح دسترسی:

  • SuperAdmin: همه عملیات
  • Admin: همه عملیات محصولات/سفارشات
  • Inspector: فقط مشاهده

🟡 فاز 4: Public Messages System - 1 روز

وضعیت: 0%

توضیح: سیستم اعلانات عمومی برای اطلاع‌رسانی به کاربران

تسک‌ها در CMS:

  • Proto: public_messages.proto موجود است
  • Commands:
    • CreatePublicMessageCommand
    • UpdatePublicMessageCommand
    • DeletePublicMessageCommand
    • PublishMessageCommand
    • ArchiveMessageCommand
  • Queries:
    • GetAllPublicMessagesQuery
    • GetPublicMessageQuery
    • GetActiveMessagesQuery
  • داکیومنت: CMS/public-messages-system.md

تأثیر روی سایر سرویس‌ها:

  • BackOffice.BFF: 6 Handler جدید
  • BackOffice: صفحات
    • لیست اعلانات
    • ایجاد/ویرایش اعلان
    • انتشار اعلان

سطوح دسترسی:

  • SuperAdmin: همه عملیات
  • Admin: Create, Update, Publish
  • Inspector: فقط مشاهده

🟡 فاز 5: سیستم مالیات (VAT) - 2 روز

وضعیت: 0%

(بدون تغییر - قبلاً مستند شده)


🟡 فاز 6: سیستم RBAC (1.5 هفته)

وضعیت: 0%

(بدون تغییر - قبلاً مستند شده)


🟢 فاز 7: فروشگاه باشگاه (2 هفته)

وضعیت: 0%

(بدون تغییر - قبلاً مستند شده)


🟢 فاز 8: Contracts (اختیاری) - 2 روز

وضعیت: 0%

توضیح: مدیریت قراردادهای عضویت/خرید خاص

تسک‌ها در CMS:

  • Proto: contract.proto, usercontract.proto موجود است
  • Commands: Create, Update, Delete, Assign, Revoke
  • Queries: GetAll, Get, GetUserContracts
  • داکیومنت: CMS/contracts-system.md

اولویت: فقط در صورت نیاز بیزینسی


2️⃣ BackOffice.BFF (Gateway) - اولویت دوم

منتظر تکمیل CMS:

  • PaymentHandler (بعد از CMS فاز 1)
  • OrderVatHandler (بعد از CMS فاز 2)
  • AuthorizationHandler (بعد از CMS فاز 3)
  • داکیومنت: هر Handler در cms-integration.md

3️⃣ BackOffice (Admin UI) - اولویت سوم

منتظر تکمیل BFF:

  • صفحه مدیریت تراکنش‌ها
  • نمایش VAT در لیست سفارشات
  • Menu filtering بر اساس Role
  • داکیومنت: هر صفحه در development-plan.md

4️⃣ FrontOffice.BFF (Gateway مشتری) - اولویت چهارم

تسک‌های اصلی:

  • Authentication APIs
  • Order APIs
  • Profile APIs
  • داکیومنت: FrontOffice.BFF/README.md

5️⃣ FrontOffice (Customer UI) - اولویت پنجم

تسک‌های اصلی:

  • صفحه ثبت‌نام/ورود
  • پروفایل کاربری
  • سبد خرید (با نمایش VAT)
  • داکیومنت: FrontOffice/README.md

🔴 اولویت بالا (High Priority) - CMS

1. تکمیل درگاه پرداخت (Phase 10) - 1 هفته

وضعیت: 70% تکمیل

انجام شده:

  • Commands: RequestWithdrawal, ProcessWithdrawal, ApproveWithdrawal, RejectWithdrawal

  • Database: UserCommissionPayout, CommissionPayoutHistory

  • ProcessedBy tracking (مدیر تأییدکننده)

  • IPaymentGatewayService Interface - یکپارچه‌سازی با درگاه‌های پرداخت

  • MockPaymentGatewayService - Mock برای تست محیط Development

  • DayaPaymentService (Skeleton) - آماده برای API واقعی دایا

  • ProcessWithdrawalCommandHandler - یکپارچه با Payment Gateway

    • روش Diamond: شارژ کیف پول تخفیف
    • روش BankTransfer: فراخوانی ProcessPayoutAsync
    • Error Handling: وضعیت PaymentFailed
    • Logging: ثبت موفقیت/خطا
  • Entity Updates:

    • BankReferenceId, BankTrackingCode, PaymentFailureReason در UserCommissionPayout
    • PaymentFailed در CommissionPayoutStatus Enum

باقی‌مانده (30%):

  1. یکپارچه‌سازی با درگاه پرداخت واقعی (2-3 روز)

    • پیاده‌سازی DayaPaymentService با API واقعی

    • تست تراکنش‌های واقعی

    • مدیریت callback و webhook

  2. رابط کاربری مدیریت (BackOffice) (2 روز)

    • صفحه لیست درخواست‌های برداشت
    • دکمه‌های تأیید/رد
    • نمایش جزئیات تراکنش (BankReferenceId, TrackingCode)
    • نمایش وضعیت PaymentFailed و دلیل
    • فیلترینگ و جستجو
  3. گزارش‌های مالی (2 روز)

    • گزارش روزانه/هفتگی/ماهانه
    • خروجی Excel/PDF
    • نمودارهای مالی
    • آمار تجمیعی

تخمین زمان باقی‌مانده: 6-7 روز کاری


2. تنظیمات Production (30 دقیقه)

وضعیت: نیاز به تنظیم دستی

کارهای مورد نیاز:

الف. تنظیم Email (Gmail)

  1. ورود به Google Account Security
  2. فعال‌سازی 2-Step Verification
  3. ایجاد App Password
  4. کپی پسورد 16 رقمی
  5. آپدیت appsettings.Production.json:
"Email": {
  "SmtpUsername": "foursat@gmail.com",
  "SmtpPassword": "xxxx xxxx xxxx xxxx"
}

ب. تنظیم SMS (کاوه‌نگار)

  1. ثبت‌نام در Kavenegar.com
  2. کپی API Key از پنل
  3. دریافت شماره Sender
  4. آپدیت appsettings.Production.json:
"Sms": {
  "KavenegarApiKey": "YOUR_API_KEY",
  "Sender": "10008663"
}

ج. تنظیم Connection String

"ConnectionStrings": {
  "DefaultConnection": "Server=PRODUCTION_SERVER;Database=Foursat_CMS;..."
}

تخمین زمان: 30 دقیقه


🟡 اولویت متوسط (Medium Priority)

3. فروشگاه باشگاه (Phase 9) - 2 هفته

وضعیت: 0% (شروع نشده)

ویژگی‌های مورد نیاز:

  1. کاتالوگ محصولات (2 روز)

    • لیست پکیج‌های عضویت
    • قیمت‌گذاری (1 ماهه، 3 ماهه، 6 ماهه، سالانه)
    • تخفیف‌های خرید چندماهه
    • نمایش ویژگی‌ها
  2. سبد خرید (2 روز)

    • افزودن به سبد
    • ویرایش تعداد
    • محاسبه تخفیف
    • پیش‌نمایش قیمت نهایی
  3. فرآیند خرید (3 روز)

    • اتصال به درگاه پرداخت
    • تأیید پرداخت
    • فعال‌سازی خودکار عضویت
    • ارسال رسید به ایمیل/SMS
  4. یادآوری تمدید (2 روز)

    • کرون‌جاب بررسی انقضا
    • ارسال SMS/Email 30 روز قبل
    • ارسال یادآوری 7 روز قبل
    • ارسال پیام انقضا
  5. پنل مدیریت (3 روز)

    • مدیریت محصولات
    • تنظیم قیمت‌ها و تخفیف‌ها
    • گزارش فروش
    • آمار تمدیدها

تخمین زمان کل: 2 هفته کاری


🟢 اولویت پایین (Low Priority)

4. تست‌نویسی (Phase 7) - موکول شده

وضعیت: 0% (Postponed)

انواع تست مورد نیاز:

  1. Unit Tests (1 هفته)

    • تست logic محاسبات کمیسیون
    • تست Binary Tree placement
    • تست Commands/Queries
    • تست Validators
    • Coverage حداقل 70%
  2. Integration Tests (3 روز)

    • تست gRPC endpoints
    • تست Database transactions
    • تست Background Worker
    • تست Notification Service
  3. Load Testing (2 روز)

    • تست همزمانی Background Worker
    • تست تعداد کاربران زیاد در Binary Tree
    • تست حجم بالای درخواست‌های API
    • بررسی Memory Leaks

تخمین زمان کل: 2 هفته کاری
توصیه: بعد از launch اولیه انجام شود


⚙️ بهبودهای اختیاری (Optional Enhancements)

5. Redis Distributed Locks

زمان نیاز: زمانی که سیستم روی چند سرور deploy شود

مزایا:

  • جلوگیری از اجرای همزمان Background Worker روی چند سرور
  • قفل توزیع‌شده برای تراکنش‌های بحرانی

پیاده‌سازی:

dotnet add package StackExchange.Redis
dotnet add package DistributedLock.Redis

6. Sentry Error Tracking

زمان نیاز: 1 ساعت

مراحل:

  1. ثبت‌نام در Sentry.io
  2. دریافت DSN
  3. آپدیت appsettings.json:
"Monitoring": {
  "SentryEnabled": true,
  "SentryDsn": "https://xxx@sentry.io/yyy"
}

7. Slack Notifications

زمان نیاز: 30 دقیقه

مراحل:

  1. ایجاد Slack App
  2. ایجاد Incoming Webhook
  3. آپدیت appsettings.json:
"Monitoring": {
  "SlackEnabled": true,
  "SlackWebhookUrl": "https://hooks.slack.com/services/..."
}

کاربرد: دریافت alert در صورت خطا در Background Worker


8. Firebase Cloud Messaging (Push Notifications)

زمان نیاز: 2 روز

مراحل:

  1. ثبت پروژه در Firebase Console
  2. دریافت Server Key
  3. نصب FirebaseAdmin package
  4. پیاده‌سازی PushNotificationService
  5. افزودن FCM Token به User entity
  6. ارسال notification همزمان با Email/SMS

9. سیستم مالیات بر ارزش افزوده (VAT System) - ساده

زمان نیاز: 2 روز

وضعیت: 0% (شروع نشده)

توضیح: فقط یک فیلد VatPercentage که روی سفارش نمایش داده می‌شه. بدون گزارش‌گیری پیچیده.


الف. Backend (CMS) - 1 روز

مدت: 1 روز

  1. Migration: اضافه کردن فیلد VatPercentage
// در UserOrder (سفارش/فاکتور)
public decimal VatPercentage { get; set; }  // مثلاً 10 (یعنی 10%)

// در FactorDetail (جزئیات فاکتور) - اختیاری
public decimal VatPercentage { get; set; }  // اگه نیاز بود
  1. Seed Data یا Configuration
// یک مقدار پیش‌فرض در SystemConfiguration
Key: "shop_vat_percentage"
Value: "10"  // 10%
  1. CreateOrderCommand - محاسبه ساده
// در زمان ثبت سفارش:
var vatPercentage = await _configService.GetVatPercentage();
order.VatPercentage = vatPercentage;

// محاسبه TotalPrice با مالیات (اختیاری):
// order.TotalPrice = order.SubTotal * (1 + vatPercentage/100);
  1. Protobuf: اضافه کردن فیلد
message OrderResponse {
    int64 id = 1;
    double total_price = 2;
    double vat_percentage = 3;  // 👈 فیلد جدید
    // ... سایر فیلدها
}

ب. BFF (اختیاری - اگه نیاز باشه) - 2 ساعت

مدت: 2 ساعت

اگه BFF درخواست جزئیات سفارش می‌ده، فقط فیلد VatPercentage رو هم بگیره و بده به Frontend:

// در OrderDto
public decimal VatPercentage { get; set; }

خیلی ساده: فقط mapping فیلد از gRPC به DTO


ج. Frontend (FrontOffice) - 4 ساعت

مدت: 4 ساعت (نصف روز)

نمایش در صفحات:

  1. صفحه سبد خرید (Cart)
<MudText Typo="Typo.body2" Color="Color.Secondary">
    شامل @order.VatPercentage% مالیات بر ارزش افزوده
</MudText>
  1. صفحه جزئیات سفارش / فاکتور
<MudText>
    قیمت کل: @order.TotalPrice تومان
</MudText>
<MudText Typo="Typo.caption" Color="Color.Secondary">
    (شامل @order.VatPercentage% مالیات بر ارزش افزوده)
</MudText>
  1. رسید خرید (Receipt)
<div class="vat-info">
    <MudIcon Icon="@Icons.Material.Filled.Info" Size="Size.Small" />
    <span>مالیات بر ارزش افزوده: @order.VatPercentage%</span>
</div>

همین! خیلی ساده، فقط نمایش یه عدد درصد.


تخمین زمان کل: 2 روز کاری (1 روز Backend + 4 ساعت Frontend)


10. سیستم مدیریت نقش‌ها و دسترسی‌ها (Role-Based Access Control)

زمان نیاز: 1.5 هفته (CMS: 2 روز + BFF: 1 روز + Frontend: 3 روز + Testing: 1 روز)

وضعیت: 0% (شروع نشده)

الف. تعریف نقش‌ها (Roles)

مدت: 1 روز

نقش‌های اصلی:

  1. SuperAdmin (سوپر ادمین)

    • دسترسی کامل به تمام بخش‌ها
    • مدیریت کاربران و نقش‌ها
    • تنظیمات سیستم
  2. Admin (ادمین)

    • دسترسی به اکثر بخش‌ها
    • مدیریت محتوا و سفارشات
    • بدون دسترسی به تنظیمات حساس
  3. Inspector (بازرس)

    • فقط مشاهده (Read-Only)
    • دسترسی به گزارش‌ها و Dashboard
    • بدون هیچ عملیات ویرایش/حذف
    • محدودیت دسترسی به صفحات:
      • Settings (تنظیمات)
      • User Management (مدیریت کاربران)
      • Financial Operations (عملیات مالی)
      • Reports (گزارش‌ها)
      • Dashboard (داشبورد)
      • Orders (فقط مشاهده)
      • Network Tree (فقط مشاهده)

ب. پیاده‌سازی در Backend (CMS)

مدت: 2 روز

  1. Entity: Role (در صورت عدم وجود)
public class Role
{
    public long Id { get; set; }
    public string Name { get; set; }              // SuperAdmin, Admin, Inspector
    public string DisplayName { get; set; }       // "سوپر ادمین", "ادمین", "بازرس"
    public string Description { get; set; }
    public List<Permission> Permissions { get; set; }
}

public class Permission
{
    public long Id { get; set; }
    public string Resource { get; set; }          // Users, Orders, Reports, Settings
    public string Action { get; set; }            // View, Create, Edit, Delete
    public long RoleId { get; set; }
    public Role Role { get; set; }
}
  1. JWT Token Claims
// در GenerateJwtTokenService
var claims = new List<Claim>
{
    new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
    new Claim(ClaimTypes.Name, user.Mobile),
    new Claim(ClaimTypes.Role, role.Name),        // "SuperAdmin", "Admin", "Inspector"
    new Claim("Permissions", JsonSerializer.Serialize(permissions))
};
  1. Authorization Attributes
// Backend API Authorization
[Authorize(Roles = "SuperAdmin,Admin")]
public async Task<UpdateUserResponse> UpdateUser(UpdateUserRequest request)

[Authorize(Roles = "SuperAdmin")]
public async Task<Empty> DeleteUser(DeleteUserRequest request)

[Authorize(Roles = "SuperAdmin,Admin,Inspector")]
public async Task<GetUserResponse> GetUser(GetUserRequest request)

ج. لایه BFF (BackOffice.BFF)

مدت: 1 روز

  1. AuthorizationHandler
public class AuthorizationHandler : IAuthorizationHandler
{
    private readonly CmsAuthClient _cmsAuthClient;
    
    public async Task<bool> CheckPermission(string userId, string resource, string action)
    {
        // gRPC call to CMS
        var request = new CheckPermissionRequest
        {
            UserId = userId,
            Resource = resource,
            Action = action
        };
        
        var response = await _cmsAuthClient.CheckPermissionAsync(request);
        return response.HasPermission;
    }
    
    public async Task<UserRoleDto> GetUserRole(string userId)
    {
        var request = new GetUserRoleRequest { UserId = userId };
        var response = await _cmsAuthClient.GetUserRoleAsync(request);
        
        return new UserRoleDto
        {
            RoleName = response.RoleName,
            Permissions = response.Permissions.Select(p => new PermissionDto
            {
                Resource = p.Resource,
                Action = p.Action
            }).ToList()
        };
    }
}
  1. RoleManagementHandler
public class RoleManagementHandler : IRoleManagementHandler
{
    private readonly CmsUserClient _cmsUserClient;
    
    public async Task<List<RoleDto>> GetRoles()
    {
        var response = await _cmsUserClient.GetRolesAsync(new Empty());
        return response.Roles.Select(r => new RoleDto
        {
            Id = r.Id,
            Name = r.Name,
            DisplayName = r.DisplayName,
            Permissions = r.Permissions.Select(p => new PermissionDto
            {
                Resource = p.Resource,
                Action = p.Action
            }).ToList()
        }).ToList();
    }
    
    public async Task<bool> AssignRole(long userId, string roleName)
    {
        var request = new AssignRoleRequest
        {
            UserId = userId,
            RoleName = roleName
        };
        
        var response = await _cmsUserClient.AssignRoleAsync(request);
        return response.Success;
    }
}
  1. API Endpoints
// Controllers/AuthorizationController.cs
[ApiController]
[Route("api/authorization")]
public class AuthorizationController : ControllerBase
{
    private readonly IAuthorizationHandler _authHandler;
    
    [HttpGet("check-permission")]
    public async Task<IActionResult> CheckPermission(
        [FromQuery] string resource, 
        [FromQuery] string action)
    {
        var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        var hasPermission = await _authHandler.CheckPermission(userId, resource, action);
        return Ok(new { hasPermission });
    }
    
    [HttpGet("user-role")]
    public async Task<IActionResult> GetUserRole()
    {
        var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        var role = await _authHandler.GetUserRole(userId);
        return Ok(role);
    }
}

// Controllers/RoleManagementController.cs
[ApiController]
[Route("api/roles")]
[Authorize(Roles = "SuperAdmin")]
public class RoleManagementController : ControllerBase
{
    private readonly IRoleManagementHandler _roleHandler;
    
    [HttpGet]
    public async Task<IActionResult> GetRoles()
    {
        var roles = await _roleHandler.GetRoles();
        return Ok(roles);
    }
    
    [HttpPost("assign")]
    public async Task<IActionResult> AssignRole([FromBody] AssignRoleDto dto)
    {
        var success = await _roleHandler.AssignRole(dto.UserId, dto.RoleName);
        return Ok(new { success });
    }
}
  1. Authorization Middleware
public class PermissionMiddleware
{
    private readonly RequestDelegate _next;
    
    public async Task InvokeAsync(HttpContext context, IAuthorizationHandler authHandler)
    {
        // Extract resource and action from endpoint metadata
        var endpoint = context.GetEndpoint();
        var requiredPermission = endpoint?.Metadata
            .GetMetadata<RequirePermissionAttribute>();
        
        if (requiredPermission != null)
        {
            var userId = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
            var hasPermission = await authHandler.CheckPermission(
                userId, 
                requiredPermission.Resource, 
                requiredPermission.Action
            );
            
            if (!hasPermission)
            {
                context.Response.StatusCode = 403;
                return;
            }
        }
        
        await _next(context);
    }
}

د. پیاده‌سازی در Frontend (BackOffice)

مدت: 3 روز

  1. AuthService Enhancement
public class AuthService
{
    private ClaimsPrincipal _user;
    
    public string GetUserRole()
    {
        return _user?.FindFirst(ClaimTypes.Role)?.Value;
    }
    
    public bool HasPermission(string resource, string action)
    {
        var permissions = GetUserPermissions();
        return permissions.Any(p => 
            p.Resource == resource && 
            p.Action == action);
    }
    
    public bool IsInRole(params string[] roles)
    {
        var userRole = GetUserRole();
        return roles.Contains(userRole);
    }
}
  1. Component-Level Authorization
@* صفحه Users.razor *@
@if (AuthService.IsInRole("SuperAdmin", "Admin"))
{
    <MudButton Color="Color.Primary" OnClick="CreateUser">
        ایجاد کاربر جدید
    </MudButton>
}

@* برای Inspector فقط جدول نمایش داده شود *@
<MudDataGrid Items="@users" ReadOnly="@(!AuthService.HasPermission("Users", "Edit"))">
    @* ... *@
</MudDataGrid>
  1. Navigation Menu Filtering
// در MainLayout.razor.cs
private List<NavMenuItem> GetFilteredMenuItems()
{
    var role = AuthService.GetUserRole();
    
    var allMenuItems = new List<NavMenuItem>
    {
        new NavMenuItem { Title = "داشبورد", Icon = Icons.Dashboard, Url = "/" },
        new NavMenuItem { Title = "سفارشات", Icon = Icons.ShoppingCart, Url = "/orders" },
        new NavMenuItem { Title = "کاربران", Icon = Icons.People, Url = "/users", 
                         RequiredRoles = new[] { "SuperAdmin", "Admin" } },
        new NavMenuItem { Title = "تنظیمات", Icon = Icons.Settings, Url = "/settings", 
                         RequiredRoles = new[] { "SuperAdmin" } },
    };
    
    return allMenuItems
        .Where(item => item.RequiredRoles == null || 
                      item.RequiredRoles.Contains(role))
        .ToList();
}
  1. UI Element Disabling for Inspector
@* در هر صفحه *@
@code {
    private bool IsReadOnly => AuthService.GetUserRole() == "Inspector";
}

<MudTextField @bind-Value="model.Name" 
              Label="نام" 
              Disabled="@IsReadOnly" />

<MudButton Color="Color.Success" 
           OnClick="SaveChanges" 
           Disabled="@IsReadOnly">
    ذخیره
</MudButton>

<MudIconButton Icon="@Icons.Material.Filled.Delete" 
               OnClick="DeleteItem" 
               Disabled="@IsReadOnly" />

د. صفحه مدیریت نقش‌ها (Role Management)

مدت: 1 روز

فقط برای SuperAdmin

  1. لیست نقش‌ها

    • جدول نقش‌ها (Name, DisplayName, Description)
    • دکمه‌های ویرایش/حذف
  2. ویرایش نقش

    • CheckBox Tree برای انتخاب دسترسی‌ها:
      ☐ کاربران
        ☑ مشاهده
        ☑ ایجاد
        ☐ ویرایش
        ☐ حذف
      ☐ سفارشات
        ☑ مشاهده
        ☐ ویرایش
        ☐ لغو
      
  3. اختصاص نقش به کاربر

    • در صفحه User Edit
    • Dropdown انتخاب نقش
    • فقط SuperAdmin می‌تواند تغییر دهد

ه. تست سناریوها

مدت: 1 روز

  1. تست Inspector

    • می‌تواند وارد سیستم شود
    • Dashboard را می‌بیند
    • گزارش‌ها را می‌بیند
    • لیست سفارشات را می‌بیند
    • نمی‌تواند سفارش ایجاد/ویرایش/حذف کند
    • صفحه Settings را نمی‌بیند
    • نمی‌تواند کاربر ایجاد/حذف کند
  2. تست Admin

    • می‌تواند اکثر عملیات را انجام دهد
    • نمی‌تواند Settings سیستم را تغییر دهد
    • نمی‌تواند نقش‌ها را مدیریت کند
  3. تست SuperAdmin

    • دسترسی کامل به همه چیز

تخمین زمان کل: 1.5 هفته کاری (CMS: 2 روز + BFF: 1 روز + UI: 3 روز + Testing: 1 روز)


📊 جدول اولویت‌بندی (به‌روز شده)

کار اولویت زمان وضعیت وابستگی
درگاه پرداخت 🔴 بالا 1 هفته 40% -
تنظیمات Production 🔴 بالا 30 دقیقه 0% -
سیستم مالیات (VAT) 🟡 متوسط 2 روز (CMS: 1 روز + UI: 4 ساعت) 0% -
مدیریت نقش‌ها (RBAC) 🟡 متوسط 1.5 هفته (CMS: 2 روز + BFF: 1 روز + UI: 3 روز + Test: 1 روز) 0% -
فروشگاه باشگاه 🟡 متوسط 2 هفته 0% درگاه پرداخت
تست‌نویسی 🟢 پایین 2 هفته 0% -
Redis Locks اختیاری 1 روز 0% Multi-server
Sentry اختیاری 1 ساعت 0% -
Slack اختیاری 30 دقیقه 0% -
FCM Push اختیاری 2 روز 0% -

🎯 برنامه پیشنهادی (Roadmap)

هفته 1: تکمیل درگاه پرداخت

  • روز 1-3: API Integration (فقط Daya برای Payout)
  • روز 4-5: BackOffice UI (Approval interface)

هفته 2: تنظیمات Production & Launch

  • روز 1: تنظیم Email/SMS
  • روز 2: تست کامل سیستم
  • روز 3-5: Soft Launch + Monitoring

هفته 3-4: فروشگاه باشگاه (اگر نیاز باشد)

  • هفته 3: Product Catalog + Cart
  • هفته 4: Purchase Flow + Renewal Reminders

هفته 5-6: سیستم مالیات و دسترسی‌ها

  • هفته 5 (روز 1-2): VAT System (مالیات بر ارزش افزوده) خیلی ساده

    • روز 1: CMS (فیلد VatPercentage + Seed Data)
    • روز 2 (صبح): Frontend (نمایش در Cart + Invoice)
  • هفته 5-6 (بقیه): RBAC (Role-Based Access Control)

    • روز 2.5-3: CMS Layer (Roles + Permissions + JWT)
    • روز 4: BFF Layer (Authorization Handlers + Middleware)
    • روز 5-7: Frontend (Menu Filtering + UI Authorization + Role Management)
    • روز 8: Testing (3 role scenarios)

هفته 7+: بهبودها و تست

  • تست‌نویسی
  • بهینه‌سازی Performance
  • اضافه کردن بهبودهای اختیاری

Checklist قبل از Launch

Backend

  • Domain Layer
  • Binary Tree
  • Commission Calculation
  • Background Worker (Hangfire)
  • Email/SMS Notifications
  • Health Checks
  • Database Migrations
  • Payment Gateway Integration
  • Production Configuration (Email/SMS)

Frontend

  • User Registration with Email
  • User Profile (Edit Email)
  • Club Shop (if needed)
  • Withdrawal Request UI
  • BackOffice Approval Interface
  • VAT Display in Cart & Invoice
  • Role-Based UI Authorization (Inspector, Admin, SuperAdmin)

Business Logic

  • VAT Calculation System
  • Role-Based Access Control (RBAC)
  • Payment Gateway Integration
  • Club Shop Integration

DevOps

  • Production Server Setup
  • SSL Certificate
  • Backup Strategy
  • Monitoring (Sentry/Slack - optional)
  • CI/CD Pipeline (optional)

Documentation

  • Implementation Progress
  • Email/SMS Configuration Guide
  • README with Quick Start
  • داکیومنت هر Feature جدید
  • مقایسه داکیومنت با کد (هر هفته)
  • API Documentation (Swagger/gRPC)
  • User Manual (فارسی)
  • Admin Manual

📝 چک‌لیست داکیومنت (بعد از هر تسک)

الزامی قبل از Commit:

1. داکیومنت Business Logic

  • آیا Business Logic در CMS/network-club-commission-system-v1.1.md به‌روز شده؟
  • آیا فرمول‌ها و محاسبات صحیح هستند؟
  • آیا مثال‌های عملی اضافه شده؟

2. داکیومنت پیشرفت

  • آیا CMS/implementation-progress.md آپدیت شده؟
  • آیا درصد پیشرفت به‌روز شده؟
  • آیا فاز جدید اضافه شده؟

3. داکیومنت API

  • آیا Protobuf messages داکیومنت شده‌اند؟
  • آیا Request/Response نمونه اضافه شده؟
  • آیا Error Codes مستند شده‌اند؟

4. مقایسه کد با داکیومنت

  • آیا کد با Business Logic تطبیق دارد؟
  • آیا Entity های کد با Entity های داکیومنت یکسان است؟
  • آیا نام‌گذاری‌ها مشابه هستند؟

5. داکیومنت تأثیرات

  • آیا تأثیر روی BackOffice.BFF مستند شده؟
  • آیا تأثیر روی BackOffice UI مستند شده؟
  • آیا Migration Guide نوشته شده؟

📊 گزارش مقایسه داکیومنت vs کد

چک‌لیست بررسی هفتگی:

# 1. بررسی Entity ها
cd CMS/src
grep -r "public class.*Entity" --include="*.cs" | wc -l
# مقایسه با تعداد Entity های مستند شده

# 2. بررسی Commands/Queries
find . -name "*Command.cs" -o -name "*Query.cs" | wc -l
# مقایسه با لیست Commands در داکیومنت

# 3. بررسی API Endpoints
grep -r "\[HttpGet\]\|\[HttpPost\]" --include="*.cs" | wc -l
# مقایسه با API های مستند شده

نمونه گزارش:

## گزارش هفتگی - 2025-12-01

### ✅ تطبیق کامل:
- Entity های UserOrder, UserOrderDetail
- Commission Calculation Logic
- Binary Tree Placement

### ⚠️ نیاز به به‌روزرسانی داکیومنت:
- [ ] فیلد VatPercentage به Entity اضافه شده ولی داکیومنت نشده
- [ ] CreateOrderCommand تغییر کرده ولی در داکیومنت قدیمی است

### ❌ اختلاف Business Logic:
- هیچ موردی
  • README with Quick Start
  • API Documentation (Swagger/gRPC)
  • User Manual (فارسی)
  • Admin Manual

📞 نکات مهم

1. قبل از Production Deploy

# بررسی Build
dotnet build --configuration Release

# اجرای Migrations
dotnet ef database update

# تست Health Check
curl http://YOUR_SERVER/health

# تست Hangfire Dashboard
# باز کردن: http://YOUR_SERVER/hangfire

# تست Manual Trigger
curl -X POST http://YOUR_SERVER/api/admin/trigger-weekly-calculation

2. Monitoring در Production

# Log Files
tail -f /var/log/cms/application.log

# Database Connections
SELECT * FROM sys.dm_exec_sessions WHERE database_id = DB_ID('Foursat_CMS')

# Hangfire Jobs
# Dashboard: /hangfire/recurring

# Worker Execution Log
SELECT TOP 10 * FROM WorkerExecutionLog ORDER BY StartTime DESC

3. Backup Strategy

  • Database: روزانه Full Backup + Hourly Transaction Log
  • Configuration Files: Git repository
  • User Data: Weekly full export

⚠️ بیزینس‌های کلیدی - چک‌لیست الزامی

هشدار: این بیزینس‌ها نباید هیچ‌وقت گم بشند! قبل از هر Release باید تطبیق کامل با کد داشته باشند.

🎯 بیزینس 1: Binary Tree (درخت دودویی)

قوانین اصلی (از دکتر):

  • هر User دقیقاً 2 زیرمجموعه مستقیم دارد (Left, Right)
  • Spillover: وقتی پر شد، زیرمجموعه بعدی به اولین جای خالی در سطح بعد می‌رود
  • محاسبه عمق (Depth): از ریشه تا آن Node
  • Parent تغییر نمی‌کند (فقط در ثبت‌نام تنظیم می‌شود)

چک‌لیست تطبیق:

# 1. بررسی کد
cd CMS/src/CMSMicroservice.Domain/Entities
grep -A 20 "class User" User.cs | grep -E "Parent|Left|Right"

# 2. بررسی منطق Placement
cd ../Application/UserCQ
grep -A 50 "PlaceInBinaryTree" CreateUserCommand.cs

# 3. تست
# آیا با 7 کاربر، Tree به شکل زیر است؟
#       1
#      / \
#     2   3
#    /|   |\
#   4 5   6 7

فایل داکیومنت مرتبط:

  • totalDoc/CMS/binary-tree-registration-guide.md
  • totalDoc/CMS/network-club-commission-system-v1.1.md (بخش Binary Tree)

💰 بیزینس 2: محاسبه کمیسیون (از دکتر)

قوانین اصلی:

  • محاسبه هر یکشنبه ساعت 00:05 UTC
  • فرمول: Commission = TotalPV × Percentage
  • شرط دریافت: MinimumPV باید رعایت شود
  • CarryOver: مانده به هفته بعد منتقل می‌شود
  • MaxCommission: سقف کمیسیون در هفته

چک‌لیست تطبیق:

# 1. بررسی Worker
cd CMS/src/CMSMicroservice.Application/BackgroundWorkers
grep -A 30 "CalculateCommission" CommissionCalculationWorker.cs

# 2. بررسی فرمول
grep "TotalPV.*Percentage" -r .

# 3. بررسی Cron Job
grep "Cron.*Sunday" -r . | grep "00:05"

# 4. تست
# با PV=1000 و Percentage=10%، آیا Commission=100 است؟

فایل داکیومنت مرتبط:

  • totalDoc/CMS/network-club-commission-system-v1.1.md (بخش Commission)
  • totalDoc/CMS/balance-calculation-carryover-logic.md

🏆 بیزینس 3: سطوح باشگاه (Club Levels)

قوانین اصلی (از دکتر):

  • 4 سطح: Bronze, Silver, Gold, Platinum
  • شرط ارتقا: تعداد PV یا تعداد زیرمجموعه فعال
  • سطح پایین نمی‌آید (یک طرفه)
  • مدت‌زمان عضویت (Duration): ماهانه یا سالانه

چک‌لیست تطبیق:

# 1. بررسی Entity
cd CMS/src/CMSMicroservice.Domain/Entities
grep -A 10 "ClubLevel" ClubMembership.cs

# 2. بررسی منطق ارتقا
cd ../Application/ClubMembershipCQ
grep -A 50 "UpgradeLevel" *.cs

# 3. تست
# آیا Bronze → Silver با شرایط مشخص اتفاق می‌افتد؟

فایل داکیومنت مرتبط:

  • totalDoc/CMS/network-club-commission-system-v1.1.md (بخش Club)

💳 بیزینس 4: برداشت (Withdrawal) - از شما

قوانین اصلی:

  • حداقل موجودی برای برداشت: مثلاً 100,000 تومان
  • کارمزد برداشت: مثلاً 2%
  • وضعیت‌ها: Pending → Approved/Rejected
  • فقط مدیر می‌تواند Approve/Reject کند
  • پس از Approve: واریز به حساب

چک‌لیست تطبیق:

# 1. بررسی Commands
cd CMS/src/CMSMicroservice.Application/WithdrawalCQ
ls -1 *Command.cs

# 2. بررسی حداقل موجودی
grep "MinimumWithdrawal" -r .

# 3. بررسی کارمزد
grep "WithdrawalFee" -r .

فایل داکیومنت مرتبط:

  • totalDoc/CMS/implementation-progress.md (Phase 10)

📧 بیزینس 5: ارسال اطلاع‌رسانی

قوانین اصلی:

  • Email: برای تأیید ثبت‌نام، کمیسیون، فعال‌سازی باشگاه
  • SMS: برای تأیید موبایل، اطلاعیه‌های مهم
  • زمان ارسال: بلافاصله بعد از event
  • Template: HTML برای Email، متن ساده برای SMS

چک‌لیست تطبیق:

# 1. بررسی NotificationService
cd CMS/src/CMSMicroservice.Application/Common/Services
ls -1 *Notification*

# 2. بررسی Template ها
find . -name "*.html" -o -name "*Template*"

# 3. تست
# آیا بعد از Commission calculation، Email ارسال می‌شود؟

فایل داکیومنت مرتبط:

  • totalDoc/CMS/email-sms-configuration-guide.md

🛒 بیزینس 6: سفارش و فاکتور (Order & Factor)

قوانین اصلی:

  • هر سفارش یک فاکتور (UserOrder) دارد
  • هر فاکتور شامل چند FactorDetail است
  • محاسبه PV از سفارش
  • وضعیت سفارش: Pending → Paid → Processing → Completed
  • مالیات (VAT): یک درصد ثابت روی کل سفارش

چک‌لیست تطبیق:

# 1. بررسی Entity
cd CMS/src/CMSMicroservice.Domain/Entities
grep -A 20 "class UserOrder" UserOrder.cs
grep -A 20 "class FactorDetail" FactorDetail.cs

# 2. بررسی محاسبه PV
cd ../Application/OrderCQ
grep "CalculatePV" -A 30 CreateOrderCommand.cs

# 3. بررسی VAT
grep "VatPercentage" -r .

فایل داکیومنت مرتبط:

  • totalDoc/CMS/network-club-commission-system-v1.1.md (بخش Orders)
  • totalDoc/REMAINING-TASKS.md (VAT System)

📋 چک‌لیست بررسی ماهانه بیزینس

هر ماه یکبار این چک‌لیست را اجرا کن:

ماه: _________ | تاریخ بررسی: _________

  • Binary Tree: Placement و Spillover صحیح کار می‌کند؟
  • Commission: فرمول محاسبه درست است؟ Cron Job اجرا می‌شود؟
  • CarryOver: مانده به هفته بعد منتقل می‌شود؟
  • Club Levels: ارتقا به سطح بالاتر صحیح است؟
  • Withdrawal: فرآیند برداشت کامل کار می‌کند؟
  • Email/SMS: تمام Notification ها ارسال می‌شوند؟
  • Order/Factor: PV محاسبه می‌شود؟ VAT اضافه می‌شود؟

نتیجه بررسی:

✅ همه بیزینس‌ها OK
⚠️ نیاز به بررسی بیشتر: _________________
❌ مشکل یافت شد: _________________

📊 تخمین زمان کل (به‌روز شده)

دسته زمان شامل
اولویت بالا 1 هفته + 30 دقیقه درگاه پرداخت، تنظیمات Production
اولویت متوسط 3.5 هفته فروشگاه (2 هفته) + VAT (2 روز) + RBAC (1.5 هفته)
اولویت پایین 2 هفته تست‌نویسی (موکول شده)
بهبودهای اختیاری 1 هفته Redis, Sentry, Slack, FCM
جمع کل (بدون تست) 4.5-5.5 هفته

🎉 وضعیت فعلی

MVP: 100% آماده
Production Ready: 95%
آماده Launch: بله (با تکمیل درگاه پرداخت + تنظیمات)

سیستم فعلی می‌تواند:

  • کاربران را در Binary Tree قرار دهد
  • کمیسیون هفتگی محاسبه کند
  • Email/SMS ارسال کند
  • درخواست‌های برداشت را مدیریت کند

فقط نیاز است:

  • درگاه پرداخت متصل شود (برای واریز خودکار)
  • تنظیمات Email/SMS در Production انجام شود

توصیه: می‌توان با MVP فعلی launch کرد و Phase 9 (فروشگاه) را بعداً اضافه کرد.