POST /api/v2/management/office

Route Info

منطق عملکرد تابع

ورودی‌ها (Request Fields)

نمونه درخواست:

POST /api/v2/management/office
Authorization: Bearer {JWT_TOKEN}
Content-Type: application/json

{
  "branch": 7
}

خروجی (Response)

نمونه پاسخ:

{
  "status": true,
  "time": 1732290287,
  "data": {
    "office": [
      {
        "id": 7,
        "en_title": "Isfahan Branch",
        "fa_title": "دفتر مرکزی اصفهان",
        "country": "IR",
        "credit_limit": 20000000,
        "base_online": 12000000
      }
    ],
    "api": [
      {
        "type": "sms",
        "url": "https://soap.melipayamak.com",
        "username": "isf-admin",
        "status": 1
      },
      {
        "type": "accounting",
        "url": "https://hub.airplus.app/v2/accounting",
        "status": 1
      }
    ]
  }
}

نکات امنیتی و احراز هویت

• احراز هویت حتماً باید توسط middleware authWithJwt انجام شود.
• در نسخه فعلی هیچ کنترل سطح دسترسی برای مشاهده دفاتر دیگر وجود ندارد.
• پیشنهاد: اعمال Role-based restriction (مانند ADMIN, FINANCE, SUPPORT).

عملکرد و Performance

• تابع سبک و سریع است زیرا فقط از دو جدول DB خوانش دارد.
• در بارهای سنگین یا محیط‌های multi-branch، پیشنهاد می‌شود cache 5 دقیقه‌ای برای داده‌های دفتر فعال شود.
• در پاسخ فعلی داده‌ها بدون pagination بازگردانده می‌شوند.

وابستگی‌ها

• use Illuminate\Support\Facades\DB;
• use Illuminate\Http\Request;
• use Carbon\Carbon;
• use Exception;

کدهای خطا

پیشنهادهای امنیتی

• اعمال تعیین سطح دسترسی مشاهده به نقش‌های مدیریتی.
• پنهان‌سازی فیلدهای حساس مانند شناسه کاربری و رمزهای اتصال API.
• رمزنگاری سمت سرور برای آیتم‌های api.username و api.data.

پیشنهادهای بهبود

• افزودن فیلد storage_usage برای مدیریت فضا و فایل‌های شعبه.
• عدم نیاز به فراخوانی مستقیم DB در هر درخواست (استفاده از Redis cache).
• افزودن قابلیت سرچ و فیلتر بر اساس نوع سرویس در بخش api.

ممیزی و لاگ‌ها

• هیچ لاگی برای مشاهده اطلاعات دفتر ثبت نمی‌شود.
• پیشنهاد: ثبت رویداد BranchViewed در جدول system_logs همراه با IP و User-Agent.

جمع‌بندی