حذف دور

reassignTo يسافر كمعامل استعلام لا داخل جسم الطلب. فجسم على DELETE قانوني وغير مدعوم على نطاق واسع (عدة أزمنة تشغيل تُسقطه وكذلك عدد من الوسطاء)، وreassignTo المُسقَط لا يمكن تمييزه عن واحد لم يُرسَل قط، وهي بالضبط الحالة التي ترفضها هذه النقطة بدل أن تخمّنها.

يصير مطلوبًا لحظة أن يحمل أحدٌ الدور: فبدونه تحصل على role_in_use، وهو 409، يحمل param: "reassignTo"، وهو الحل الفعلي. والعمود تحته ON DELETE RESTRICT، فلا يوجد مسار يغيّر فيه حذف دور بصمت ما يستطيع شخص فعله.

مفاتيح API تُعاد توجيهها بدل أن تُيتَّم، وهذا هو النصف الدقيق. فالمفتاح الذي اختفى دوره كان سيسقط إلى سقف NULL، والسقف الفارغ أوسع من الدور الذي اختفى للتو، فحذف دور مقيِّد كان سيرقّي بصمت كل مفتاح كان يقيّده.

العددان منفصلان لأنهما شيئان مختلفان يجب فحصهما: reassigned هم أشخاص، وسيلاحظون، وkeysReassigned هي برامج، ولن تلاحظ.

دور المالك لا يمكن حذفه (role_undeletable، وهو 409) لأنه يسمّي الحساب الذي تُبنى عليه مساحة العمل لا وظيفة يؤديها أحد. أما كل دور آخر فيمكن أن يذهب، سواء الأدوار المزروعة Admin وMember وViewer وDeveloper وBilling أو دور كتبه أحدهم: فهي نقطة بداية، ومساحة عمل بلا تكاملات لا حاجة لها بصف Developer غير مسموح لها بالتخلص منه. افحص deletable قبل عرض الزر؛ المالك وحده يجيب بـ false.

حذف دور مزروع ليس نهائيًا، فلا تصغ الحوار وكأنه كذلك. GET /roles يعيد زرع أي صف قالب ناقص، والحذف لا يترك شاهدة، فقراءة القائمة التالية تُعيد Developer تحت id جديد. إعادة تسميته هي ما يجعله يكف عن العودة (فالصف المُعاد تسميته يحتفظ بـ builtin ويظل يتعارض مع الزرع)، أو أن يأخذ دور آخر الاسم، لأن الزارع يتخطى صفًا اسمه محجوز.