أمثلة ومراجع
أسئلة متكررة
هل يمكنني تغيير نوع التكامل بعد الإنشاء؟
لا. القرار محوري ويغيّر بنية التطبيق بالكامل. أنشئ تطبيقاً جديداً بالنوع المطلوب وأرشف القديم.
كم مدة المراجعة؟
عادةً 1-3 أيام عمل. التطبيقات Embedded أبطأ قليلاً لأنها تتطلب مراجعة كود إضافية.
هل يمكنني الوصول لبيانات مستأجرين متعددين بـ token واحد؟
لا. كل installation token مرتبط بـ (tenant, module) واحد فقط. إذا أردت تطبيقاً يخدم عدة مستأجرين، تحصل على token مستقل لكل تثبيت.
الاستثناء الوحيد ليس توكناً بل شخصاً: تطبيقك وهو مفتوح في مجمّع أو شركة
يقرأ المدارس التابعة لها بـ?entities= — انظر السؤال التالي.
هل يقرأ تطبيق المجمّع بيانات مدارسه من التطبيق المصغّر؟
نعم، بلا نقطة خادم. سمِّ المدارس في مسار القراءة نفسه:
Okta.getQuery('/api/apps/education/students', {'entities': 'A,B'}) يعيد غلافاً
بمفتاح كل مدرسة، و{'entity': 'A'} يعيد ردّ مدرسة واحدة كما هو. يلزم أن يحمل
تطبيقك entity.hierarchy.read، وأن يكون نطاق البيانات ممنوحاً على المجمّع أو
على المدرسة (أحدهما يكفي)، وأن يحمل الشخص tenants.children.view_members في
المجمّع. والمدرسة التي لم تثبّت تطبيقك تُقرأ بمنحة المجمّع. ومفتاح كل مدرسة
إمّا ردّها وإمّا رفضٌ يحمل error — فرّق بينهما بـidentical(answer['error'], null)
لا بـ== null التي تُخطئ قراءة المفتاح الذي لا يحمله الردّ. التفاصيل في فصل
«الشركات والمجمّعات: شجرة الجهة وبيانات مدارسها»، والمثال في فصل الوضع
native.
هل يستطيع المجمّع تثبيت تطبيقي في مدارسه فلا تزيله؟
نعم — حين تُتيح ذلك بـ{"hierarchy": {"managed_install": true}}. يثبّته المجمّع
لنفسه، ويختار مدارسه، وتبقى لكل مدرسة إعدادات التطبيق لكنها لا تستطيع إزالته:
يظهر لها «مثبّت من قبل <المجمّع>» ولا يزيله إلا المجمّع. والمجمّع يعتمد عن
المدرسة كل النطاقات التي يطلبها التطبيق. التفاصيل في «المجمّع يثبّت تطبيقك في
مدارسه — hierarchy.managed_install».
هل يُثبَّت تطبيقي في مدارس المجمّع تلقائياً حين يثبّته المجمّع؟
حين تختار ذلك: {"hierarchy": {"reach": "container_and_children"}} (خيار «المجمّع
ومدارسه» في محرّر الإصدار). عندها يُثبَّت في كل جهة تحت المجمّع نسخةً مُدارة لحظة
يثبّته المجمّع، وفي كل جهة تنضمّ إليه لاحقاً. وبلا المفتاح — أو بـ"container" —
يُثبَّت في المجمّع وحده، وهو سلوك كل تطبيق اليوم. التفاصيل في «تثبيت المجمّع يشمل
مدارسه — hierarchy.reach».
هل يكتب تطبيق المجمّع سجلاً في مدرسة الطالب؟
نعم — للتطبيق المدمج، داخل العملية: ActForStudentsInTree لدفعة طلاب، و
ActInChildEntity لمدرسة واحدة؛ ولا مسار HTTP لذلك. يحمل الشخص في المجمّع
مفتاحين — tenants.children.operate_apps وصلاحية تطبيقك للفعل — ولا تُفتح إلا
المدارس التي تُدير نسخةَ تطبيقك فيها نسخةُ المجمّع نفسها
(hierarchy.managed_install / hierarchy.reach). تضع المنصّة كل طالب في مدرسته
على الخادم، وتشغّل كودك داخلها تحت نسخة المدرسة، فيخرج إشعار وليّ الأمر تحت تلك
النسخة — بإعدادات المدرسة، أو بإعداد المجمّع إلى أن يضبط أحدٌ في المدرسة ذلك
الإشعار. لا تأخذ المدرسة من الطلب أبداً، ولا تستعمل RunAsChildEntity على مسار
طلب. التفاصيل في «التطبيق يعمل داخل مدارس المجمّع — ActInChildEntity».
كيف أصل للأخبار/الأحداث الجديدة؟
اشترك في أحداث المنصة عبر webhook_events في تطبيقك External، أو
ارجع إلى الـ Pulse dashboard إن كنت Embedded.
لو تأخّر تسليم webhook كثيراً، هل تختفي البيانات؟
لا. كل تسليم محفوظ في صفحة "Webhook Deliveries" مع زر replay يدوي. أي تسليم giving_up يبقى في السجل ولا يُحذف.
من أين أضيف إشعارات تطبيقي؟
اطّلع على قسم كتالوج الإشعارات للشرح الكامل.
المسار المباشر: التطبيقات ← اختر تطبيقك ← تبويب "الإشعارات"
(/dashboard/modules/<slug>?tab=notifications).