تفتح بطاقة عميل وتضغط حفظ دون تغيير البريد، فيرفض النظام القيمة لأنها موجودة بالفعل. استثناء السجل الجاري تعديله يحل هذه الحالة، لكن يصبح مصدر معرّف الاستثناء جزءًا مهمًا من التصميم. لا ينبغي أن يسمح نموذج الواجهة للمستخدم باختيار السجل الذي تتجاهله قاعدة التفرد.
اربط الاستثناء بسجل حمّله الخادم
توضح وثائق Laravel 12 لقاعدة unique إمكانية تمرير نموذج إلى ignore أو استخدام معرّف مولد من النظام. وتحذر صراحة من تمرير مدخل يتحكم فيه المستخدم إلى هذه الدالة. افحص التنفيذ في إصدار مشروعك، ولا تعتبر حقلًا مخفيًا في HTML مصدرًا موثوقًا.
في مثال افتراضي لنظام مبيعات، يستقبل المسار رقم العميل، ثم يحمّل الخادم السجل المسموح للمستخدم بتعديله. هذا السجل هو مرجع الاستثناء. وجود رقم آخر في جسم الطلب لا ينبغي أن يغير هوية العميل المستهدف أو يوسّع نطاق التعديل.
اختبار من أربع طلبات
- البريد الحالي نفسه: يُسمح بالحفظ إذا اجتازت بقية القواعد.
- بريد عميل آخر: يظهر تعارض مفهوم ولا تتغير البيانات.
- إضافة معرّف استثناء مختلف يدويًا: لا تتبدل هوية السجل المحمل.
- طلب تعديل سجل خارج الصلاحيات: يُرفض قبل أي كتابة، حتى لو كان البريد متاحًا.
التفرد ونطاق المؤسسة قراران منفصلان
حدد هل البريد فريد في النظام كله أم داخل مؤسسة واحدة. في الخيار الثاني، راجع أن شرط المؤسسة يأتي من سياق موثوق وأن تصميم قاعدة البيانات يوافق السياسة. استثناء السجل الحالي لا يثبت التفويض، واختبار مرور النموذج لا يغطي مسارات الاستيراد أو التعديل الجماعي.
أضف تجربة طلبين متزامنين لقيمة جديدة في قاعدة اختبار. قاعدة تحقق الطلب قد تمر قبل وصول الكتابة المنافسة؛ راجع قيد قاعدة البيانات ومعالجة التعارض بدل عرض خطأ داخلي للمستخدم.
ما دليل التسليم؟
ضمن تطوير CRM احفظ مصفوفة القبول وسجلات قبل وبعد بعناوين مصطنعة. وتفحص المراجعة التقنية مصدر المعرّف ونطاق المؤسسة ورسالة التعارض. المطلوب إثبات أن الاستثناء محدود بالسجل المصرح به، وليس مجرد اختفاء رسالة البريد المكرر.
صورة توضيحية أصلية لشرح الفكرة، وليست لقطة نظام عميل أو نتيجة قياس فعلية.
