اختبار Kandji وIru Assignment Maps: شرط واحد عام ممكن يغير إعدادات أجهزة أكثر مما تتوقع

جهاز Mac في قسم البيع، ومعالج Intel، والمفروض يحصل على إعداد خاص يجمع هذي الصفتين. تفتح Assignment Map وتلقى الشرط موجودًا، فتقول كل شيء مضبوط. لكن فوقه شرط أبسط يقول: «إذا القسم بيع». إذا طابقه الجهاز أولًا، هل يصل أصلًا إلى الشرط الأدق؟

هذا النوع من الأخطاء ما يحتاج ثغرة ويب حتى يغير حدود إدارة الأجهزة. يحتاج قراءة منطق التعيين، مصدر الخصائص، ومن يملك تعديلها. المقال يركز على Blueprints وAssignment Maps في Kandji، مع مراعاة الانتقال الحالي إلى Iru، ويستخدم عناصر مختبرية غير حساسة لتفسير الأثر. الصورة الرسمية المرفقة توضح فكرة أول تطابق داخل كتلة شرطية واحدة.

قبل المنطق: راجع الاسم والنشر الذي تختبره اليوم

وقت كتابة المقال في أكتوبر 2026، توثيق المورد يعلن انتقال Kandji إلى Iru ويحدد 1 ديسمبر 2026 موعدًا للترقية. هذا يهم القارئ الذي يبحث باسم Kandji؛ بعض البيئة والمصطلحات التي يعرفها قد تظهر ضمن واجهة أو نطاق Iru. لا تعتبر اختلاف العنوان دليلًا على أن المؤسسة تستخدم منتجًا مختلفًا تمامًا، ولا تنقل إعداد مصادقة قديمًا إلى نشر انتقل دون مراجعة.

اسأل مالك البيئة: هل الترقية تمت؟ ما عنوان الإدارة المعتمد؟ وما توثيق النسخة التي يستخدمونها؟ المقال يشرح نموذجًا موثقًا لـ Assignment Maps، لكن صلاحيات المسؤولين ومسارات API والواجهة تحتاج مطابقة مع النشر الحالي. لا تطلب من الفريق تنفيذ ترقية أو تغيير تسجيل دخول لمجرد أن الاختبار بدأ.

كذلك لا تخلط Classic Blueprints القديمة مع Assignment Maps. إذا وجدت عنصرًا قديمًا في مراجعة تاريخية، اقرأ طريقة تعيينه كما كانت، ثم راجع ما أصبح عليه بعد الانتقال. سجل النسخة أو تاريخ المصدر في الدليل حتى يعرف من يعيد الاختبار هل المقارنة على نفس منطق التوزيع.

Blueprint حاوية إدارة، وLibrary Item محتوى قابل للتعيين

ابدأ بربط الجهاز بـ Blueprint، ثم عناصر المكتبة التي يمكن أن تصل إليه عبر الخريطة. عنصر المكتبة قد يمثل تطبيقًا أو إعدادًا أو عملًا إداريًا حسب النوع. اسم Blueprint مثل Sales Macs لا يثبت أن كل عناصره مناسبة لكل مستخدم فيه؛ التفاصيل في مسارات التعيين والشروط.

في مختبرنا نستخدم عنصرين عامين: إعداد تجريبي يحمل علامة A، وآخر يحمل علامة B. لا نستخدم Profile يضعف حماية ولا تطبيقًا له صلاحيات حساسة. الهدف معرفة أي مسار اختاره النظام، ثم ربط نفس نموذج القرار بعناصر الإنتاج من خلال قراءة التعيينات مع المالك.

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

داخل كتلة واحدة: أول تطابق يغير نتيجة الشروط التالية

وثائق Conditional Logic تشرح تقييم المسارات داخل Conditional Block بالترتيب، والانتقال عند أول شرط مطابق بدل تطبيق جميع شروط else if في نفس الكتلة. الصورة المرفقة تعرض شرط قسم عام يطابق قبل شرط يجمع القسم والمعالج. هذه نقطة قراءة أساسية، وليست خللًا في المنتج؛ المنطق يعمل كما صُمم.

خلنا نكتب مثالًا خاصًا بالمختبر: الشرط الأول قسم البيع، والثاني قسم البيع ومعالج Intel. كل جهاز يحقق الثاني يحقق الأول أيضًا. إذا كانا ضمن نفس سلسلة القرار بهذا الترتيب، الشرط الثاني ما يحصل على فرصة للجهاز المطابق للأول. وجود النص الأدق في الخريطة يعطي شعورًا زائفًا أنه مطبق.

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

AND وOR: ترجم القاعدة إلى حالات جهاز

الشرط الذي يقول «القسم بيع AND الجهاز Intel» يختلف عن «القسم بيع OR الجهاز Intel». الأول يطلب الصفتين، والثاني يقبل واحدة منهما. الفرق بسيط في الشرح، لكنه ممكن يوسع جمهور عنصر من عدة أجهزة إلى كل أجهزة قسم وكل أجهزة معالج معين في الشركة.

بدل قراءة القاعدة بعينك فقط، جهز أربع حالات: يحقق الصفتين، يحقق القسم فقط، يحقق المعالج فقط، ولا يحقق أيًا منهما. اكتب لكل حالة العنصر المتوقع. بعده استخدم أداة Device Lookup الموثقة أو جرد جهاز مختبر لتعرف المسار الذي سيختاره النشر. ما تحتاج أربعة أجهزة إنتاج إذا تستطيع قراءة حالات تجريبية أو إعداد معمل صغير مع المالك.

انتبه لتجميع الأقواس أو الطبقات عند وجود أكثر من شرط. قاعدة فيها ثلاثة معايير قد تحمل قصدًا مختلفًا عما يفهمه الفريق من الاسم. ترجمتها إلى جملة عربية قصيرة تساعد: «أجهزة فريق معين بشرط منصة محددة». لو الترجمة ما تعكس كل فروع OR، ارجع للواجهة والنتائج قبل اعتمادها.

Else مب مساحة فاضية؛ هو قرار افتراضي

فرع Else يستقبل الحالات التي لم تطابق الشروط السابقة داخل الكتلة. إذا وضع الفريق فيه عنصرًا واسعًا بحجة أنه «للأجهزة الأخرى»، اسأل من هم الآخرون فعلًا: حساب بلا قسم؟ جهاز جديد لم تكتمل بياناته؟ مستخدم غيّر فريقه؟ كل حالة ممكن تصل إلى هذا المسار حسب المدخلات.

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

إذا الافتراضي يصل إلى محتوى حساس في الإنتاج، النتيجة تحتاج دليل مصدر البيانات والمحتوى الذي يصل، لا عبارة «Else خطر». ممكن يكون الافتراضي مقصودًا وآمنًا، وممكن يمنح إعدادًا قبل التحقق من أهلية الجهاز. اقترح حالة تجهيز محدودة إذا كانت المشكلة ناتجة عن بيانات ناقصة، مع مسار واضح لنقل الجهاز بعد تحقق المالك.

مصدر الخاصية أهم من شكل الشرط

Assignment Map قد يعتمد على خصائص جهاز أو مستخدم، مثل قسم أو بريد أو Tag وفق المدخلات المتاحة. راجع من يكتب هذه القيم ومن أين تتزامن. اسم Department يوحي ببيانات موارد بشرية، لكنه قد يكون مرتبطًا بمصدر مختلف في نشر العميل.

السؤال الهجومي المصرح هو: هل طرف أقل ثقة يستطيع تغيير مدخل يقرر حصول الجهاز على عنصر إداري أعلى حساسية؟ لا تفرض الجواب. إذا الخاصية لا يمكنه تعديلها ومصدرها مضبوط، فهذا حد قائم. وإذا هناك قدرة تعديل موثقة لحساب الدعم، اربطها بالخريطة التي تقرأها وبالجمهور الذي يتأثر.

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

Device Lookup يشرح الاختيار، لكنه مب دليل التطبيق النهائي

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

قسّم الدليل إلى قرار ثم تسليم ثم حالة جهاز. صورة المسار تبين لماذا اختيرت العلامة A. سجل العنصر أو الجهاز يبين ما أرسل أو حالته وفق المنصة. وعلى Mac المختبر تتحقق من العلامة العامة التي يمثلها العنصر. إذا Device Lookup يقول A لكن الجهاز يظهر B، راجع الاتصال والتوقيت والتوافق والنسخة قبل نسبة الاختلاف إلى المنطق.

وفي مثال خاص توضح الوثائق أن عنصر Automated Device Enrollment يظهر رماديًا في Lookup لأنه ليس محل تقييم المنطق الشرطي ذاته. لا تفسر اللون وحده كاستبعاد أمني. اقرأ معنى العنصر واللون من التوثيق الموافق، ثم راجع حالة تعيينه من المكان المخصص له إذا كان يدخل في سؤال اختبارك.

إعادة التقييم ما تعني أن الأجهزة طبقت فورًا

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

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

ولا تختبر Save على خريطة إنتاج واسعة لتشوف شكلها. إذا الأداة تعيد تقييم جمهورها، فالحفظ له أثر محتمل يتجاوز الشاشة التي أمامك. استخدم Blueprint معمل يضم جهازًا معروفًا، أو اكتفِ بقراءة المنطق وLookup إذا كانت الأدلة كافية. المراجعة قبل تغيير الاستهداف أو المحتوى توفر نتيجة أوضح وتقلل أثرًا تشغيليًا ما يحتاجه السؤال.

نقل الجهاز بين Blueprints يغير علاقات، مب اسمًا فقط

موظف دعم قد لا يستطيع تحرير عنصر مكتبة لكنه يستطيع نقل جهاز إلى Blueprint مختلفة بحسب دوره. السؤال هل الوجهة تمنحه محتوى لا يحتاجه أو تغير إعدادًا خارج سياق عمله؟ لا تسجل النقل كقدرة تنفيذ قبل قراءة الفروقات بين الوجهتين.

وثيقة الانتقال من Classic إلى Maps تذكر أن العناصر المشتركة قد لا تتغير عند نقل الجهاز إذا التعيين واحد. لذلك لازم تقارن هوية العنصر والمعرف والمحتوى، مب عدد العناصر أو الاسم فقط. عنصر Wi-Fi نفسه في الطرفين يختلف عن عنصرين لهما أسماء متشابهة وقيم مختلفة.

في مختبر مصرح جهز وجهتين لهما علامتان عامتان، وانقل الجهاز وفق اتفاق إذا احتجت اختبارًا فعليًا. اقرأ ما وصل وما سُحب والحالة النهائية. لا تفترض أن خروج الجهاز من Blueprint يسحب كل أثر فورًا؛ نوع العنصر وسياسة إدارته يحددان ما يحدث. نتائج دورة الحياة تحتاج قراءة مستقلة، خصوصًا عند تغيير مستخدم أو فريق.

Library Item مشتركة: خطورة تعديل واحد لها جمهور خفي

الخريطة المرئية قد تحتوي عنصرًا يستخدم في خرائط أخرى. إذا كان حساب محدد يستطيع تحريره، راجع المراجع التي تؤثر عليها نسخته. لا تجعل اسم Blueprint الحالية يحدد حدود الأثر؛ المصدر المشترك قد يمتد إلى فرق أخرى.

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

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

تمرين من ست حالات يختبر القصد بدل تخمينه

جهز جدولًا فيه الأجهزة الأربعة لحالات AND وOR، وحالة خامسة ببيانات مستخدم ناقصة، وسادسة مستبعدة يدويًا من عنصر المختبر. اكتب العلامة المتوقعة لكل حالة، ثم اقرأ Lookup والنتيجة العامة على الجهاز الذي يمكن تشغيله. باقي الحالات يمكن أن يراجعها المالك من بيانات مختبر أو نسخة الخريطة.

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

بعد التصحيح اترك جدول القصد للمالك مع المعرفات وتاريخ الاختبار. هذا يساعده عند ترقية واجهة أو تعديل قسم أو إضافة عنصر جديد. الاختبار الأمني هنا يعطي أصلًا تشغيليًا مفيدًا: مجموعة حالات صغيرة تكشف اتساع التعيين قبل وصوله لأجهزة العمل. وهي أفضل من توصية عامة «راجع الـ Blueprint» بدون وصف ما كان خطأً.

مراجع الصورة والمنطق والانتقال إلى Iru

مصدر الصورة وشرح تقييم الشروط وDevice Lookup:
https://support.kandji.io/kb/using-conditional-logic-in-assignment-maps

شرح Blueprints والتعيين:
https://support.kandji.io/kb/getting-started-with-assignment-maps

معلومات الانتقال الحالية:
https://docs.iru.com/en/iru/platform-overview/upgrade-to-iru

وللمقارنة مع سياسة Jamf التي تجمع محتوى وهدفًا وتوقيتًا:
https://courses.cyberpts.com/community/167/akhtbar-syasat-jamf-pro-ala-macos-alskrbt-yaml-k-root-lkn-mn-ymlk-almhtwa-wal-sc

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