تخطي إلى المحتوى الرئيسي

إدارة الخادم

ميزات إدارة الخادم في ChurchApps متاحة فقط للمستخدمين الذين لديهم صلاحية Server.Admin. تُستخدم هذه الأدوات لعمليات المنصة والدعم واستكشاف الأخطاء وإصلاحها عبر جميع الكنائس في النظام.

تقييد الوصول

الميزات الموضحة في هذه الصفحة تتطلب صلاحية Server.Admin ولا تتوفر لمسؤولي الكنائس العاديين. وهي مخصصة لمشغّلي المنصة وفريق الدعم فقط.

الوصول إلى إدارة الخادم​

يمكن للمستخدمين الذين لديهم صلاحية Server.Admin الوصول إلى لوحة إدارة الخادم من B1 Admin:

  1. سجّل الدخول إلى admin.b1.church
  2. افتح قائمة الانتقال، ثم وسّع Settings وانقر على Server Admin. (يمكنك أيضًا الانتقال مباشرةً إلى admin.b1.church/admin.)
  3. تعرض لوحة Server Admin أقسامها على الجانب الأيسر في ثلاث مجموعات: Directory (Churches وUsers وImpersonate User)، وOperations (Background Jobs وCommons وUsage Trends)، وSystem (Translation Lookups وServer Health وDatabase Migrations)

إعادة تعيين تسجيل الدخول بالتحقق بخطوتين​

إذا كان لدى مستخدم تسجيل الدخول بالتحقق بخطوتين مفعّلًا وفقد هاتفه ورموز النسخ الاحتياطي معًا، يمكن لمسؤول الخادم إيقاف هذه الميزة:

  1. افتح قسم Users في لوحة Server Admin وابحث عن المستخدم.
  2. يعرض المستخدمون الذين لديهم تسجيل دخول بالتحقق بخطوتين شارة التحقق بخطوتين مفعّل. انقر على Reset 2FA بجانبها.
  3. أكّد الطلب. لا تنفّذ هذه الخطوة إلا بعد التأكد من هوية الشخص الذي تتحدث معه.

يمكن للمستخدم بعد ذلك تسجيل الدخول بكلمة المرور وحدها، ثم إعداد تسجيل الدخول بالتحقق بخطوتين مرة أخرى من ملفه الشخصي. تُسجَّل عمليات إعادة التعيين في سجل التدقيق باسم mfa_reset. نقطة النهاية هي POST /membership/users/mfa/reset/:userId وتتطلب صلاحية Server.Admin.

انتحال هوية المستخدم​

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

كيفية انتحال هوية مستخدم​

  1. افتح قسم Impersonate User في لوحة Server Admin.
  2. أدخل اسم المستخدم أو عنوان بريده الإلكتروني في حقل البحث.
  3. انقر على Search أو اضغط Enter.
  4. من نتائج البحث، انقر على المستخدم الذي تريد انتحال هويته.
  5. أكّد الانتحال في مربع الحوار الذي يظهر.
  6. ستسجّل الدخول باسم ذلك المستخدم وتُنقل إلى حسابه.

ملاحظات مهمة​

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

نقطة نهاية واجهة البرمجة​

تعتمد ميزة الانتحال على نقطة النهاية /users/:userId/impersonate في واجهة Membership API. راجع نقاط نهاية Membership للاطلاع على التفاصيل التقنية.

اعتبارات الأمان​

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

إشراف Commons​

Commons هي قائمة الإشراف المشتركة للمحتوى الذي يقدمه المستخدمون عبر المنتجات المختلفة. تمر أغاني WorshipCommons ودروس Lessons.church وقوالب FreeShow وقوالب منشئ مواقع B1 جميعها عبر القائمة نفسها بدلًا من أدوات مراجعة منفصلة لكل منتج.

الوصول إلى Commons​

  1. انتقل إلى علامة التبويب Commons في لوحة Server Admin.
  2. سترى ثلاث علامات تبويب فرعية: Queue وReports وAssets.

يمكن لدور music editor المحدود أن يرى علامة التبويب Queue أيضًا، لكنه يُمنع من الموافقة على الإرسالات التي تغيّر حقوق أغنية أو ترخيصها.

Queue​

تعرض القائمة جميع الإرسالات المعلّقة عبر جميع المنتجات، ويمكن تصفيتها حسب المنتج ونوع المحتوى. يوضح كل صف ما إذا كان الإرسال أصلًا جديدًا أو تعديلًا من مؤلفه الأصلي أو تعديلًا من طرف ثالث، إلى جانب سجل الموافقات السابق للمُرسِل والمدة التي انتظر فيها الإرسال (ويُعلَّم الإرسال بعد مرور 72 ساعة).

انقر على Review لفتح لوحة جانبية تعرض الفروقات على مستوى الحقول ومعاينات الملفات ومعاينة للقراءة فقط للعنصر. استخدم اختصارات لوحة المفاتيح a للموافقة وr للرفض، واستخدم j وk للانتقال إلى الإرسال التالي أو السابق دون مغادرة اللوحة. يتطلب الرفض اختيار سبب (مثل الجودة أو التكرار أو الترخيص أو ccli أو الذكاء الاصطناعي أو خارج الموضوع) وكتابة ملاحظة.

Reports​

تتعامل علامة التبويب Reports مع تقارير حقوق النشر والسياسات والجودة المقدمة ضد محتوى منشور بالفعل، وتنقسم إلى قائمتين منفصلتين هما Copyright وPolicy & Other، بالإضافة إلى سجل Resolved للتقارير التي تمت معالجتها. اختر تقريرًا لبدء العمل عليه، ثم أغلقه بتحديد حل (upheld أو dismissed أو duplicate) وإجراء (none أو unpublish أو remove).

Assets​

تُعد علامة التبويب Assets متصفحًا قابلًا للبحث للمحتوى المنشور، وتتضمن إجراءات لـFeature لعرض المحتوى على الصفحة الرئيسية للمنتج، وUnpublish/Republish لإلغاء النشر أو إعادته، وRemove لحذفه (مع تحديد سبب يتعلق بحقوق النشر أو السياسات).

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

معلومة

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

راجع صفحة بنية Content Commons للاطلاع على نموذج البيانات الأساسي ودورة حياة الإرسال.

الموافقة على البريد الإلكتروني للمجموعات​

لا تستطيع الكنائس إرسال البريد الإلكتروني الذي تكتبه بنفسها (بريد المجموعات، ومتابعات النماذج، ورسائل سير العمل، ودعوات الحسابات) إلا بعد أن يوافق عليه مسؤول الخادم. يمنع ذلك الكنائس المسجلة عبر الروبوتات من استخدام عنوان الإرسال المشترك لـ ChurchApps في إرسال الرسائل المزعجة.

  1. افتح علامة التبويب Churches في لوحة Server Admin.
  2. تعرض كل كنيسة شارة Group Email: إما Approved (باللون الأخضر) أو Not approved (بإطار فقط).
  3. انقر على الشارة وأكّد لتفعيل الموافقة للكنيسة، أو لإلغائها.

يطلب موظفو الكنيسة الموافقة عبر زر Request review في مربع حوار Send Email في B1 Admin. يُرسل الطلب بالبريد الإلكتروني إلى عنوان الدعم ويتضمن اسم الكنيسة ومعرّفها وتاريخ تسجيلها وموقعها ومن قدّم الطلب. يمكن للكنيسة إرسال طلب واحد في الأسبوع. راجع حدود البريد الإلكتروني الذي تكتبه الكنيسة للاطلاع على الحصة اليومية والإيقاف التلقائي عند الارتدادات والشكاوى.

ترحيلات قاعدة البيانات​

يطبّق سير العمل Deploy Prod الترحيلات المعلّقة بنفسه. قواعد البيانات المستضافة تقبل الاتصالات فقط من داخل شبكة Api، لذلك لا يستطيع مشغّل GitHub الوصول إليها. بدلًا من ذلك، يستدعي السير مباشرةً بعد serverless deploy دالة migrate في Lambda الخاصة بـ Api (api-Prod-migrate)، والتي تشغّل الترحيلات المعلّقة لكل وحدة باستخدام المشغّل نفسه الموجود في هذه العلامة، وتفشل عملية النشر إذا فشلت أي وحدة أو رُفضت. يتراجع Rollback Prod عن كود Lambda فقط، وتبقى الترحيلات المطبّقة مطبّقة. علامة التبويب Database Migrations مخصصة للتحقق من الحالة، وتشغيل أي ترحيل لم يطبّقه النشر (مثلًا في البيئة التجريبية، إذ لا يُطبّق نشرها الترحيلات)، وتسجيل الوحدات التي ليس لها سجل بدء. (تُشغّل تثبيتات Docker المستضافة ذاتيًا الترحيلات تلقائيًا عند بدء حاوية Api.)

تعرض العلامة البيئة الحالية وصفًا واحدًا لكل وحدة (مثل membership وattendance وgiving وغيرها) مع حالتها وعدد الترحيلات المطبّقة والمعلّقة وآخر ترحيل طُبّق.

  • يطبّق Run Pending Migrations كل ترحيل معلّق، وحدةً تلو الأخرى وبالترتيب. يتوقف عند أول فشل ويعرض ما طُبّق لكل وحدة.
  • تُعلَّم الوحدة التي لها No history بأن قاعدة بياناتها أقدم من تتبّع الترحيلات. لا تُشغَّل هذه الوحدة تلقائيًا أبدًا، لأن ذلك سيعيد تشغيل ترحيلات البيانات القديمة على الجداول الحية. بدلًا من ذلك، انقر على Check Schema لهذه الوحدة. تقارن Api الجداول والأعمدة والفهارس التي ينشئها كل ترحيل بقاعدة البيانات الحية، وتعلّم كل ترحيل بإحدى الحالات: Already applied أو Missing أو Partly applied أو Data only. لا يغيّر الفحص أي شيء.
  • في نتائج الفحص، يكتب Record as Already Applied الترحيلات المكتشفة في سجل الترحيلات دون تشغيلها (بعد التأكيد). تُسجَّل كل الترحيلات حتى آخر ترحيل بحالة Already applied، بما في ذلك ترحيلات Data only ضمن هذا النطاق. أما الترحيلات Missing فتبقى معلّقة، ويمكن تشغيلها بعد ذلك بشكل طبيعي عبر Run Pending Migrations.
  • يمنع الترحيل بحالة Partly applied التسجيل. إذا كان الترحيل آمنًا لإعادة التشغيل (اقرأه أولًا)، فضع علامة على Re-run ليبقى معلّقًا ويُعاد تشغيله من البداية.

تستخدم لوحة Server Admin وواجهة سطر الأوامر (yarn migrate:up) المُرحِّل نفسه من Kysely وجدول kysely_migration نفسه، لذا فهما دائمًا متفقان على ما طُبّق. نقاط النهاية الداعمة هي GET /membership/serverHealth/migrations وPOST /membership/serverHealth/migrations/:module/run وGET .../:module/detect وPOST .../:module/baseline، وجميعها متاحة لـ Server.Admin فقط.

صفحات ذات صلة​