إدارة البروفايلات والـ permission sets في التحكم بالإصدارات

الإجابة باختصار: حطّ الـ permission sets في نظام التحكم في الإصدارات كمصدر الحقيقة الفعلي، وفكّكها لملفات أصغر علشان اتنين يعدّلوا من غير تعارض دمج، وخلّي البروفايلات خفيفة، واتعامل مع أي نشر بروفايل على إنه تغطية فوق الموجود مش استبدال كامل. وبعدين بطّل تتبّع الحاجات المرتبطة بالبيئة عن قصد، لأن أغلب ضجيج البروفايلات في المستودع محدش بيقراه.

ليه البروفايلات صعبة في Git؟

في سلوكين موثّقين بيخلّوا البروفايل مختلف عن أي ملف تاني في المستودع.

• الاسترجاع بيعتمد على السياق. ملف الـ .profile الراجع بيشيل إعدادات الأمان الخاصة بأنواع الميتاداتا التانية المذكورة في نفس الطلب بس. اطلب البروفايل لوحده هتلاقي شبه فاضي؛ اطلبه مع 40 كائن هتلاقي ملف مختلف تمامًا (توثيق Metadata API).
• النشر بيتغطّى فوق الموجود. الصلاحيات اللي مش في الملف مش بتتشال من الـ org الهدف، وتعطيل صلاحية بيحتاج تكتب القيمة false صراحة في الـ XML. السطر الناقص معناه "مفيش رأي"، مش "مقفول".

اجمع الاتنين هتلاقي نفس البروفايل بيطلّع diff مختلف حسب مين اللي استرجعه وإيه اللي كان معاه في الحزمة. علشان كده diff البروفايلات هو أكتر ملف بيتخانقوا عليه وأقلهم ثقة في أغلب مستودعات سيلزفورس.

إيه اللي اتغيّر في 2026، وهل بيغيّر الاستراتيجية؟

سيلزفورس كانت أعلنت إن الصلاحيات جوه البروفايلات هتتوقف ابتداءً من Spring '26. وفي 6 يونيو 2026 اتلغى التطبيق ده، بسبب ملاحظات العملاء وفجوات في المميزات، مع استمرار سيلزفورس في التوصية بنموذج أمان بيقوده الـ permission sets (مساعدة سيلزفورس).

القراية العملية: الموعد النهائي راح، لكن الاتجاه فاضل. البروفايلات لسه مدعومة، فمحدش محتاج يهاجر بسرعة، لكن لو بتقرر تستثمر انضباطك في التحكم في الإصدارات فين، استثمره في الـ permission sets. هي إضافية، وبتتفكك، وبتتدمج.

إزاي تفكّك الـ permission sets علشان تبطل تتعارض؟

الـ permission set لما بيترجع بيبقى ملف XML كبير فيه كل صلاحيات الكائنات والحقول والمستخدمين. اتنين أدمن بيلمسوا حقلين مالهمش علاقة ببعض بيصطدموا في نفس الملف. سيلزفورس بتقدّم حل في الـ CLI: خيارات سلوك المصدر اللي بتقسّم الملف لملف لكل مجموعة صلاحيات (دليل مطوّري Salesforce DX).

1. اعمل commit لكل حاجة الأول. العملية بتعيد كتابة ملفات على الديسك، فابدأ من شجرة نضيفة.
2. شغّلها تجربة: sf project convert source-behavior --behavior decomposePermissionSetBeta2 --dry-run.
3. شغّلها فعليًا. ملف sfdx-project.json بيتحدّث علشان السلوك يفضل ثابت للكل، والسورس الحالي بيتحوّل في مكانه.
4. اعمل commit للتحويل في فرع لوحده من غير أي تغيير وظيفي معاه. محدش يقدر يراجع diff بيخلط تحويل صيغة بتعديلات حقيقية.

نفس الآلية بتغطي الـ custom labels والـ workflows وقواعد المشاركة وتسجيلات الخدمات الخارجية. خد بالك من الفجوة: البروفايلات مش موجودة في قايمة الأنواع القابلة للتفكيك. الكائنات وترجماتها بتتفكك افتراضيًا، والباقي بيتا اختيارية، والبروفايل فاضل ملف واحد.

إيه اللي المفروض تبطّل تتبّعه؟

نص الوجع ده إنت السبب فيه. الحاجات دي مكانها بره المستودع، أو ورا استثناء مقصود.

• صلاحيات الحزم المُدارة. صلاحيات الكائنات والحقول اللي ليها namespace بتظهر وتختفي مع إصدارات الحزم في كل org. تتبّعها بيضمنلك diffs وهمية دايمة.
• نطاقات IP وساعات الدخول. دي غالبًا سياسة بيئة مش محتوى إصدار، وبتختلف بشكل مشروع بين الساندبوكس والإنتاج.
• تعيينات الـ permission sets. دي سجلات مش ميتاداتا. مين واخد أنهي مجموعة دي بيانات، ومكانها خطوة تجهيز بيانات مش Git.
• صلاحيات الكائنات القياسية اللي عمرك ما هتغيّرها. لو عمليتك مش بتديرها، استرجاعها بيزوّد حجم الـ diff بس.
• البروفايلات اللي مش بتنشرها. أغلب الـ orgs فيها بروفايلات موروثة محدش لمسها من سنين. تتبّع اللي خط النشر بيرقّيه فعلًا.

اكتب الاستثناءات دي كقاعدة جوه المستودع، مش كمعرفة شفهية في تاريخ أوامر حد واحد. القاعدة اللي عايشة في alias بتاع حد بتتكسر أول ما زميل جديد يعمل retrieve.

إزاي تنقل الصلاحيات من البروفايلات للـ permission sets بأمان؟

1. اختار بروفايل واحد واعمل جرد لللي بيديه فعلًا في الإنتاج، مش في الساندبوكس اللي بعدت.
2. اعمل permission sets حسب المهمة مش حسب المسمى الوظيفي. المجموعات المبنية على مهام بتتعاد استخدامها، واللي مبنية على مسميات بتتكرر مع كل مسمى جديد.
3. عيّن المجموعات الجديدة جنب البروفايل من غير ما تغيّر حاجة تانية. الوصول إضافي، فمحدش هيخسر حاجة في المرحلة دي.
4. شيل الصلاحيات المنقولة من البروفايل في إصدار منفصل، بقيم false صريحة علشان النشر يقفلها فعلًا.
5. اتأكد بمستخدم على البروفايل ده في ساندبوكس، واحتفظ بنسخة الصلاحيات قبل التغيير لحد ما تتأكد.

متعملش الخطوة التالتة والرابعة في نفس الإصدار أبدًا. التغييرات الإضافية والتغييرات اللي بتشيل صلاحيات ليها قصص رجوع مختلفة تمامًا، وخلطهم هو السبب في إن حد يلاقي نفسه مقفول عليه صباح الاتنين. في أدلة هندسة إصدار تانية في مكتبة SF Guides بتاعتنا.

FAQ

مين مصدر الحقيقة: البروفايلات ولا الـ permission sets؟

الـ permission sets. هي إضافية، وبتتفكك لملفات قابلة للدمج، وسيلزفورس بتوصي بنموذج بيقودوه. سيب البروفايل للإعدادات الأساسية زي الترخيص وأنواع السجلات الافتراضية وتخطيطات الصفحات.

هل الصلاحيات جوه البروفايلات هتتلغي؟

لأ. الإيقاف اللي كان مخطط لـ Spring '26 اتلغى في 6 يونيو 2026. الهجرة بقت على مزاجك مش على موعد نهائي.

ليه الـ diff بتاع البروفايل بيتغيّر وأنا ملمستوش؟

لأن استرجاع البروفايل بيرجّع إعدادات الميتاداتا اللي في نفس الطلب بس. غيّر محتوى الحزمة يتغيّر الملف. صلّح ملف الاسترجاع، مش الملف نفسه.

ينفع نفكّك البروفايلات زي الـ permission sets؟

مش دلوقتي. خيارات سلوك المصدر بتغطي الـ permission sets والـ custom labels والـ workflows وقواعد المشاركة والخدمات الخارجية. البروفايل فاضل ملف واحد، وده سبب إضافي إنك تخليه خفيف.