a4fc807160
Introduce a comprehensive address management system allowing users to
save, manage, and reuse sender and receiver addresses during the
ordering process. This feature bridges the WordPress frontend with the
Laravel backend API.
Key changes:
- Backend (Laravel):
- Added `AddressBookEntry` model and migration for storing addresses
with role (sender/receiver), usage tracking, and default status.
- Implemented `AddressBookController` with full CRUD functionality
secured via Sanctum and ownership validation.
- Integrated address usage tracking and upsert logic into the
`CustomerOrderController` to prevent duplicate entries.
- Added 18 new feature tests covering ownership, limits, and
validation.
- Frontend (WordPress):
- Added a new "Address Book" tab in the user dashboard with card-based
UI, filtering, and SweetAlert2 integration.
- Enhanced the order form with dropdown selectors for saved addresses
and "save this address" checkboxes for both sender and receiver.
- Implemented secure AJAX proxies in `user-bridge.php` with nonce
and sanitization.
- Documentation:
- Updated `AGENT.md` and `CLIENT_DELIVERY.md` to reflect phase 3.9
completion and updated the project roadmap.
- Removed obsolete `README-INSTALL.md`.
582 lines
28 KiB
Markdown
582 lines
28 KiB
Markdown
# IFNEX — چک‌لیست تحویل به مشتری
|
||
|
||
> **وضعیت:** آماده برای دیپلوی (فاز ۳.۸، ۳.۸.۱ و ۳.۹ تکمیل شد)
|
||
> **فاز جاری:** فاز ۳.۹ — دفترچه آدرس (تکمیل) → قدم بعدی: دیپلوی Production (فاز ۳.۱۰)
|
||
> **تاریخ آخرین به‌روزرسانی:** ۲۰۲۶-۱۱-۰۱
|
||
> **مخزن:** [git.vernahost.ir/gitmodir110/ifnex](https://www.git.vernahost.ir/gitmodir110/ifnex)
|
||
|
||
> ⚠️ این فایل فقط برای مدیریت تعهدات، تست و تحویل نسخهٔ فعلی مشتری است و جایگزین `AGENT.md` یا `IFNEX_Roadmap.md` نیست.
|
||
|
||
---
|
||
|
||
## راهنمای وضعیت‌ها
|
||
|
||
| نشان | معنی |
|
||
|------|------|
|
||
| ✅ | تکمیل‌شده |
|
||
| 🟡 | پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
| ⏳ | در انتظار |
|
||
| 🔴 | مسدود |
|
||
| ❌ | پیاده‌سازی‌نشده |
|
||
|
||
---
|
||
|
||
# ۱. فرانت‌اند و صفحهٔ اصلی
|
||
|
||
## ۱.۱ هدایت دکمهٔ ردیابی مرسوله
|
||
|
||
**الزام مشتری:** در بخش Hero صفحهٔ اصلی وردپرس، دکمهٔ «ردیابی مرسوله» کاربر را به صفحهٔ اختصاصی Tracking هدایت کند.
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
| فایل‌ها | `03_WordPress/wp-content/themes/ifnex/`<br>`03_WordPress/wp-content/plugins/ifnex-bridge/` |
|
||
|
||
**تست پذیرش:**
|
||
|
||
- [ ] کلیک روی دکمهٔ CTA
|
||
- [ ] ریدایرکت صحیح انجام می‌شود
|
||
- [ ] URL مقصد صحیح است
|
||
- [ ] صفحهٔ Tracking درست نمایش داده می‌شود
|
||
- [ ] رفتار در حالت Login و Guest بررسی شد
|
||
|
||
---
|
||
|
||
## ۱.۲ فرم ثبت سفارش چندمرحله‌ای
|
||
|
||
**الزام مشتری:** پس از تکمیل مرحلهٔ اول، مرحلهٔ دوم بدون خطا Load شود.
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
| باگ تاریخی | بسته‌نبودن یک `div` در فایل `shortcodes.php` |
|
||
| فایل‌ها | `includes/shortcodes.php`<br>`assets/js/ifnex-order-form.js` |
|
||
|
||
**تست پذیرش:**
|
||
|
||
- [ ] حرکت رو به جلو بین مراحل
|
||
- [ ] حرکت رو به عقب بین مراحل
|
||
- [ ] اعتبارسنجی فرم در هر مرحله
|
||
- [ ] حفظ اطلاعات مراحل قبلی
|
||
- [ ] Console مرورگر بدون Error
|
||
- [ ] رفتار Export و Import بررسی شد
|
||
|
||
---
|
||
|
||
# ۲. داشبورد مشتری و وضعیت مالی
|
||
|
||
## ۲.۱ مانده حساب مشتری
|
||
|
||
**الزام مشتری:** در داشبورد مشتری، علاوه بر موجودی کیف پول و سفارش‌ها، مانده حساب نیز نمایش داده شود.
|
||
|
||
**فرمول مورد انتظار:**
|
||
|
||
```text
|
||
Account Balance = Wallet Balance − Outstanding Approved Obligations
|
||
```
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
|
||
**تست پذیرش:**
|
||
|
||
- [ ] کیف پول مثبت
|
||
- [ ] مشتری بدون بدهی
|
||
- [ ] مشتری دارای بدهی
|
||
- [ ] مشتری با چند سفارش تأییدشده ولی پرداخت‌نشده
|
||
- [ ] نمایش صحیح ارز
|
||
- [ ] بدهی چندارزی به مبلغ ریالی اشتباه تبدیل نمی‌شود
|
||
|
||
---
|
||
|
||
# ۳. تأیید سفارش پیش از پرداخت
|
||
|
||
> **الزام اصلی:** مشتری بلافاصله پس از ثبت سفارش نباید وارد درگاه پرداخت شود.
|
||
|
||
## ۳.۱ فلوی عمومی
|
||
|
||
```text
|
||
Create Order
|
||
→ Pending Approval
|
||
→ Staff Review
|
||
→ Approved
|
||
→ Documents / Commitment Verification
|
||
→ Payment Enabled
|
||
→ Wallet OR Online Payment
|
||
→ Paid
|
||
→ Processed
|
||
```
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید End-to-End |
|
||
|
||
## ۳.۲ سفارش Export
|
||
|
||
```text
|
||
Create Export Order
|
||
→ Pending Approval
|
||
→ Staff Approval
|
||
→ Documents Available
|
||
→ Customer Downloads Documents
|
||
→ Customer Signs / Fingerprints
|
||
→ Customer Uploads Signed Documents
|
||
→ Staff Verification
|
||
→ Payment Enabled
|
||
→ Wallet / Online Payment
|
||
→ Paid
|
||
→ Shipment Processing
|
||
```
|
||
|
||
**اسناد مرتبط:** AWB، Invoice، Label، فرم‌های تعهدنامه و سایر اسناد الزامی.
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | ✅ تکمیل — تست End-to-End تأیید شد |
|
||
|
||
**نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۳):**
|
||
|
||
- چرخهٔ تعهدنامه به‌صورت کامل تست شد: دانلود قالب توسط مشتری (از طریق پروکسی وردپرس با توکن)، آپلود فایل امضاشده، تأیید یا رد توسط ادمین در Filament به‌همراه اعلان دیتابیسی، و نمایش وضعیت (تأییدشده / ردشده + دلیل رد) در پورتال مشتری.
|
||
- دانلود امن فایل‌ها در پنل ادمین از طریق روت‌های `admin.commitment-forms.*` و از دیسک secure انجام می‌شود.
|
||
|
||
**نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):**
|
||
|
||
- فلوی کامل سفارش (ثبت ← تأیید ← آپلود تعهدنامه ← تأیید تعهدنامه ← پرداخت کیف پول یا درگاه) به‌صورت End-to-End تست و تأیید شد.
|
||
|
||
## ۳.۳ سفارش Import
|
||
|
||
```text
|
||
Create Import Order
|
||
→ Pending Approval
|
||
→ Staff Review
|
||
→ Required Documents
|
||
→ Customer Verification / Upload
|
||
→ Staff Verification
|
||
→ Payment Enabled
|
||
→ Wallet / Online Payment
|
||
→ Paid
|
||
→ Shipment Processing
|
||
```
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
|
||
---
|
||
|
||
# ۴. چک‌لیست کارمند
|
||
|
||
**الزام مشتری:** برای هر سفارش یک چک‌لیست عملیاتی وجود داشته باشد.
|
||
|
||
**فیلدهای اجباری هر آیتم:**
|
||
|
||
| فیلد |
|
||
|------|
|
||
| عنوان آیتم |
|
||
| وضعیت |
|
||
| Required / Optional |
|
||
| کارمند تکمیل‌کننده |
|
||
| تاریخ و ساعت تکمیل |
|
||
| یادداشت |
|
||
| پیوست (در صورت نیاز) |
|
||
|
||
**الزامات مدیر:**
|
||
|
||
- مشاهدهٔ تمام مراحل
|
||
- مشاهدهٔ کارمند انجام‌دهنده
|
||
- مشاهدهٔ تاریخ و ساعت
|
||
- مشاهدهٔ موارد ناقص
|
||
- امکان گزارش‌گیری
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | ✅ تکمیل — نمونه‌سازی خودکار پس از تأیید |
|
||
|
||
**نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):**
|
||
|
||
- چک‌لیست پس از تأیید سفارش (در `ShipmentReviewService::approve`) از قالب‌های فعال (`ShipmentChecklistTemplate`) نمونه‌سازی می‌شود.
|
||
- مدیریت کامل در `ChecklistsRelationManager` روی `ShipmentResource` و `ShipmentChecklistResource` انجام می‌شود.
|
||
- اکشن‌های تکمیل تکی و گروهی به‌همراه فیلدهای `completed_by` و `completed_at` پیاده‌سازی شدند.
|
||
|
||
---
|
||
|
||
# ۵. تاریخچه و تایم‌لاین مرسوله
|
||
|
||
**الزام مشتری:** مدیر بتواند تاریخچهٔ کامل هر مرسوله را از ابتدا تا انتها مشاهده کند.
|
||
|
||
هر تغییر وضعیت باید شامل موارد زیر باشد:
|
||
|
||
- وضعیت قبلی
|
||
- وضعیت جدید
|
||
- کاربر / کارمند
|
||
- تاریخ
|
||
- ساعت
|
||
- یادداشت
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
|
||
---
|
||
|
||
# ۶. اسناد PDF
|
||
|
||
**الزام مشتری:** اسناد AWB، Invoice، Label، فاکتور واردات و تعهدنامه‌ها تولید شوند و طراحی آن‌ها تا حد امکان مطابق نمونه‌های اکسل و اسناد کارفرما باشد.
|
||
|
||
> **توجه:** تطبیق ۱۰۰٪ پیکسلی به دلیل تفاوت موتور PDF با اکسل ممکن نیست. هدف، نزدیک‌ترین تطبیق عملی و قابل چاپ است.
|
||
|
||
## ۶.۱ بازطراحی انجام‌شده (۲۰۲۶-۱۰-۰۴)
|
||
|
||
| سند | طراحی |
|
||
|------|-------|
|
||
| AWB | A4 افقی، پالت navy + amber، چیدمان جدولی، بارکد در هدر، لوگوی IFNEX، گرید ۴×۱ |
|
||
| Invoice | A4 عمودی، طراحی هم‌سبک AWB، فیلدهای خالی با `@if` مخفی، جدول با راه‌راه Zebra |
|
||
| Import Invoice | A4 عمودی، بر اساس شیت ENG Invoice |
|
||
| Label | A5 افقی، بدون برند (white-label)، تک‌رنگ، بارکد بزرگ، جدول وزن و ابعاد |
|
||
|
||
همهٔ اسناد با **dompdf** و چیدمان **جدولی** (نه flexbox) تولید می‌شوند تا سازگاری کامل و بدون overflow تضمین شود.
|
||
|
||
## ۶.۲ وضعیت تأیید PDF
|
||
|
||
| مورد | وضعیت |
|
||
|------|--------|
|
||
| AWB | ✅ بازطراحی شد |
|
||
| Export Invoice | ✅ بازطراحی شد |
|
||
| Import Invoice | ✅ بازطراحی شد — نیازمند تأیید نهایی مشتری |
|
||
| Label | ✅ بازطراحی شد |
|
||
| بارکد | ✅ Code-128 قابل اسکن |
|
||
| چیدمان | ✅ جدولی، بدون overflow |
|
||
| تایپوگرافی | ✅ DejaVu Sans / Vazirmatn |
|
||
| اندازهٔ صفحه | ✅ A4 افقی (AWB) / A4 عمودی (Invoice) / A5 افقی (Label) |
|
||
| خروجی چاپ | ⏳ نیازمند تست چاپ فیزیکی |
|
||
|
||
| وضعیت کلی بخش | مقدار |
|
||
|----------------|-------|
|
||
| نتیجه | 🟡 پیاده‌سازی‌شده — در انتظار تأیید نهایی مشتری |
|
||
|
||
---
|
||
|
||
# ۷. اطلاعات مالی مشتری (کارمند / مدیر)
|
||
|
||
**الزام مشتری:** کارمند یا مدیر بتواند با انتخاب یا جستجوی مشتری، اطلاعات مالی کامل او را مشاهده کند.
|
||
|
||
**اطلاعات مورد نیاز:**
|
||
|
||
- موجودی فعلی
|
||
- مطالبات / بدهی‌ها
|
||
- ارز
|
||
- تراکنش‌های اخیر
|
||
- سفارش‌های اخیر
|
||
- شمارهٔ مرجع سفارش
|
||
- مبلغ
|
||
- وضعیت پرداخت
|
||
- تاریخ‌ها
|
||
- یادداشت‌ها
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | ✅ تکمیل — صفحهٔ نمای کلی مالی مشتری ساخته شد |
|
||
|
||
**نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):**
|
||
|
||
- صفحهٔ «وضعیت مالی مشتری» در `App\Filament\Pages\CustomerFinancialOverview` ساخته شد.
|
||
- مدیر یا کارمند با جستجوی مشتری موارد زیر را می‌بیند:
|
||
- ۴ کارت KPI: موجودی کیف پول، بدهی فعلی، کل پرداختی، مانده حساب
|
||
- جدول بدهی‌های چندارزی به تفکیک ارز (EUR / USD / AED / CNY)
|
||
- ۵ سفارش اخیر و ۵ تراکنش اخیر
|
||
- دکمه‌های اقدام: اعتبار جدید، سفارش‌ها، وضعیت مالی
|
||
- طراحی با گرید ۱۲ ستونی و CSS اختصاصی IFNEX انجام شده است.
|
||
|
||
---
|
||
|
||
# ۸. اعتبار مشتری (چندارزی)
|
||
|
||
**الزام مشتری:** فقط مدیر کل بتواند برای مشتریِ شناخته‌شده اعتبار ایجاد یا افزایش دهد.
|
||
|
||
## ۸.۱ قاعدهٔ اصلی
|
||
|
||
اگر مشتری مثلاً **۵۰ EUR** بدهکار باشد، بدهی باید به همان ارز ثبت شود و **نباید** به مبلغ ریالی روز تبدیل و جایگزین شود.
|
||
|
||
## ۸.۲ اطلاعات لازم هنگام تسویهٔ ریالی
|
||
|
||
| فیلد |
|
||
|------|
|
||
| مبلغ اصلی |
|
||
| ارز اصلی |
|
||
| ارز تسویه |
|
||
| نرخ تبدیل |
|
||
| تاریخ نرخ |
|
||
| مبلغ تسویه |
|
||
| دلیل / مرجع |
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | ✅ تکمیل — سیستم اعتبار چندارزی کامل شد |
|
||
|
||
**نکات پیاده‌سازی (۲۰۲۶-۱۰-۰۴):**
|
||
|
||
- `CustomerCreditService` با متدهای `grantCredit()`، `settle()` و `getCustomerDebtsByCurrency()`
|
||
- جدول‌های `customer_credits` و `credit_settlements` — بدهی به همان ارز ثبت و تسویه با نرخ روز
|
||
- `CustomerCreditResource` با فرم ایجاد و اکشن تسویه (`exchange_rate`، `rate_date`، `from_wallet`)
|
||
- `CreditsRelationManager` روی `UserResource` برای مشاهدهٔ درجا
|
||
- نمایش بدهی‌های ارزی در پورتال مشتری (تب کیف پول و پروفایل در وردپرس)
|
||
- ویجت داشبورد «بدهی‌های ارزی تسویه‌نشده» به‌همراه badge روی منو
|
||
- اصلاح race condition در `settle()` با بررسی مجدد مانده پس از `lockForUpdate()`
|
||
- Policy: فقط `super_admin` مجاز به اعطای اعتبار است
|
||
|
||
---
|
||
|
||
# ۹. ایمپورت گروهی وضعیت ترکینگ
|
||
|
||
**الزام مشتری:** امکان Import گروهی آخرین وضعیت Trackingها در پنل مدیریت.
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| ورودی | فایل CSV یا فرمت Import تأییدشده |
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند تأیید نهایی |
|
||
|
||
**خروجی مورد انتظار:**
|
||
|
||
- یافتن مرسوله
|
||
- اعتبارسنجی شمارهٔ ترکینگ
|
||
- به‌روزرسانی وضعیت
|
||
- ثبت تاریخچه
|
||
- ثبت نتیجهٔ Import
|
||
- گزارش ردیف‌های ناموفق
|
||
|
||
---
|
||
|
||
# ۱۰. ویرایش مدیریتی و Audit Log
|
||
|
||
**الزام مشتری:** مدیر بتواند تقریباً همهٔ اطلاعات عملیاتی لازم را ویرایش کند.
|
||
|
||
> **قاعدهٔ مهم:** تغییرات مدیریتی باید قابل Audit باشند.
|
||
|
||
**اطلاعات Audit:**
|
||
|
||
- کاربر
|
||
- نوع عملیات
|
||
- مدل
|
||
- رکورد
|
||
- مقدار قبلی
|
||
- مقدار جدید
|
||
- تاریخ
|
||
- ساعت
|
||
- IP (در صورت کاربرد)
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند بررسی امنیت و مجوز دسترسی |
|
||
|
||
---
|
||
|
||
# ۱۱. یکپارچه‌سازی پیامک
|
||
|
||
| مورد | مقدار |
|
||
|------|-------|
|
||
| سرویس‌دهنده | Kavenegar |
|
||
| وضعیت | 🟡 پیاده‌سازی‌شده — نیازمند پیکربندی Production و تأیید End-to-End |
|
||
|
||
**موارد استفاده:**
|
||
|
||
- تأیید موبایل
|
||
- تأیید ثبت‌نام
|
||
- ثبت سفارش
|
||
- تأیید سفارش
|
||
- رد سفارش
|
||
- پرداخت موفق
|
||
- تغییر وضعیت ترکینگ
|
||
- اعلان‌های مهم سیستم
|
||
|
||
---
|
||
|
||
# ۱۲. سخت‌سازی Production
|
||
|
||
## ۱۲.۱ امنیت
|
||
|
||
| مورد | وضعیت |
|
||
|------|--------|
|
||
| حذف اسکریپت‌های دیباگ (opcache_reset / header / cache-buster) | ✅ ۲۰۲۶-۱۰-۳۱ — از ۵ فایل پلاگین حذف شد؛ cache-buster با filemtime جایگزین شد |
|
||
| چرخش کلیدهای افشاشده | 🔑 در چک‌لیست استقرار (بخش ۴.۴ `DEPLOYMENT_HANDOFF.md`) — قبل از دیپلوی چرخش شود |
|
||
| بررسی نحوهٔ نگهداری Bridge API Key | ✅ ۲۰۲۶-۱۰-۳۱ — `wp-config.php` از گیت حذف شد (فقط sample در مخزن)؛ راهنمای چرخش در `.env.example` |
|
||
| بررسی مجوز روت‌های Staff | ✅ `StaffApiMiddleware` روی همهٔ `/staff/*` |
|
||
| بررسی عملیات مختص مدیر | ✅ Policy روی `CustomerCredit` و `Shipment` |
|
||
| اعتبارسنجی آپلود فایل | ✅ ۲۰۲۶-۱۰-۳۱ — `mimetypes` (بررسی محتوا) + `mimes` + `max:5120` + دیسک secure + چک مالکیت |
|
||
| بررسی مالکیت و مجوز اسناد | ✅ `ShipmentPolicy` و `CustomerCreditPolicy` |
|
||
| امنیت Callback پرداخت | ✅ `OrderPaymentService` با محافظ Mock در Production |
|
||
| غیرفعال‌سازی Mock Gateway در Production | ✅ ۲۰۲۶-۱۰-۳۱ — گارد سخت: در `APP_ENV=production` درگاه تستی با RuntimeException مسدود می‌شود |
|
||
| Rate Limiting | ✅ ۲۰۲۶-۱۰-۰۴ — ۶ لایه throttle: auth / sms / public / customer / wallet / staff |
|
||
|
||
## ۱۲.۲ یکپارچگی مالی
|
||
|
||
| مورد | وضعیت |
|
||
|------|--------|
|
||
| حفاظت از همزمانی کیف پول | ✅ `lockForUpdate()` در `CustomerCreditService::settle()` |
|
||
| یکتایی پرداخت (Idempotency) | ✅ race condition اصلاح شد |
|
||
| منطق مصرف کد تخفیف | ✅ ۲۰۲۶-۱۰-۳۱ — `DiscountCodeService` + جدول `discount_code_usages`: قفل رقابتی، مصرف یک‌بار، رکورد Audit، گارد ظرفیت در قیمت‌گذاری، ۴۲۲ در شکست مصرف. باگ P0 تاریخی: متد `consumeDiscountCode()` وجود نداشت و ثبت سفارش را می‌شکست — برطرف شد |
|
||
| دقت مبلغ و ارز | ✅ cast با `decimal:2` |
|
||
| یکپارچگی بدهی چندارزی | ✅ بدهی به همان ارز ثبت می‌شود، نه معادل ریالی |
|
||
|
||
> ✅ **انجام شد (۲۰۲۶-۱۰-۰۳):** تغییر نرخ ارز فقط از منوی «نرخ ارز» (تاریخچه + گردش تأیید + به‌روزرسانی از API) انجام می‌شود. فیلدهای مستقیم نرخ در «تنظیمات سیستم» حذف و به نمایش فقط‌خواندنی تبدیل شدند.
|
||
|
||
## ۱۲.۳ اپلیکیشن
|
||
|
||
| مورد | وضعیت |
|
||
|------|--------|
|
||
| بازبینی فلوی قدیمی سفارش | ✅ ۲۰۲۶-۱۰-۳۱ — باگ P0 کد تخفیف کشف و برطرف شد؛ ۳۳ تست پاس (۱۰۱ assertion) شامل ثبت سفارش با تخفیف |
|
||
| مدیریت خطاها | ✅ ۲۰۲۶-۱۰-۳۱ — شکست مصرف کد تخفیف → ۴۲۲ با پیام واضح؛ Mock در Production → خطای صریح؛ مسیرهای حساس Log::error/critical |
|
||
| لاگ Production | ✅ ۲۰۲۶-۱۰-۳۱ — راهنمای `LOG_STACK=daily` + `LOG_LEVEL=warning` در `.env.example` و بخش ۴.۴ سند استقرار |
|
||
| پیکربندی Cache / OPcache | ✅ ۲۰۲۶-۱۰-۳۱ — راهنمای `config:cache` / `route:cache` / `view:cache` در سند استقرار؛ هک OPcache حذف شد |
|
||
| نسخه‌بندی Assetها | ✅ ۲۰۲۶-۱۰-۳۱ — `ifnex_asset_version()` مبتنی بر filemtime + ثابت `IFNEX_BRIDGE_VERSION` (۲.۱.۰) |
|
||
|
||
---
|
||
|
||
# ۱۳. تست پذیرش End-to-End
|
||
|
||
## ۱۳.۱ مشتری
|
||
|
||
- [ ] ثبت‌نام
|
||
- [ ] تأیید موبایل
|
||
- [ ] ورود
|
||
- [ ] ثبت سفارش Export
|
||
- [ ] ثبت سفارش Import
|
||
- [ ] مشاهدهٔ سفارش
|
||
- [ ] انتظار برای تأیید
|
||
- [ ] دریافت اسناد
|
||
- [ ] دانلود اسناد
|
||
- [ ] آپلود اسناد امضاشده
|
||
- [ ] دریافت تأیید
|
||
- [ ] پرداخت با کیف پول
|
||
- [ ] پرداخت آنلاین
|
||
- [ ] مشاهدهٔ موجودی
|
||
- [ ] مشاهدهٔ تراکنش‌ها
|
||
- [ ] مشاهدهٔ ترکینگ
|
||
- [ ] دریافت اعلان‌ها
|
||
|
||
## ۱۳.۲ کارمند
|
||
|
||
- [ ] مشاهدهٔ سفارش‌ها
|
||
- [ ] تأیید سفارش
|
||
- [ ] رد سفارش
|
||
- [ ] آپلود تعهدنامه
|
||
- [ ] بررسی اسناد مشتری
|
||
- [ ] تکمیل چک‌لیست
|
||
- [ ] به‌روزرسانی مرسوله
|
||
- [ ] ایمپورت ترکینگ
|
||
- [ ] مشاهدهٔ وضعیت مالی مشتری
|
||
- [ ] مشاهدهٔ سفارش‌های مشتری
|
||
- [ ] بازبینی Audit Log
|
||
|
||
## ۱۳.۳ مدیر / مدیر کل
|
||
|
||
- [ ] بازبینی مالی مشتری
|
||
- [ ] اعطای اعتبار
|
||
- [ ] ویرایش اعتبار
|
||
- [ ] بازبینی Audit
|
||
- [ ] مشاهدهٔ تایم‌لاین مرسوله
|
||
- [ ] ویرایش داده‌های عملیاتی
|
||
- [ ] بازبینی فعالیت کارمندان
|
||
|
||
---
|
||
|
||
# ۱۴. دروازهٔ نهایی تحویل
|
||
|
||
پیش از انتشار در Production:
|
||
|
||
- [ ] همهٔ قابلیت‌های الزامی پیاده‌سازی شده‌اند
|
||
- [ ] باگ‌های بحرانی برطرف شده‌اند
|
||
- [ ] بازبینی امنیتی انجام شده
|
||
- [ ] فلوی پرداخت تست شده
|
||
- [ ] فلوی کیف پول تست شده
|
||
- [ ] فلوی Export تست شده
|
||
- [ ] فلوی Import تست شده
|
||
- [ ] PDFها تأیید شده‌اند
|
||
- [ ] پیامک تست شده
|
||
- [ ] ایمپورت ترکینگ تست شده
|
||
- [ ] بکاپ بررسی شده
|
||
- [ ] محیط Production بررسی شده
|
||
- [ ] تست پذیرش کارفرما (UAT) انجام شده
|
||
|
||
---
|
||
|
||
# ۱۵. خلاصهٔ وضعیت تحویل
|
||
|
||
**وضعیت فعلی:** آماده برای دیپلوی (فاز ۳.۸، ۳.۸.۱ و ۳.۹ تکمیل شد)
|
||
|
||
**آخرین کامیت بازبینی‌شده:** ۲۰۲۶-۱۱-۰۱ — فاز ۳.۹ (دفترچه آدرس: مدل + مایگریشن، CRUD API با Sanctum، اتصال به ثبت سفارش، dropdown آدرس ذخیره‌شده + چک‌باکس ذخیره در فرم سفارش، تب دفترچه آدرس در پنل کاربری، ۴ پروکسی AJAX، ۱۸ تست جدید).
|
||
|
||
## ۱۵.۱ تکمیل‌شده در فاز ۳.۶ (۲۰۲۶-۱۰-۰۴)
|
||
|
||
- [x] فلوی پذیرش End-to-End (کیف پول + درگاه پس از تأیید تعهدنامه)
|
||
- [x] بازطراحی داشبورد و صفحهٔ Login (پنل Filament)
|
||
- [x] بازطراحی PDFهای AWB، Invoice و Label (dompdf، چیدمان جدولی، navy + amber)
|
||
- [x] صفحهٔ وضعیت مالی مشتری در پنل ادمین
|
||
- [x] سیستم اعتبار چندارزی (درخواست ۹) — تکمیل End-to-End
|
||
- [x] ویجت بدهی‌های ارزی تسویه‌نشده + badge ناوبری
|
||
- [x] اصلاح race condition در تسویهٔ اعتبار
|
||
- [x] `CreditsRelationManager` روی `UserResource`
|
||
- [x] Rate Limiting روی همهٔ endpointهای API (۶ لایه)
|
||
- [x] چک‌لیست خودکار کارمند پس از تأیید سفارش (درخواست ۵)
|
||
- [x] نمایش بدهی ارزی در پورتال مشتری وردپرس
|
||
- [x] استایل‌دهی صفحهٔ پروفایل مشتری در وردپرس
|
||
- [x] پاک‌سازی کد (حذف فایل‌های تستی، تأیید تمیزی کد)
|
||
|
||
## ۱۵.۲ تکمیل‌شده در فاز ۳.۷ (۲۰۲۶-۱۰-۳۰)
|
||
|
||
- [x] **سیستم ۴-رُبعی نرخ‌ها** (Export/Import × Doc/Parcel) با ایمپورت از اکسل
|
||
- [x] **معماری IRR-only** — ارز مبنا = ریال ایران، حذف جفت‌ارز و تبدیل در زمان ایمپورت
|
||
- [x] **ایمپورت فایل اصلی مشتری** + قالب جدید `IFNEX_Rate_Template.xlsx`
|
||
- [x] **حذف تمام «تومان» و «درهم» از نمایش قیمت‌های داخلی** در همه UIها
|
||
- [x] **فاکتورهای دستی مدیر** — صدور، پرداخت از کیف پول، اعلان خودکار
|
||
- [x] **تب «فاکتورهای دستی» در پورتال وردپرس** (لیست + جزئیات + پرداخت)
|
||
- [x] **اضافه شدن فاکتورها به وضعیت مالی و داشبورد مشتری**
|
||
- [x] **فرمت هزارگان** در فیلدهای عددی فرم فاکتور ادمین
|
||
- [x] آپدیت خط قرمزها برای معماری ارزی
|
||
|
||
## ۱۵.۳ تکمیل‌شده در فاز ۳.۸ (۲۰۲۶-۱۰-۳۱)
|
||
|
||
- [x] **Favicon حرفه‌ای IFNEX** — طراحی هواپیمای کاغذی کهربایی روی پس‌زمینهٔ سرمه‌ای (`favicon.ico` چندسایزی + `favicon.svg` وکتور + apple-touch-icon + icon-192/512 + `site.webmanifest`) + لینک‌ها در head پنل فیلمنت
|
||
- [x] **صفحهٔ `/` برندشده** — جایگزین welcome پیش‌فرض لاراول (RTL، وزیرمتن، کارت‌های پنل مدیریت / استعلام نرخ / ثبت سفارش)
|
||
- [x] **جمع‌شدن کارت لاگین فیلمنت** — عرض ۴۴۰←۳۸۰px، padding و فاصله‌های فشرده‌تر، موبایل-فرندلی
|
||
- [x] **SweetAlert2 برای خطاهای فرم سفارش وردپرس** — باندل محلی (بدون CDN)، پاپ‌آپ مرکزی برای خطاهای اعتبارسنجی/ثبت/ارتباط با fallback به alert
|
||
|
||
## ۱۵.۴ تکمیل‌شده در فاز ۳.۸.۱ — سخت‌سازی Production (۲۰۲۶-۱۰-۳۱)
|
||
|
||
- [x] **باگ P0 کد تخفیف** — متد `consumeDiscountCode()` صدا زده می‌شد ولی وجود نداشت (ثبت سفارش شکسته بود)؛ سرویس `DiscountCodeService` + جدول `discount_code_usages` (Audit + Idempotency + قفل رقابتی) پیاده‌سازی شد
|
||
- [x] **گارد Mock Gateway در Production** — پردازش با درگاه تستی در Production مسدود می‌شود
|
||
- [x] **حذف هک‌های دیباگ** از ۵ فایل پلاگین وردپرس (opcache_reset / header / cache-buster)
|
||
- [x] **نسخه‌بندی سالم assetها** — filemtime + ثابت نسخه به‌جای `time()`
|
||
- [x] **سخت‌سازی آپلود** — بررسی mimetype واقعی فایل
|
||
- [x] **خروج `wp-config.php` از گیت** (saltها لو‌رفته فرض می‌شوند — چرخش در چک‌لیست استقرار)
|
||
- [x] **تعمیر ۷ تست شکسته + ۹ تست جدید** — ۳۳ تست پاس، ۱۰۱ assertion
|
||
- [x] **چک‌لیست امنیتی استقرار** در `DEPLOYMENT_HANDOFF.md` (بخش ۴.۴)
|
||
|
||
## ۱۵.۵ تکمیل‌شده در فاز ۳.۹ — دفترچه آدرس (۲۰۲۶-۱۱-۰۱)
|
||
|
||
- [x] **مدل + جدول `address_book_entries`** — نقش sender/receiver، فیلدهای عیناً مطابق ستون‌های sender_/receiver_ در shipments، آدرس پیش‌فرض، شمارندهٔ استفاده + آخرین استفاده، سقف ۵۰ رکورد برای هر کاربر
|
||
- [x] **CRUD API محافظت‌شده با Sanctum** — `GET/POST/PUT/DELETE /api/v1/addresses` + `POST /addresses/{id}/default`؛ بررسی مالکیت در همهٔ اکشن‌ها؛ فیلتر بر اساس نقش و جستجو؛ جلوگیری از رکورد تکراری (نقش + تلفن + آدرس → بروزرسانی)
|
||
- [x] **اتصال به ثبت سفارش** — چک‌باکس «ذخیره این آدرس» برای هر دو نقش (upsert بدون رکورد تکراری) + ثبت استفاده از آدرس انتخاب‌شده؛ عملیات دفترچه هرگز ثبت سفارش را ناموفق نمی‌کند
|
||
- [x] **فرم سفارش وردپرس** — dropdown «آدرس‌های ذخیره‌شده» بالای هر دو بخش فرستنده/گیرنده (پر شدن یک‌کلیکی تمام فیلدها) + چک‌باکس ذخیره؛ در نبود آدرس ذخیره‌شده کاملاً مخفی است
|
||
- [x] **تب «دفترچه آدرس» در پنل کاربری** — کارت‌های آدرس با فیلتر (همه/فرستنده/گیرنده)، فرم افزودن/ویرایش، حذف با تأیید SweetAlert، تنظیم پیش‌فرض، حالت خالی راهنما، موبایل-فرندلی
|
||
- [x] **۴ پروکسی AJAX امن** (get/save/delete/set-default) — nonce + sanitize + توکن Sanctum کاربر در سمت لاراول
|
||
- [x] **۱۸ تست Feature جدید** — مالکیت، سقف، تکراری، پیش‌فرض، فیلترها و رفتار مدل
|
||
|
||
## ۱۵.۶ باقی‌مانده
|
||
|
||
- [ ] i18n (موکول به زمان دیپلوی)
|
||
- [ ] تست نهایی UAT کارفرما
|
||
- [ ] دیپلوی روی سرور Production (با چرخش کلیدها طبق بخش ۴.۴ سند استقرار) — **قدم بعدی**
|
||
- [ ] سند پیشنهادی سیستم مالی (درخواست ۱۳ کارفرما — موکول به آینده)
|
||
- [ ] پلاگین SMS (منتظر تحویل پنل SMS مشتری)
|
||
|
||
### باقی‌مانده برای نسخه Pro (آینده)
|
||
|
||
- [ ] ارز مرجع قابل تنظیم (IRR/EUR/USD/AED) — `01_Documents/IFNEX_Pro_Backlog.md`
|
||
- [ ] سیستم لایسنس با Domain Lock + Feature Flags
|
||
- [ ] بروزرسانی خودکار از گیت
|
||
|
||
---
|
||
|
||
> **نکتهٔ نگهداری:** این فایل باید در طول تحویل پروژه به‌روزرسانی شود. این فایل فقط برای وضعیت تحویل مشتری است و نباید به مستندات معماری یا Roadmap محصول تبدیل شود.
|