Skip to main content
#P1481

POST /base/accommodation/rooms/delete

Route Info

Method Endpoint Controller Middleware Purpose
POST /api/v2/base/accommodation/rooms/delete V2BaseController@accommodationRoomsDelete authWithJwt حذف گروهی انواع اتاق‌های اقامتگاه و نگاشت‌های مربوطه از جداول سیستم.

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

تابع accommodationRoomsDelete مسئول حذف تمام انواع اتاق‌های وابسته به یک اقامتگاه (هتل) است. این تابع ابتدا شناسه‌های اتاق‌های وابسته را بر اساس پارامتر ورودی accommodation_id واکشی می‌کند، سپس نگاشت‌های تبعی در جدول mapping_roomtypes را پاک کرده و در نهایت خود رکوردهای اتاق‌های اقامتگاه را حذف می‌کند.

منطق کلی:
  • دریافت ورودی accommodation_id و اختیاری service.
  • ایجاد کوئری داخلی با JOIN بین جداول accommodation_roomtypes و mapping_roomtypes.
  • در صورت وجود پارامتر service، فقط اتاق‌هایی حذف می‌شوند که دارای مقدار در آن سرویس باشند.
  • پس از حذف از دو جدول، پاسخ موفق شامل وضعیت بولی payload=true بازگردانده می‌شود.

ورودی‌ها

نام پارامتر نوع داده منبع الزامی توضیح
accommodation_id integer Body بله شناسه اقامتگاه مقصد برای حذف اتاق‌ها.
service string Body اختیاری نام سرویس (مثلاً snapptrip) برای اعمال حذف محدود.

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

POST /api/v2/base/accommodation/rooms/delete
Authorization: Bearer {JWT_TOKEN}
Content-Type: application/json

{
  "accommodation_id": 1870,
  "service": "snapptrip"
}

خروجی (Response)

فیلد نوع داده توضیح
payload boolean نمایانگر موفقیت حذف رکوردها.
meta.timestamp integer زمان یونیکس ثبت پاسخ.

نمونه پاسخ موفق:

{
  "payload": true,
  "meta": {
    "timestamp": 1750669152
  }
}

نکات امنیتی

  • مسیر فقط با احراز هویت JWT معتبر قابل دستیابی است.
  • تمام رکوردها فقط از شعبه مربوطه حذف می‌شوند در صورت اعمال کنترل مرکزی (پیشنهاد: اضافه شود).
  • بدون تأیید پیش‌شرط، حذف داده‌ها خطرناک است — نیاز به اعتبارسنجی نقش (Role).

نکات عملکردی

  • عملیات delete() هم‌زمان روی دو جدول انجام می‌گیرد، بنابراین هزینه I/O دو برابر معمول است.
  • پیشنهاد می‌شود حذف‌ها در تراکنش DB::transaction() انجام گیرند تا از ناسازگاری داده جلوگیری شود.
  • TTL کش مربوطه (Redis) برای کلید accommodations:cron:services:{service}:{accommodation_id} باید پس از حذف ریست شود.

وابستگی‌ها

  • use Illuminate\Support\Facades\DB;
  • use Illuminate\Support\Facades\Redis;
  • use Carbon\Carbon;
  • use Exception;

کدهای خطا

کد شرح خطا منبع
404 شناسه اقامتگاه وجود ندارد یا خالی است. accommodationRoomsDelete()
403 کاربر مجاز به حذف رکورد نیست. authWithJwt
500 خطا در حذف رکورد از DB. DB Facade

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

  • افزودن ROLE "DataManager" برای کنترل سطح حذف.
  • لاگ‌گذاری حذف‌ها در جدول audit به همراه شناسه اقامتگاه و شناسه اپراتور.
  • اضافه کردن تأیید دو مرحله‌ای برای حذف‌های گسترده.

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

  • استفاده از SoftDelete برای حفظ تاریخچه رکوردهای اتاق.
  • ارسال پاسخ تفکیکی شامل تعداد رکوردهای حذف‌شده.
  • امکان فیلتر حذف بر اساس وضعیت فعال یا سرویس خاص.
  • اتصال حذف‌ها به فرآیند Cron برای به‌روزرسانی خدمات خارجی.

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

  • ثبت لاگ با نوع DeleteRoomType.
  • فیلدهای پیشنهادی: operator_id، branch، accommodation_id، service.
  • سطح لاگ توصیه‌شده: Critical.

جمع‌بندی

مسیر POST /base/accommodation/rooms/delete نقطه اصلی برای پاک‌سازی انواع اتاق‌های اقامتگاه است. حذف هم‌زمان نگاشت‌ها و اتاق‌ها بدون Transaction انجام می‌شود که باید در نسخه بعدی اصلاح گردد. پیشنهاد می‌شود پس از حذف، کلیدهای Redis مربوطه آزاد (evict) شوند تا وضعیت لحظه‌ای سرویس‌های اتاق‌دار (مانند Snapptrip) با منبع هماهنگ بماند.
Back to top