أدوار المستخدمين والصلاحيات في دروبال: كيف تتحكم الجامعات في من يمكنه التعديل

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

معظم الشروحات حول هذا الموضوع تغطي الآلية التقنية بشكل جيد ثم تتوقف عند مثال عام. وهذا يترك السؤال الأصعب دون إجابة: كيف تُترجم مؤسسة تضم كليات وأقسامًا ومراكز بحثية وموظفين طلابيين متغيّرين إلى نظام صلاحيات يمكن لفريق مركزي صغير أن يديره فعليًا؟ فيما يلي نستعرض هذه الترجمة، مع تسمية الصلاحيات الأساسية والوحدات (Modules) المساهِمة في كل خطوة.

كيف تعمل الأدوار والصلاحيات في دروبال

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

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

الأدوار الثلاثة التي يبدأ بها كل موقع

يحتوي موقع دروبال الجديد على دور "مستخدم زائر" (anonymous) للزوار غير المسجلين، ودور "مستخدم مسجل" (authenticated) يُمنح تلقائيًا لكل حساب يسجّل الدخول. وحسب ملف التثبيت (installation profile) المستخدم، قد يوجد أيضًا دور "مسؤول" (administrator) يُمنح كل الصلاحيات على الموقع.

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

حساب المستخدم رقم 1 ولماذا لا ينبغي لأحد العمل من خلاله

الحساب الأول الذي يُنشأ أثناء التثبيت يحمل المعرّف الداخلي 1، وهو مختلف عن أي حساب آخر. أيًا كانت الأدوار التي يحملها أو لا يحملها، يستطيع المستخدم رقم 1 تنفيذ أي إجراء على الموقع: عرض وتعديل كل المحتوى، تعديل أي حساب، تغيير الإعدادات، تثبيت الوحدات وإلغاء تثبيتها، وتشغيل سكربت التحديث. توثيق دروبال نفسه يشبّهه بحساب "الجذر" (root) على خادم Linux. كما لا يمكن حذفه عبر واجهة الإدارة.

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

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

القاعدة العملية هي الاحتفاظ ببيانات اعتماد المستخدم رقم 1 في خزنة كلمات المرور الخاصة بالمؤسسة، واستخدامها فقط للاستعادة وصيانة المنصة، ومنح كل مسؤول حسابًا مُسمّى بدور "المسؤول".

الأدوار تتراكم، ولا تُطرح أبدًا

يمكن للمستخدم أن يحمل عدة أدوار في آن واحد، وتتراكم صلاحيات هذه الأدوار. لا توجد آلية في نواة دروبال تسمح لدور بسحب صلاحية منحها دور آخر.

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

نموذج أدوار يتناسب مع طريقة عمل الجامعة فعليًا

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

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

بالنسبة للسؤال الأول، تغطي خمسة مستويات معظم المؤسسات:

• مسؤول المنصة. مجموعة مُسمّاة من شخصين إلى أربعة في تقنية المعلومات المركزية، يحملون دور "المسؤول" ويتولون الإعدادات والوحدات والتحديثات.
• محرر مركزي. موظفو الاتصالات والتسويق الذين ينشرون عبر الموقع بأكمله، بما في ذلك الصفحة الرئيسية والصفحات على مستوى المؤسسة.
• محرر وحدة (قسم). موظفو الكليات والأقسام الذين ينشئون وينشرون ضمن نطاقهم الخاص. وهذه أكبر مجموعة بفارق كبير.
• مساهم. الأكاديميون والطلاب المساعدون والمساهمون العرضيون الذين يكتبون مسودات ليقوم آخرون بنشرها.
• مُشاهد. حسابات موجودة للوصول إلى صفحات مقيّدة وليس للتعديل، مثل وثائق السياسات الخاصة بالموظفين فقط.

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

منح الأقسام نطاقها التحريري الخاص

تجيب الأدوار على سؤال "ماذا يمكن للشخص أن يفعل؟" لكن ليس "أين يمكنه فعل ذلك؟". فدور "محرر وحدة" الذي يمنح صلاحية "تعديل أي صفحة" سيسمح لقسم الأحياء بتعديل صفحات القبول. حل هذه المشكلة يتطلب طبقة ثانية، ويقدّم دروبال طريقتين معتمدتين.

التحكم القائم على الأقسام باستخدام Workbench Access

تُنشئ وحدة Workbench Access نظام تحكم تحريري يعتمد على تسلسل هرمي موجود لديك أصلًا، عادة تصنيف (taxonomy) للكليات والأقسام أو بنية قائمة الموقع. يُوضع المحتوى ضمن قسم تحريري عند إنشائه، ويُعيَّن المستخدمون إلى الأقسام حسب الحساب أو الدور، ولا يمكنهم التصرف إلا في المحتوى الموجود ضمن أقسامهم أو الأقسام الفرعية منها. صدرت النسخة 2.0.5 في سبتمبر 2026 وتدعم دروبال 9 و10 و11. يستخدمها نحو ثمانية آلاف موقع، وقد تم رعاية تطويرها من قبل Palantir.net بدعم من جامعة Charles Darwin.

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

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

متى تكون وحدة Group أنسب من الأقسام

تتبع وحدة Group نهجًا مختلفًا. فبدلًا من وضع المحتوى ضمن تسلسل هرمي، تُنشئ مجموعات لها عضويتها الخاصة وأدوارها الخاصة بداخلها. يمكن للشخص أن يكون مسؤولًا في مجموعة وعضوًا عاديًا في أخرى، وأدوار المجموعة منفصلة عن الأدوار على مستوى الموقع. تُستخدم في نحو ثمانية عشر ألف موقع.

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

يتطلب اختيار الإصدار عناية بحلول أواخر 2026. تدعم الفرعان 2.x و3.x نسختي دروبال 10 و11، وقد وصل الفرع 8.x-1.x إلى نهاية الدعم بالتزامن مع دروبال 10 في منتصف 2026، والفرع 4.x المخصص لدروبال 11.4 وما بعده لا يزال في مرحلة alpha. لا ينبغي لمنصة تبدأ الآن أن تنطلق من الفرع الأقدم.

الأدوار عبر منصة متعددة المواقع (Multisite)

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

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

صلاحيات تمنح كل شيء بصمت

بعض الصلاحيات تبدو وكأنها تسهيلات إدارية ضيقة، لكنها من الناحية العملية تعادل تسليم الموقع بأكمله. يشير دروبال نفسه إلى أخطر هذه الصلاحيات: يمكن الإعلان عن صلاحية بعلامة "وصول مقيَّد" (restricted access) ضمن تعريف الوحدة، ما يجعل صفحة الصلاحيات تعرض تحذيرًا أمنيًا قياسيًا بجانبها. تستخدم النواة هذه الآلية لصلاحيات مثل إدارة تنسيقات النصوص والفلاتر.

من السهل تجاوز هذا التحذير على صفحة تضم مئات مربعات الاختيار، لذا تستحق هذه الصلاحيات أن تُسمّى بوضوح.

• إدارة الصلاحيات (Administer permissions). أي شخص يحملها يستطيع منح نفسه أو أي شخص آخر أي صلاحية على الموقع، بما فيها هذه الصلاحية نفسها.
• إدارة المستخدمين (Administer users). تسمح بتعديل أي حساب. مع الصلاحية السابقة، أو على موقع يمكن فيه تعديل حساب مسؤول، تصبح طريقًا إلى التحكم الكامل.
• إدارة تنسيقات النصوص والفلاتر. تتحكم في نوع HTML المسموح به وأي الأدوار يمكنها استخدام أي تنسيق. تخفيف قيود تنسيق ما هو الطريق الذي يدخل عبره حقن السكربتات إلى الموقع من خلال المحرر.
• تجاوز التحكم في الوصول إلى المحتوى (Bypass content access control). تتجاوز كل صلاحية محتوى أخرى، بما فيها أي قيود يفرضها Workbench Access أو Group.
• إدارة إعدادات الموقع. تصل إلى إعدادات تؤثر على المنصة بأكملها، وليس قسمًا واحدًا من الموقع.
• إدارة الوحدات (Administer modules). تثبيت الشيفرة هو الطريق الأكثر مباشرة لتشغيل شيفرة عشوائية على الخادم.

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

يستحق الأمر تصحيح ادعاء متداول في كتابات أقدم حول هذا الموضوع: أن الوحدات المساهَمة (contributed modules) أقل أمانًا بطبيعتها من النواة. الوحدات المساهَمة ذات الإصدارات المستقرة مشمولة بسياسة الاستشارات الأمنية لدروبال، وكل الوحدات المذكورة في هذا المقال تحمل هذه التغطية. ما يختلف فعلًا هو حالة الصيانة، وهي مذكورة على صفحة كل مشروع وهي ما ينبغي التحقق منه.

السماح للأقسام بإدارة أفرادها بنفسها

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

من أجل ذلك توجد وحدة Role Delegation. تُنشئ صلاحية "تعيين" منفصلة لكل دور على الموقع، بحيث يمكن منح إداري كلية القدرة على تعيين دور "المساهم" فقط ولا شيء آخر. يرون أداة تعيين الأدوار في نماذج الحسابات وفي العمليات الجماعية على قائمة المستخدمين، دون حملهم لصلاحية "إدارة الصلاحيات" إطلاقًا. تُستخدم في أكثر من خمسين ألف موقع، ويدعم إصدارها الحالي دروبال 10.3 و11.

يعمل التفويض بشكل أفضل مع قاعدة تحدد الأدوار القابلة للتفويض: "محرر الوحدة" و"المساهم" نعم، "المحرر المركزي" و"مسؤول المنصة" لا. هذا يبقي عملية الاستقبال اليومية محلية بينما تبقى الأدوار ذات السلطة الحقيقية مع الفريق المركزي.

تعيين الأدوار من نظام الهوية الجامعي

التعيين اليدوي لا يتوسع على مستوى الحرم الجامعي، ولا حاجة له. فعندما يسجّل الموظفون الدخول عبر مزوّد الهوية الخاص بالمؤسسة، يمكن للسمات (attributes) الصادرة في ذلك الدخول أن تحدّد تعيين الأدوار مباشرة، بحيث تصبح العضوية في مجموعة دليل (directory group) دورًا في دروبال دون أن يلمس أحد الحساب. تناولنا جانب المصادقة في تكامل تسجيل الدخول الموحد (SSO) مع SAML وShibboleth وLDAP وCAS؛ وفيما يلي ما يحدث بعد وصول الهوية.

توفّر ذلك عائلتان من الوحدات. تقدّم وحدة simpleSAMLphp Authentication تزويدًا فوريًا للحسابات (just-in-time provisioning) وتعيينًا تلقائيًا للأدوار من سمات SAML، ولا تزال منتشرة على نطاق واسع. لكن صفحة مشروعها تحمل الآن حالة "صيانة محدودة"، ويوصي القائم عليها بتقييم وحدة SAML Authentication كبديل، والتي تتمتع بسلسلة اعتماديات (dependencies) أصغر بكثير. تتعامل تلك الوحدة الثانية مع تعيين الأدوار عبر وحدتها الفرعية الخاصة بأدوار المستخدمين، وتوجد وحدة مرافقة تربط سمات SAML بعضوية Group للمؤسسات التي تستخدم المجموعات بدلًا من الأقسام.

أيًا كان المسار الذي تختاره، هناك ثلاثة قرارات تصميمية أهم من اختيار الوحدة نفسها. قرر أي سمة هي المرجعية، وعادة ما تكون مجموعة دليل وليس حقل مسمى وظيفي. قرر ما يحدث عند كل تسجيل دخول: هل تُعاد حساب الأدوار في كل مرة، ما يجعل الإزالة تلقائية، أم تُعيَّن مرة واحدة عند إنشاء الحساب، وهو ما لا يحقق ذلك. وأبقِ مجموعة صغيرة من الأدوار خارج التعيين الآلي، لأن دور "مسؤول المنصة" ينبغي أن يكون فعلًا مقصودًا وليس نتيجة لتغيير في الدليل.

الجزء الذي تتجاهله معظم المؤسسات: سحب الصلاحيات

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

تواجه الجامعة نسخة خاصة من هذه المشكلة لأن معدل الدوران موسمي ويمكن التنبؤ به. يتغيّر الموظفون الطلابيون كل فصل دراسي. المهام الإدارية الأكاديمية تتناوب سنويًا. الأقسام تندمج. لا شيء من هذا يُنتج إشعارًا لفريق الويب.

ثلاث عادات تغطي معظم المخاطر.

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

قائمة قصيرة بمن يحمل دوري "مسؤول المنصة" و"المحرر المركزي"، تُراجع مرة كل فصل دراسي من قبل شخص مُسمّى، تساوي أكثر من أي قدر من التوثيق للسياسات.

البيانات الشخصية وطبقة الصلاحيات

بمجرد أن يحمل الموقع نماذج تقديم طلبات، أو تسجيلات فعاليات، أو سجلات طلاب مستخرَجة من نظام آخر، يتحول نظام الصلاحيات من تسهيل تحريري إلى ضابط لحماية البيانات.

في الولايات المتحدة، يميّز قانون FERPA بين السجلات التعليمية ومعلومات الدليل، وتحديد الحقول التي تندرج ضمن كل فئة قرار يعود إلى مسجّل الجامعة (registrar) وليس فريق الويب. وفي الاتحاد الأوروبي والمملكة المتحدة، يشير مبدأ تقليل البيانات في اللائحة العامة لحماية البيانات (GDPR) إلى الاتجاه نفسه: يجب أن يصل الأشخاص فقط إلى البيانات التي يتطلبها عملهم، ولا أكثر.

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

مراجعة نظام الصلاحيات واختباره

نظام الصلاحيات هو إعداد (configuration)، ما يعني أنه يمكن تصديره ومراجعته بنفس طريقة مراجعة الشيفرة، ونشره بدلًا من ضبطه بالنقر مباشرة على الموقع المباشر (live). المؤسسات التي تتعامل معه بهذه الطريقة يمكنها الإجابة عن سؤال ما الذي تغيّر ومتى، حتى بعد أشهر.

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

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

التخطيط لبنية الأدوار الخاصة بك

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

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

منصات دروبال التي بناها فريق Drupal4edu في Drupart لمؤسسات مثل جامعة صابانجي (Sabanci University) وجامعة الشرق الأوسط التقنية (METU) وجامعة يلدز التقنية (Yildiz Technical University) مصمَّمة حول هذه الطبقة تحديدًا، حيث يحافظ فريق مركزي صغير على اتساق المنصة بينما تحرر كل كلية صفحاتها الخاصة. يمكنك قراءة المزيد عن نهجنا في صفحة دروبال للتعليم.

أسئلة شائعة حول أدوار وصلاحيات دروبال

آخر تحديث: 18.09.2026 15:46