# حالة إصلاح مشروع رسيل

تاريخ التسليم: 2026-10-04. التعديلات محلية؛ لم أُنشئ commit ولم أرفع شيئًا إلى GitHub.

## الدخول وإدارة الشركات

- تم إنشاء الحساب `mbkyr0161@gmail.com` في قاعدة المشروع المحلية، بصلاحية `platform_admin` داخل مساحة مستقلة لإدارة المنصة.
- بيانات الدخول محفوظة في `storage/app/private/platform-admin-access.txt` بصلاحية قراءة للمالك فقط، والملف مستثنى من Git. لا تنسخ محتواه إلى مستودع أو تقرير.
- بعد تسجيل الدخول، يجب تغيير كلمة المرور المؤقتة. يفرض الخادم هذا الشرط على واجهات الإدارة والعمل، ويسمح بالاطلاع على الحساب وتغيير كلمة المرور والخروج.
- إدارة الشركات من القائمة **إدارة الشركات**، أو المسار `/dashboard/companies` على عنوان واجهتك الحالية. تدعم عرض الشركات ومالكيها وعدد المستخدمين وتعليق الشركات وتفعيلها، وتمنع تعليق الشركة المرتبطة بحساب المدير نفسه.
- تم اختبار دخول الحساب الحقيقي محليًا: الدخول 200، منع إدارة الشركات قبل تغيير كلمة المرور 403، والخروج 204. لم أغيّر كلمة المرور المؤقتة نيابةً عنك.

## ما أُصلح في هذه المتابعة

| المجال | النتيجة |
| --- | --- |
| إنشاء المستخدمين | أزيلت كلمة المرور الافتراضية المشتركة؛ أصبح إدخال كلمة مرور مؤقتة مطلوبًا، مع إلزام المستخدم الجديد بتغييرها. |
| تغيير كلمة المرور | أضيف حقل مستقل في قاعدة البيانات، وحماية على الخادم، وإرجاع حالته ضمن بيانات تسجيل الدخول. تغييرها يلغي جلسات المستخدم الأخرى، وإعادة التعيين تزيل شرط الكلمة المؤقتة. |
| الإرسال والتحصيل | فُصل تحصيل BSP في مهمة مستقلة قابلة لإعادة المحاولة؛ فشل التحصيل أو المعالجة اللاحقة لا يحوّل رسالة مسجلة كمرسلة إلى رسالة قابلة للإرسال مجددًا. |
| الخصم | حماية الخصم من التكرار لكل رسالة، وتحديد محفظة الشركة من الرسالة، وتنفيذ الخصم وتسجيل التكلفة في معاملة واحدة، وقفل صف المحفظة عند تعديل الرصيد. |
| تعرفة BSP | تصحيح شروط صلاحية التعرفة حتى لا تُختار تعرفة لنوع مختلف أو بتاريخ مستقبلي، وضبط حساب الفرق، ومعالجة تعارض تحديث التعرفة في الثانية نفسها. |
| قوالب BSP | تصحيح البحث بمعرف المزود دون تمريره إلى حقل UUID، وتقييد المزامنة بحساب WABA وسياق الشركة عند وجوده، والتحقق من المتغيرات غير السليمة. |
| أخطاء BSP | الاحتفاظ برمز خطأ المزود الرقمي، وتحويل فئة حد الإرسال إلى قيمة عددية عند تحديث الجودة. |
| العمليات المالية غير الموثقة | بقي شحن المحفظة وترقية الاشتراك وإعادة تفعيله متوقفًا. أُغلق أيضًا مسار تعيين الباقة الإداري الذي أُضيف لاحقًا وكان يتجاوز هذا المنع، وعُطّل زرّه في الواجهة. |
| التشغيل المحلي | أُصلحت صلاحيات وصول مستخدم PHP داخل Docker إلى `storage` و`bootstrap/cache` باستخدام ACL مع إبقاء ملكية الملفات الحالية؛ كانت تمنع تسجيل الدخول بخطأ 500. |
| الاختبارات | تصحيح بيانات اختبارات BSP لتطابق العلاقات والمعرفات الفعلية، وتحديث اختبارات إنشاء المستخدمين لتطابق الإنشاء المباشر، وإضافة اختبارات عدم تكرار الخصم والإرسال وفرض تغيير كلمة المرور. |

## الإصلاحات السابقة الموجودة في النسخة الحالية

تتضمن النسخة صلاحية إدارة منصة منفصلة عن مالك الشركة، وضوابط عزل الشركات والرسائل، وحصص إرسال الاشتراك، والتعامل مع رفض المزود، ومعالجة أحداث WhatsApp الموقعة والتكرار، ومتابعة الحملات، واستعادة كلمة المرور، وتقييد مفاتيح API، وسجل التدقيق وتنزيل تقارير CSV.

وفق موافقتك، بيانات أحداث الرسائل المرسلة إلى Webhooks الشركات تقتصر على **`id` و`status`**. اختبار هذا الشرط ضمن الاختبارات الناجحة. لم تُرسل رسائل أو Webhooks فعلية إلى جهات خارجية أثناء التحقق.

## نتائج التحقق

- **626 اختبارًا ناجحًا، و1798 تحققًا** على PostgreSQL معزول؛ لا تستخدم اختبارات التهيئة قاعدة بيانات المشروع الفعلية.
- نجاح بناء الواجهة النهائي باستخدام Next.js وWebpack داخل نسخة مؤقتة منفصلة. ونجح بناء الواجهة المعتاد قبل تعديلات نماذج هذه المتابعة.
- نجاح فحص TypeScript، وتنسيق PHP، و`git diff --check`.
- تحقق متصفح فعلي بحساب تجريبي: تسجيل الدخول ← تغيير كلمة المرور ← عرض الشركات ← تعليق شركة اختبار ← إعادة تفعيلها. لم يظهر خطأ JavaScript أو واجهة خطأ في هذا المسار.
- أُوقفت خوادم الاختبار المؤقتة والمتصفح بعد التحقق؛ لم أوقف خادم الواجهة الذي كان يعمل مسبقًا.
- طُبقت محليًا مهاجرة `2026_10_03_110000_add_password_change_requirement_to_users.php`. تحتاج أي بيئة أخرى هذه المهاجرة قبل تشغيل الشيفرة الجديدة.

## ما لا يزال غير مكتمل أو غير متحقق

هذه النتائج تثبت المسارات المذكورة، ولا تعني اكتمال كل ميزات المشروع أو جاهزيته للإنتاج:

- لا توجد دورة مصادقة ثنائية مكتملة؛ وجود حقل `two_factor_enabled` وحده لا يحقق ذلك.
- تصدير التقارير يدعم CSV؛ دعم XLSX وPDF غير مكتمل.
- لم تُنفّذ اختبارات إرسال فعلية مع مزودي WhatsApp أو SMS أو البريد. استقبال Webhooks غير WhatsApp، وصلاحية أرقام BSP وحساباتها لدى المزود، تحتاج استكمالًا وتحققًا خاصًا بكل مزود.
- فوترة BSP الحالية ليست إثبات تحصيل من مزود دفع. ما زالت مراجعة فئات الرسائل والتعرفة التاريخية ودقة كسور العملة والحجز المالي عند الإرسال المتزامن مطلوبة قبل اعتمادها تجاريًا؛ إصلاح منع التكرار لا يحل هذه المسائل وحده.
- تحصيل المدفوعات وشحن الرصيد وتفعيل الباقات المدفوعة متوقفة عمدًا حتى ربط دفع موثق.
- لم تُنفّذ اختبارات حمل أو تعافٍ من الأعطال أو قبول إنتاجي شامل. إصلاح ACL محلي؛ يحتاج أي تثبيت جديد تجهيز صلاحيات التخزين المناسبة.

## متابعة تكرار طلب تغيير كلمة المرور

أُصلح تعارض قديم في `auth/login` و`auth/me` كان يعيد طلب تغيير كلمة المرور رغم اكتمال تغييرها. أصبحت الاستجابة تعتمد على حالة `must_change_password` المحفوظة، المتوافقة مع حماية الخادم. لم تُعدّل كلمة مرور الحساب أثناء الإصلاح. نجح اختبار الدخول المتكرر بعد التغيير، ونجحت مجموعة المصادقة المرتبطة: 24 اختبارًا و93 تحققًا. بيانات الحساب المحلي الآن تعيد `must_change_password: false`.

## موافقة مالك المنصة على الشركات الجديدة

أصبح التسجيل الجديد ينشئ الشركة بحالة `pending`، ويعرض لصاحبها صفحة `/pending-approval` برسالة ترحيب وانتظار التفعيل فقط، مع خيار تسجيل الخروج. تسجيل الدخول لاحقًا قبل الموافقة يعيده إلى الصفحة نفسها.

من **إدارة الشركات** تظهر الشركات المنتظرة أولًا، بحالة **بانتظار التفعيل** وزر **تفعيل**. يستطيع مدير المنصة وحده تفعيلها. تبدأ الفترة التجريبية للخطة الافتراضية عند الموافقة، ولا تُستهلك أثناء الانتظار، ولا تتكرر عند الضغط على التفعيل مجددًا.

يحجب الخادم واجهات النظام عن الشركة المنتظرة، بما فيها القنوات والإشعارات والبيانات والإدارة، ويسمح فقط بقراءة حالة حسابها والخروج. مفاتيح API لا تتجاوز المنع. تتحقق لوحة الواجهة من الحالة لدى الخادم قبل عرض محتواها، وتعيد الروابط المباشرة إلى صفحة الانتظار. صفحة الانتظار تتحقق من التفعيل كل 15 ثانية وعند العودة إليها، ثم تنقل الشركة إلى النظام بعد الموافقة.

لم تتغير حالات الشركات الموجودة سابقًا؛ القاعدة الجديدة تخص التسجيلات الجديدة. لا يتطلب هذا التغيير مهاجرة جديدة، لأن حقل الحالة الحالي نصي ويدعم القيمة الجديدة.

التحقق: **632 اختبارًا ناجحًا، و1888 تحققًا**. تحقق متصفح بحسابي شركة ومدير منفصلين: التسجيل والرسالة الترحيبية، رفض طلب جهات الاتصال بحالة 403 قبل الموافقة، منع تجاوز الانتظار بتغيير الحالة المخزنة بالمتصفح، التفعيل من شاشة إدارة الشركات، الانتقال التلقائي إلى لوحة النظام، ونجاح الطلب نفسه بحالة 200 بعد الموافقة. فحص TypeScript ناجح. فحص ESLint للملفات المتأثرة بلا أخطاء، مع تحذير سابق واحد عن التنقل داخل معالج أخطاء API.

نجح بناء الواجهة النهائي بما فيه مسار `/pending-approval`، وأُغلقت بيئة الاختبار المعزولة بعد انتهاء التحقق. لم أُنشئ commit أو أرفع التعديلات إلى GitHub.

## تعليق أقسام هذه النسخة دون حذف

الأقسام الموقوفة مؤقتًا: **الأتمتة، الدعم، الإعدادات، المحفظة، التحليلات، مفاتيح API، وWebhooks الصادرة للشركات**.

- إعداد التفعيل المركزي هو `config/release.php`. قيمة `false` تعني أن القسم متوقف، و`true` تعيد تفعيله. تعرض استجابة الحساب `disabled_modules` حتى تستخدم الواجهة إعداد الخادم نفسه.
- بقيت ملفات الأقسام ومساراتها وبياناتها محفوظة. تُخفى روابطها من القائمة والاختصارات، ويعرض الدخول المباشر رسالة توقف دون تحميل محتوى القسم أو طلب بياناته.
- طلبات API لهذه الأقسام تعيد `503` مع الرمز `module_temporarily_disabled`، بما فيها الطلبات من مدير المنصة. يشمل إيقاف مفاتيح API الوصول البرمجي عبر `/api/v1`.
- لا تبدأ الأتمتة ولا تنفذ إجراءاتها أثناء التوقف. لا تُرسل Webhooks الصادرة للشركات. استقبال Webhooks مزودي القنوات مستمر لأنه جزء من استقبال الرسائل وتتبع حالتها.
- لا تحذف حواجز الإيقاف إعدادات الأتمتة أو Webhooks ولا سجلات التسليم الموجودة. الأحداث أثناء فترة التوقف لا تُعاد تلقائيًا بعد التفعيل؛ يمكن إعادة محاولة سجلات تسليم Webhooks المعلقة من واجهتها بعد إعادة التفعيل.
- تعليق شاشة المحفظة وواجهاتها لا يغيّر الأرصدة ولا يوقف التحقق الداخلي من الرصيد المستخدم في إرسال الرسائل. تظل الإعدادات الداخلية اللازمة للتسجيل والقنوات مقروءة للخدمات.

لإعادة قسم: غيّر قيمته إلى `true` في `config/release.php`، ثم امسح كاش الإعدادات إن كان مستخدمًا (`php artisan config:clear`) وأعد تشغيل عمال الطابور (`php artisan queue:restart`) وحدّث الصفحة. لا تحتاج إعادة إنشاء البيانات.

التحقق: **637 اختبارًا ناجحًا، و1972 تحققًا**. تختبر المجموعة العامة الأقسام في وضع التشغيل للحفاظ على تغطية كودها، بينما تستعيد `PausedModulesTest` إعدادات النسخة الفعلية وتختبر الإيقاف وإعادة التفعيل وحفظ البيانات وعدم حجب استقبال رسائل المزود. فحص TypeScript ناجح، وESLint بلا أخطاء مع تحذير سابق عن استيراد غير مستخدم في صفحة التقارير. في المتصفح اختفت الروابط السبعة، وأظهر الرابط المباشر للمحفظة رسالة التوقف دون إرسال طلب بيانات المحفظة.

نجح بناء الواجهة بعد تعليق الأقسام، وأُوقفت خوادم وقاعدة الاختبار المعزولة. لم تُرفع أي تعديلات إلى GitHub.