كيفية إصلاح CANT_DISABLE_LAST_ADMIN في عمليات نشر Salesforce

يمنع Salesforce إلغاء تفعيل أو تجميد آخر مستخدم نشط يملك صلاحيات System Administrator، لتجنب إغلاق الوصول إلى المؤسسة.

يظهر أثناء: عمليات DML وقت التشغيل لإدارة المستخدمين، وليس أثناء نشر ميتاداتا

المعنى

يظهر خطأ CANT_DISABLE_LAST_ADMIN عندما تحاول عملية إلغاء تفعيل أو تجميد أو إزالة صلاحيات المسؤول من آخر مستخدم نشط يملكها. يفرض Salesforce هذا كإجراء وقائي: لا يمكن استرداد مؤسسة بلا مسؤولين نشطين عبر الواجهة، لذا يرفض النظام التغيير تمامًا بدلاً من السماح بحدوثه عن طريق الخطأ.

ينطبق هذا على أي مستخدم يحمل ما يعادل صلاحيات System Administrator، وليس فقط الملف الشخصي الذي يحمل هذا الاسم حرفيًا، لذا فإن ملفًا شخصيًا مخصصًا أو مجموعة صلاحيات تمنح "Modify All Data" مع "Manage Users" يمكن أن تفعّل نفس الحماية.

التشخيص

الأسباب الشائعة

إلغاء التزويد الجماعي يعطّل حسابات المسؤولين دون التحقق من العدد

يقوم سكربت إنهاء الخدمة بإلغاء تفعيل مجموعة من المستخدمين، بمن فيهم المسؤولون، دون التحقق من عدد المسؤولين النشطين المتبقين بعد ذلك.

يتم إلغاء تفعيل المسؤول القديم قبل أن يصبح الجديد نشطًا بالكامل

تقوم عملية تسليم المهام بتعطيل وصول المسؤول المغادر قبل تأكيد تفعيل حساب وصلاحيات المسؤول البديل.

تغييرات مجموعات الصلاحيات تزيل الوصول المكافئ للمسؤول على مستوى المؤسسة بأكملها

يقوم نشر ما بتحديث تخصيصات مجموعات الصلاحيات بطريقة تزيل "Modify All Data" من كل مستخدم نشط متبقٍ دفعة واحدة.

الحل

تأكد من وجود مسؤول نشط آخر قبل إلغاء تفعيل أحدهم
تحقق من عدد المستخدمين النشطين الذين يملكون صلاحيات System Administrator أو ما يعادلها قبل تنفيذ أي خطوة إلغاء تزويد.
```
SELECT COUNT(Id) FROM User
WHERE IsActive = true AND Profile.PermissionsModifyAllData = true
```
فعّل المسؤول البديل أولاً
رتّب عملية إنهاء الخدمة بحيث يتم تأكيد عمل حساب وصلاحيات المسؤول الجديد قبل تعطيل القديم.
أضف فحصًا لعدد المسؤولين إلى سكربتات ما قبل النشر أو ما قبل إلغاء التزويد
أدرج إجراءً وقائيًا داخل الأتمتة نفسها بحيث لا يمكنها تقديم تغيير من شأنه ترك المؤسسة بلا مسؤولين نشطين.

من واقع الاستخدام

إزاي Serpent بتمنع ده

يرتبط الوصول إلى المؤسسات في Serpent بسجل المهام والنشر، بحيث يفشل سكربت إلغاء التزويد الذي قد يترك مؤسسة بلا مسؤول نشط بشكل واضح بدلاً من إغلاق sandbox أو scratch org بصمت. راجع مكتبة أخطاء نشر Salesforce.

الوقاية

احتفظ بمسؤولَين نشطَين على الأقل في كل مؤسسة في جميع الأوقات

تعامل مع المؤسسة ذات المسؤول الواحد كحادثة في انتظار الحدوث؛ حساب مسؤول نشط ثانٍ هو أرخص تأمين ضد هذا الخطأ وضد الإغلاق عمومًا.

أتمتة إنهاء الخدمة كخطوات مرتبة، وليس كدفعة واحدة

افصل بين "منح المسؤول الجديد" و"سحب صلاحيات المسؤول القديم" إلى خطوات متسلسلة منفصلة مع بوابة تحقق بينهما.

راجع عمليات نشر مجموعات الصلاحيات بحثًا عن تغييرات وصول على مستوى المؤسسة

ضع علامة على أي نشر يمسّ Modify All Data أو Manage Users لعدة مستخدمين دفعة واحدة ليخضع لمراجعة يدوية قبل تنفيذه.

أسئلة شائعة

أسئلة شائعة حول CANT_DISABLE_LAST_ADMIN

هل يمنع هذا أيضًا تجميد حساب المسؤول، وليس فقط إلغاء تفعيله؟

نعم. تنطبق نفس الحماية على تجميد آخر مسؤول نشط، لأن المستخدم المجمّد أيضًا لا يمكنه تسجيل الدخول.

هل يهم الملف الشخصي الذي يستخدمه المسؤول، أم مستوى الصلاحيات فقط؟

مستوى الصلاحيات هو ما يهم. أي مستخدم نشط يمنحه ملفه الشخصي أو مجموعات صلاحياته وصولًا مكافئًا للمسؤول، وأبرزه Modify All Data، يُحتسب ضمن الحد الأدنى، بغض النظر عن اسم الملف الشخصي.

ماذا لو كنت بحاجة فعليًا إلى إزالة المسؤول الوحيد، مثلًا عند إيقاف مؤسسة نهائيًا؟

ألغِ تفعيل جميع المستخدمين الآخرين أولاً واترك المسؤول نشطًا حتى النهاية، أو تواصل مع دعم Salesforce إذا كانت المؤسسة نفسها ستُوقف بالكامل.

ابدأ مجانًا. بدون بطاقة ائتمان، وبدون تثبيت، وبدون التزام.

الإعداد في أقل من 15 دقيقة. لا حاجة لتوظيف مختص DevOps.

ابدأ مجانًا احجز عرضًا توضيحيًا