customerTicket/docs/PRODUCTION_SEED.md

انتقال خودکار SQLite به PostgreSQL Production

این فرایند تمام داده‌های پایدار فعلی را منتقل می‌کند:

• کاربران، hash رمزهای قابل استفاده، superuser، گروه‌ها و permissionها
• واحدهای سازمانی، عضویت‌ها، نقش‌ها و پروفایل پرسنل
• مشتریان، گروه مخاطبان، دسته‌بندی‌ها و SLA
• branding، عنوان صفحات، SMS templateها، NotificationPolicy و سیاست فایل‌ها
• تیکت‌ها، ارسال‌های گروهی، رویدادها، پیام‌ها، رسیدهای خواندن و attachmentها
• تمام فایل‌های موجود در MEDIA_ROOT، شامل branding، avatar و فایل تیکت

داده‌های موقتی و خطرناک زیر عمداً منتقل نمی‌شوند: sessionها، OTPهای قبلی، Magic Linkهای قبلی، admin log و NotificationJob. انتقال outbox قبلی می‌توانست بعد از بالا آمدن worker باعث ارسال مجدد SMS یا Bale شود.

خروجی ساخته‌شده

دستور زیر از SQLite فعلی snapshot می‌گیرد:

.\.venv\Scripts\python.exe manage.py export_production_seed --output production-seed --force

برای وضعیت فعلی پروژه خروجی قبلاً تولید شده و شامل ۳۹۵ رکورد پایدار و ۵۷ فایل media است:

production-seed/
  data.json.gz
  media.tar.gz
  manifest.json

این پوشه شامل اطلاعات شخصی و password hash است و عمداً توسط Git و Docker ignore می‌شود. آن را commit، ایمیل یا در فضای عمومی بارگذاری نکنید.

انتقال امن به volume سرور

در Coolify volume خارجی customer_ticket_seed را ایجاد کنید. سه فایل بالا باید مستقیماً در ریشه آن قرار بگیرند، به شکلی که container مسیر زیر را ببیند:

/app/production-seed/manifest.json
/app/production-seed/data.json.gz
/app/production-seed/media.tar.gz

فایل‌ها را با قابلیت Persistent Storage/File Mount خود Coolify یا یک انتقال امن مانند SCP به سرور ببرید. اگر روی سرور در /tmp/customer-ticket-seed قرار گرفته‌اند، مدیر سرور می‌تواند volume را این‌گونه پر کند:

docker run --rm \
  -v customer_ticket_seed:/target \
  -v /tmp/customer-ticket-seed:/source:ro \
  alpine:3.20 sh -c 'cp /source/data.json.gz /source/media.tar.gz /source/manifest.json /target/'

پس از کپی، نسخه موجود در /tmp را امن حذف کنید. volume seed در Compose فقط read-only داخل web mount می‌شود.

اجرای خودکار

در اولین startup سرویس web ترتیب زیر اجرا می‌شود:

1. انتظار برای PostgreSQL
2. اجرای migrationها
3. اعتبارسنجی SHA-256 فایل‌های seed
4. اطمینان از خالی بودن PostgreSQL و media volume
5. حذف defaultهای data migration و import کامل snapshot
6. انتقال media به volume اصلی
7. ثبت ProductionSeedState
8. رد کردن bootstrap برای حفظ دقیق snapshot به‌عنوان منبع authoritative
9. اجرای collectstatic و Gunicorn

در deployهای بعدی checksum قبلاً ثبت‌شده تشخیص داده می‌شود و import دوباره انجام نمی‌شود. اگر bundle نباشد، با REQUIRE_PRODUCTION_SEED=1 سرویس عمداً متوقف می‌شود تا production ناقص بالا نیاید.

محدودیت‌های ایمنی

• import فقط روی PostgreSQL اجرا می‌شود.
• دیتابیس دارای User یا seed قبلی با checksum متفاوت پذیرفته نمی‌شود.
• media volume غیرخالی overwrite نمی‌شود.
• مسیرهای مشکوک، symlink و path traversal در archive رد می‌شوند.
• checksum هر دو فایل پیش از هر تغییر بررسی می‌شود.
• شکست import باعث rollback دیتابیس و حذف فایل‌های کپی‌شده همان اجرا می‌شود.

اگر واقعاً می‌خواهید production بدون snapshot بالا بیاید، REQUIRE_PRODUCTION_SEED=0 بگذارید؛ در این حالت فقط bootstrap استاندارد اجرا می‌شود و کاربران دارای password فعلی SQLite منتقل نخواهند شد.