> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# أدوات النشر المشترك لحسابات الجهة دون مشاركة كلمة المرور
- URL: https://arabroot.io/articles/ادوات-ادارة-حسابات-التواصل-للجهات/
- Published: 2026-10-14T14:45:00.000Z
- Updated: 2026-10-15T15:19:31.000Z
- Description: ما الذي تقدمه أدوات النشر المشترك للجهة في الأدوار والموافقة وسجل من نشر، وما الذي اكتشفناه عند تشغيل Postiz على سيرفرنا.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الأمن السيبراني, القطاع الحكومي, الاستضافة الذاتية

في [المقال السابق](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D8%A7%D9%84%D8%B1%D8%B3%D9%85%D9%8A%D8%A9-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/) ذكرنا أن كل موظف يجب أن يدخل إلى الحساب الرسمي بحسابه ودوره، وأن المنصات نفسها تدعم ذلك، ولكننا انتهينا إلى فجوتين لا تغطيهما أغلب المنصات: خطوة موافقة قبل النشر، وسجل يقول من كتب كل منشور ومن وافق عليه. وهنا تأتي أدوات النشر المشترك مثل Hootsuite وSprout Social وBuffer، والبدائل مفتوحة المصدر مثل Postiz وMixpost، فهي تجمع حسابات الجهة في مكان واحد، وتعطي الفريق أدواراً داخلها، وبعضها يضيف الموافقة والسجل، ولكنها في المقابل تصبح هي نفسها مكاناً جديداً تعيش فيه مفاتيح حساباتك.

المواضيع في السلسلة:

1. [من يملك كلمة مرور حساب الجهة في منصات التواصل؟](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D8%A7%D9%84%D8%B1%D8%B3%D9%85%D9%8A%D8%A9-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/)
2. أدوات النشر المشترك لحسابات الجهة دون مشاركة كلمة المرور (الموضوع الحالي)

وفي هذا المقال سوف نتناول:

- ما الذي تطلبه الجهة من أداة النشر المشترك، ولماذا تصبح الأداة نفسها أصلاً حساساً.
- متى تكفي أدوات المنصات نفسها مثل Meta Business Suite، ومتى تحتاج أداة منفصلة.
- Hootsuite وSprout Social وBuffer: ما يقدمه كل منها في الأدوار والموافقة والدخول الموحد، وأسعارها كما ظهرت في 15 أكتوبر 2026.
- Postiz وMixpost: الترخيص والصيانة وما تقدمه النسخة المجانية فعلاً.
- تجربة عملية على Postiz بمستخدمين اثنين، نكتشف فيها أن الدور المحدود لا يطبق في النسخة المستضافة ذاتياً، ونبحث عن سجل التدقيق فلا نجده.
- جدول مقارنة ودليل قرار.

## ماذا تطلب الجهة من أداة النشر المشترك؟

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

- **الربط دون كلمة مرور OAuth**: الأداة تتصل بكل منصة عبر إذن تمنحه المنصة، فلا تكتب كلمة مرور الحساب الرسمي في الأداة أبداً.
- **الأدوار Roles**: من ينشئ المسودة، ومن ينشر، ومن يضيف الحسابات والأشخاص، وأن يطبق ذلك فعلاً في الخادم وليس في الواجهة فقط، كما سوف نرى في التجربة.
- **الموافقة قبل النشر Approval**: المنشور لا يخرج حتى يوافق عليه شخص ثان له صلاحية الموافقة.
- **سجل التدقيق Audit Trail**: من أنشأ المنشور، ومن عدله، ومن وافق عليه، ومن أضاف شخصاً أو حساباً، ومتى.
- **الدخول الموحد SSO**: الموظف يدخل الأداة بحساب الجهة، فإذا غادر وأغلق حسابه في مزود الهوية خرج من الأداة معه، كما شرحنا في [مقال دورة حياة حساب الموظف](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8-%D8%A7%D9%84%D9%85%D9%88%D8%B8%D9%81-jml/#leaver).
- **مكان البيانات Data Residency**: أين تحفظ المسودات والرسائل والتوكنات، وتحت أي نظام.
- **الخروج من الأداة**: ماذا يحدث للتوكنات والبيانات عند انتهاء العقد.

## الأداة نفسها أصل حساس

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

![على اليمين موظفو الجهة يدخلون إلى أداة النشر المشترك بالدخول الموحد SSO وأدوار، وفي الوسط الأداة وفيها الأدوار والموافقة وسجل التدقيق ومخزن التوكنات باللون الأحمر، وعلى اليسار المنصات X وMeta وYouTube وLinkedIn تتصل بها الأداة عبر OAuth، وتحت الأداة ملاحظة أن من يملك صلاحية كافية في الأداة ينشر باسم كل الحسابات](https://arabroot.io/content/images/2026/10/social-media-tools-01-tool-in-middle.webp)

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

ولذلك فإن ضوابط OSMACC تعامل هذه الأدوات معاملة مقدم خدمة، فالضابط 2-2-1-8 يطلب تقييد صلاحيات مقدمي خدمات إدارة الحسابات والرصد وحماية العلامة التجارية، والضابط 3-1-1 يطلب تقييم الحاجة إلى هذه الخدمات ومخاطرها قبل استخدامها، والضابط 3-1-2 يطلب في العقد بنود عدم الإفصاح وحذف بيانات الجهة عند انتهاء الخدمة، وإجراءات الإبلاغ عن الثغرات والحوادث، والتزام المقدم بسياسات الجهة. وقد ذكرنا مكان هذه الضوابط في [مقال مجموعات ضوابط الهيئة](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D9%87%D9%8A%D8%A6%D8%A9-%D8%A7%D9%84%D9%88%D8%B7%D9%86%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D8%A7%D9%8A%D9%87%D8%A7-%D9%8A%D9%86%D8%B7%D8%A8%D9%82-%D8%B9%D9%84%D9%8A%D9%83/#osmacc).

## هل تحتاج أداة أصلاً؟

إذا كانت جهتك تنشر في Facebook وInstagram فقط، فإن Meta Business Suite نفسه يجمع الحسابين، ويعطي الأدوار والوصول المؤقت والشركاء وإلزام التحقق الثنائي دون تكلفة، كما شرحنا في [قسم Meta في المقال السابق](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D8%A7%D9%84%D8%B1%D8%B3%D9%85%D9%8A%D8%A9-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/#meta)، والأمر نفسه في YouTube Studio لصلاحيات القناة، وفي LinkedIn لمديري الصفحة. فمتى تحتاج أداة منفصلة؟ الحالات التي رأيناها تتكرر هي التالية:

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

## الأدوات التجارية

قرأنا صفحات الأسعار والمزايا لكل أداة في 15 أكتوبر 2026، والأسعار تتغير كثيراً، فراجعها قبل أي قرار.

### Hootsuite

بحسب [صفحة الخطط](https://www.hootsuite.com/plans?ref=arabroot.io) فإن الأسعار لكل مستخدم شهرياً مع الدفع السنوي هي 99 دولاراً للخطة Standard بعشرة حسابات، و199 دولاراً للخطة Professional، و399 دولاراً للخطة Advanced، والخطة Enterprise بسعر يحدد بالتواصل. والمهم للجهة أن مراجعة المحتوى والموافقة عليه تبدأ من الخطة Advanced، وأن الدخول الموحد SSO في الخطة Enterprise فقط.

- **نقاط القوة**: مراجعة المحتوى والموافقة عليه وتوجيه الرسائل إلى أعضاء الفريق في الخطة Advanced، وحلول امتثال ودخول موحد في الخطة Enterprise.
- **نقاط الضعف**: السعر لكل مستخدم يرتفع بسرعة مع حجم الفريق، والموافقة والدخول الموحد في أغلى الخطط.

### Sprout Social

بحسب [صفحة الأسعار](https://sproutsocial.com/pricing/?ref=arabroot.io) فإن الأسعار لكل مقعد شهرياً هي 79 دولاراً للخطة Essentials مع الدفع السنوي، و199 دولاراً للخطة Standard، و299 دولاراً للخطة Professional، و399 دولاراً للخطة Advanced، والخطة Enterprise بسعر خاص. وفي جدول المزايا الأمنية تظهر «عدم مشاركة كلمات مرور الحسابات» والتحقق الثنائي وتقييد الوصول على مستوى الحساب في كل الخطط، بينما سير الموافقة على الرسائل Message approval workflow يبدأ من الخطة Professional، والموافقة من خارج الفريق External approval في الخطة Advanced، وإعداد الدخول الموحد خدمة مذكورة في الخطة Enterprise.

- **نقاط القوة**: الأمان الأساسي في كل الخطط، وصلاحيات نشر متقدمة وموافقات واضحة في الخطط الوسطى.
- **نقاط الضعف**: أغلى من البدائل لكل مقعد، والدخول الموحد في الخطة الخاصة.

### Buffer

أما Buffer فيسعر لكل حساب منصة Channel وليس لكل مستخدم، فبحسب [صفحة الأسعار](https://buffer.com/pricing?ref=arabroot.io) فإن الخطة المجانية لثلاث قنوات ومستخدم واحد، والخطة Essentials بخمسة دولارات للقناة شهرياً مع الدفع السنوي ومستخدم واحد، والخطة Team بعشرة دولارات للقناة شهرياً مع الدفع السنوي وأعضاء فريق دون حد، وفيها مستويات الوصول Access levels وسير الموافقة على المحتوى Content approval workflows. ولم نجد في صفحة الأسعار ذكراً للدخول الموحد.

- **نقاط القوة**: أرخص طريق إلى موافقة قبل النشر لعدد قليل من الحسابات، والتسعير لا يتأثر بعدد الموظفين.
- **نقاط الضعف**: لا يوجد دخول موحد في صفحة الأسعار، وأدوات الإدارة أبسط من Hootsuite وSprout.

## البدائل مفتوحة المصدر

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

### Postiz

مشروع [Postiz](https://github.com/gitroomhq/postiz-app?ref=arabroot.io) مرخص بترخيص [AGPL-3.0](https://github.com/gitroomhq/postiz-app/blob/v2.25.1/LICENSE?ref=arabroot.io)، ومشروع نشط جداً، فآخر إصدار وقت الكتابة هو [v2.25.1](https://github.com/gitroomhq/postiz-app/releases/tag/v2.25.1?ref=arabroot.io) بتاريخ 11 أكتوبر 2026، وقبله v2.25.0 في 2 أكتوبر وv2.24.0 في 22 سبتمبر، وله خدمة سحابية تبدأ بحسب [صفحة أسعاره](https://postiz.com/pricing?ref=arabroot.io) من 29 دولاراً شهرياً لخمس قنوات ومستخدم واحد، ثم 39 دولاراً لعشر قنوات وأعضاء فريق دون حد. وعندما قرأنا الكود في الإصدار v2.25.1 قبل التجربة وجدنا ثلاثة أشياء تهم الجهة:

- **الأدوار**: في [مخطط قاعدة البيانات](https://github.com/gitroomhq/postiz-app/blob/v2.25.1/libraries/nestjs-libraries/src/database/prisma/schema.prisma?ref=arabroot.io) ثلاثة أدوار فقط داخل المؤسسة، وهي SUPERADMIN وADMIN وUSER.
- **الموافقة**: حالات المنشور هي QUEUE وPUBLISHED وERROR وDRAFT فقط، فلا توجد حالة «بانتظار الموافقة»، والحقل الوحيد الذي فيه كلمة approved يخص سوق الطلبات في الخدمة وليس موافقة داخلية. وفي الإصدار v2.25.1 أضيفت تعليقات على صفحة معاينة المنشور يمكن أن تستخدمها للمراجعة، ولكنها لا تمنع النشر.
- **التحقق من الصلاحيات**: في [ملف الصلاحيات](https://github.com/gitroomhq/postiz-app/blob/v2.25.1/apps/backend/src/services/auth/permissions/permissions.service.ts?ref=arabroot.io) شرط يمنح كل الصلاحيات المطلوبة إذا لم يكن مفتاح Stripe معرفاً، وهذه هي حالة كل نسخة مستضافة ذاتياً لا تبيع اشتراكات، وهذا ما اختبرناه في التجربة.

المقطع التالي من ملف الصلاحيات كما هو في الإصدار v2.25.1:

```typescript
    if (
      requestedPermission.length === 0 ||
      !process.env.STRIPE_PUBLISHABLE_KEY
    ) {
      for (const [action, section] of requestedPermission) {
        can(action, section);
      }
      return build({
```

في الكود أعلاه لاحظ أن التحقق من الدور ADMIN يأتي بعد هذا الشرط، فإذا لم يكن المتغير `STRIPE_PUBLISHABLE_KEY` معرفاً عاد الكود بكل الصلاحيات قبل أن يصل إليه، والملف الرسمي لـ [Docker Compose](https://github.com/gitroomhq/postiz-docker-compose?ref=arabroot.io) يتركه فارغاً.

### Mixpost

يأتي [Mixpost](https://github.com/inovector/mixpost?ref=arabroot.io) بنسختين: Lite المجانية بترخيص [MIT](https://github.com/inovector/mixpost/blob/main/LICENSE.md?ref=arabroot.io)، وآخر إصدار لها 2.6.0 بتاريخ 16 مارس 2026، وPro المدفوعة. وبحسب [صفحة شرح طريقة العمل](https://docs.mixpost.app/using/?ref=arabroot.io) فإن في Mixpost حالة «بانتظار الموافقة» للمنشور في مساحة العمل التي تطلب المراجعة، وثلاثة أدوار هي Admin وMember وViewer، وصلاحية الموافقة تمنح لكل عضو منفصلة عن دوره، فيستطيع Viewer أن يوافق دون أن يعدل. وهذا يطابق ما تحتاجه الجهة أكثر من Postiz، ولكن [صفحة الأسعار](https://mixpost.app/pricing?ref=arabroot.io) تضع سير الموافقة Approval flow وسجل نشاط المنشور Post activity في نسخة Pro بسعر 299 دولاراً بدفعة واحدة تشمل تحديثات سنة، وليس في Lite المجانية. ولذلك لم نختبر Mixpost، لأن الميزتين اللتين تهمان هذا المقال تحتاجان شراء ترخيص، ولم نشتر ترخيصاً.

## جدول المقارنة

الجدول التالي يجمع ما سبق كما قرأناه في 15 أكتوبر 2026:

| الأداة              | الترخيص أو النوع | السعر المعلن                                    | الموافقة قبل النشر                         | الدخول الموحد                                 | الاستضافة على سيرفرك |
| ------------------- | ---------------- | ----------------------------------------------- | ------------------------------------------ | --------------------------------------------- | -------------------- |
| Meta Business Suite | خدمة من المنصة   | دون تكلفة                                       | غير موجودة كخطوة موافقة                    | عبر الحسابات المدارة، وغير متاحة لكل المؤسسات | لا                   |
| Hootsuite           | خدمة سحابية      | من 99 دولاراً للمستخدم شهرياً                   | من الخطة Advanced                          | في الخطة Enterprise                           | لا                   |
| Sprout Social       | خدمة سحابية      | من 79 دولاراً للمقعد شهرياً                     | من الخطة Professional                      | في الخطة Enterprise                           | لا                   |
| Buffer              | خدمة سحابية      | من 5 دولارات للقناة شهرياً                      | في الخطة Team                              | غير مذكور في صفحة الأسعار                     | لا                   |
| Postiz              | AGPL-3.0         | مجاني على سيرفرك، والسحابة من 29 دولاراً شهرياً | لا توجد حالة موافقة، وتعليقات للمراجعة فقط | لم نختبره                                     | نعم                  |
| Mixpost Lite        | MIT              | مجاني                                           | في Pro فقط                                 | لم نختبره                                     | نعم                  |
| Mixpost Pro         | ترخيص تجاري      | 299 دولاراً بدفعة واحدة                         | نعم بحسب الوثائق، ولم نختبره               | لم نختبره                                     | نعم                  |

## أسئلة مكان البيانات قبل التعاقد

لم نذكر في الجدول أين يحفظ كل مزود بياناته، لأن ذلك يتغير بالخطة والمنطقة ولا يظهر في صفحات الأسعار، فاسأل المزود كتابة قبل التعاقد، والأسئلة التي نقترحها هي التالية:

1. في أي دولة تحفظ التوكنات والمسودات والرسائل الواردة والنسخ الاحتياطية؟
2. من موظفي المزود يستطيع الوصول إلى حسابات العملاء، وهل يسجل ذلك ويعرض على الجهة؟
3. هل يمكن ربط الدخول بمزود الهوية في الجهة، وفي أي خطة؟
4. هل يوجد سجل تدقيق يصدر للجهة بمن أنشأ ووافق ونشر، وكم يحفظ؟
5. ماذا يحذف عند انتهاء العقد، وكيف تحصل الجهة على ما يثبت الحذف؟ وهذا ما يطلبه الضابط 3-1-2-1.

## تجربة عملية: Postiz بمستخدمين اثنين

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

### التشغيل بأقل عدد من الخدمات

ملف Docker Compose الرسمي يشغل تسع خدمات، منها واجهة Temporal وأدوات إدارته وأداة Spotlight للتطوير، فحذفنا ما لا يلزم وجمعنا قاعدة Postiz وقاعدة Temporal في PostgreSQL واحد. وقد حاولنا أيضاً حذف Elasticsearch وجعل Temporal يحفظ بيانات البحث في PostgreSQL، ولكن Postiz توقف عند التشغيل بالخطأ التالي في سجل الخادم:

```text
  details: 'Unable to create search attributes: cannot have more than 3 search attribute of type Text.',
```

والسبب أن Temporal عندما يحفظ بيانات البحث في قاعدة SQL يسمح بثلاثة حقول نصية مخصصة فقط، وPostiz يسجل أكثر منها، فأعدنا Elasticsearch بأصغر ذاكرة في الملف الرسمي. والملف النهائي هو التالي:

```yaml
# Light Postiz lab: one PostgreSQL for Postiz and Temporal, no Temporal UI, admin tools or Spotlight.
# docker compose -p lab-soc up -d
name: lab-soc
services:
  postiz:
    image: ghcr.io/gitroomhq/postiz-app:v2.25.1
    container_name: lab-soc-postiz
    environment:
      MAIN_URL: 'http://localhost:24007'
      FRONTEND_URL: 'http://localhost:24007'
      NEXT_PUBLIC_BACKEND_URL: 'http://localhost:24007/api'
      JWT_SECRET: 'lab-only-7f3c9a1e5b2d4f6a8c0e1b3d5f7a9c2e'
      DATABASE_URL: 'postgresql://postgres:lab-soc-db@lab-soc-db:5432/postiz'
      REDIS_URL: 'redis://lab-soc-redis:6379'
      BACKEND_INTERNAL_URL: 'http://localhost:3000'
      TEMPORAL_ADDRESS: 'lab-soc-temporal:7233'
      IS_GENERAL: 'true'
      DISABLE_REGISTRATION: 'false'
      RUN_CRON: 'true'
      STORAGE_PROVIDER: 'local'
      UPLOAD_DIRECTORY: '/uploads'
      NEXT_PUBLIC_UPLOAD_DIRECTORY: '/uploads'
      NX_ADD_PLUGINS: 'false'
      NOT_SECURED: 'true'   # lab on http://localhost only; never in production
    volumes:
      - lab-soc-uploads:/uploads/
    ports:
      - "127.0.0.1:24007:5000"
    depends_on:
      db: { condition: service_healthy }
      redis: { condition: service_healthy }
      temporal: { condition: service_healthy }

  db:
    image: postgres:17.6-alpine
    container_name: lab-soc-db
    environment:
      POSTGRES_PASSWORD: lab-soc-db
      POSTGRES_DB: postiz
    volumes:
      - lab-soc-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 20

  redis:
    image: redis:7.2.16
    container_name: lab-soc-redis
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      retries: 20

  # Temporal's SQL visibility allows only 3 Text search attributes and Postiz registers more,
  # so the official setup keeps Elasticsearch for visibility (smallest heap from the official file).
  es:
    image: elasticsearch:7.17.27
    container_name: lab-soc-es
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms256m -Xmx256m
      - xpack.security.enabled=false
    volumes:
      - lab-soc-es:/usr/share/elasticsearch/data
    healthcheck:
      test: ["CMD-SHELL", "curl -fsS 'http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=5s' || exit 1"]
      interval: 10s
      retries: 20
      start_period: 40s

  temporal:
    image: temporalio/auto-setup:1.28.1
    container_name: lab-soc-temporal
    environment:
      - DB=postgres12
      - DB_PORT=5432
      - POSTGRES_USER=postgres
      - POSTGRES_PWD=lab-soc-db
      - POSTGRES_SEEDS=lab-soc-db
      - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml
      - ENABLE_ES=true
      - ES_SEEDS=lab-soc-es
      - ES_VERSION=v7
      - TEMPORAL_NAMESPACE=default
    volumes:
      - ./dynamicconfig:/etc/temporal/config/dynamicconfig
    depends_on:
      db: { condition: service_healthy }
      es: { condition: service_healthy }
    healthcheck:
      test: ["CMD", "temporal", "operator", "cluster", "health", "--address", "lab-soc-temporal:7233"]
      interval: 10s
      retries: 30
      start_period: 30s

volumes:
  lab-soc-db:
    name: lab-soc-db
  lab-soc-es:
    name: lab-soc-es
  lab-soc-uploads:
    name: lab-soc-uploads

networks:
  default:
    name: lab-soc-net
```

في الإعداد أعلاه لاحظ التالي:

- **إصدارات مثبتة**: الملف الرسمي يستخدم الوسم `latest` لصورة Postiz، ونحن ثبتنا `v2.25.1` حتى تكون النتيجة قابلة للتكرار.
- **`NOT_SECURED`**: يسمح بملفات تعريف الارتباط Cookies عبر HTTP على localhost فقط، ولا يستخدم في بيئة حقيقية، والصحيح هناك وضع Postiz خلف Reverse Proxy بشهادة HTTPS.
- **المنفذ على 127.0.0.1**: الأداة لا تظهر إلا على الجهاز نفسه.
- **لا يوجد أي مفتاح منصة**: لم نضع مفاتيح X أو Meta أو LinkedIn، فلا يمكن ربط أي قناة، وهذا مقصود.

وحجم Docker Image الخاص بـ Postiz وحده 7.59GB، وصورة Temporal نحو 745MB، وبعد التشغيل كان استهلاك الذاكرة كما يلي:

```bash
docker stats --no-stream --format '{{.Name}} {{.MemUsage}}' | grep lab-soc
```

والمخرج سوف يكون كما يلي:

```text
lab-soc-postiz 1.562GiB / 31.29GiB
lab-soc-temporal 168.3MiB / 31.29GiB
lab-soc-db 137.3MiB / 31.29GiB
lab-soc-es 614.1MiB / 31.29GiB
lab-soc-redis 7.816MiB / 31.29GiB
```

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

### مستخدمان: مدير ومحرر

السكربت التالي يسجل مديراً ينشئ المؤسسة «Lab Ministry»، ثم يدعو محرراً بدور USER دون إرسال بريد، فيعيد Postiz رابط الدعوة، ثم يسجل المحرر من خلاله، وبعدها يطلب المحرر نقطتين من واجهة البرمجة مخصصتين للمدير: قائمة الفريق، وإنشاء دعوة جديدة بدور ADMIN:

```bash
#!/usr/bin/env bash
# Two users in Postiz: an admin who registers the organisation, and a USER invited by link.
# Then the USER calls the team endpoints that are meant for admins.
# Lab only: test addresses on example.com, nothing is sent and no social account is connected.
set -u
B=http://127.0.0.1:24007/api
H=$(mktemp)

token() { grep -i '^auth:' "$H" | cut -d' ' -f2 | tr -d '\r'; }

echo '## 1) admin registers the organisation'
curl -s -D "$H" -X POST $B/auth/register -H 'Content-Type: application/json' \
  -d '{"email":"admin@example.com","password":"Lab-Admin-2026!x","company":"Lab Ministry","provider":"LOCAL"}'; echo
ADMIN=$(token)

echo '## 2) admin invites a USER without email (Postiz returns the invite link)'
INVITE=$(curl -s -X POST $B/settings/team -H "auth: $ADMIN" -H 'Content-Type: application/json' \
  -d '{"email":"editor@example.com","role":"USER","sendEmail":false}')
echo "$INVITE" | cut -c1-90
ORGJWT=$(echo "$INVITE" | sed -E 's/.*org=([^"]+)".*/\1/')

echo '## 3) the editor registers through the link (the org cookie carries the invite)'
curl -s -D "$H" -X POST $B/auth/register -H 'Content-Type: application/json' -H "Cookie: org=$ORGJWT" \
  -d '{"email":"editor@example.com","password":"Lab-Editor-2026!x","company":"Editor desk","provider":"LOCAL"}'; echo
EDITOR=$(token)
ORG=$(curl -s $B/user/organizations -H "auth: $ADMIN" | sed -E 's/^\[\{"id":"([^"]+)".*/\1/')

echo '## 4) the team as the admin sees it'
curl -s $B/settings/team -H "auth: $ADMIN"; echo

echo '## 5) the editor (role USER) reads the team list'
curl -s -o /dev/null -w 'HTTP %{http_code}\n' $B/settings/team -H "auth: $EDITOR" -H "showorg: $ORG"

echo '## 6) the editor (role USER) creates an invite with role ADMIN'
curl -s -X POST $B/settings/team -H "auth: $EDITOR" -H "showorg: $ORG" -H 'Content-Type: application/json' \
  -d '{"email":"outsider@example.com","role":"ADMIN","sendEmail":false}' | cut -c1-90; echo
rm -f "$H"
```

والمخرج سوف يكون كما يلي (السكربت نفسه يقص رابطي الدعوة عند 90 حرفاً بالأمر `cut`):

```text
## 1) admin registers the organisation
{"register":true}
## 2) admin invites a USER without email (Postiz returns the invite link)
{"url":"http://localhost:24007/?org=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6ImVka
## 3) the editor registers through the link (the org cookie carries the invite)
{"register":true}
## 4) the team as the admin sees it
{"users":[{"role":"SUPERADMIN","disabled":false,"user":{"email":"admin@example.com","id":"0cccf38f-7083-4989-911c-807c3df42cb1","sendSuccessEmails":true,"sendFailureEmails":true,"sendStreakEmails":true}},{"role":"USER","disabled":false,"user":{"email":"editor@example.com","id":"d0bf14c7-d41f-4bca-a5da-1c8ec43a02a2","sendSuccessEmails":true,"sendFailureEmails":true,"sendStreakEmails":true}}]}
## 5) the editor (role USER) reads the team list
HTTP 200
## 6) the editor (role USER) creates an invite with role ADMIN
{"url":"http://localhost:24007/?org=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Im91d
```

في المخرج أعلاه لاحظ التالي:

- **الخطوة 4**: المؤسسة فيها شخصان، المدير بدور SUPERADMIN والمحرر بدور USER، كما أردنا.
- **الخطوة 5**: المحرر قرأ قائمة الفريق، مع أن النقطة محمية في الكود بالقسم ADMIN.
- **الخطوة 6**: المحرر أنشأ رابط دعوة بدور ADMIN، أي أن من يحمل أدنى دور يستطيع أن يدخل شخصاً آخر بدور مدير.

### هل كان المحرر داخل مؤسسة الوزارة فعلاً؟

قبل أن نحكم على النتيجة يجب أن نستبعد تفسيراً آخر، والسبب أن Postiz عندما سجل المحرر عبر الدعوة أنشأ له أيضاً مؤسسة شخصية باسم «Editor desk» يكون فيها هو SUPERADMIN، فربما نفذ الطلب في مؤسسته هو. لذلك يدخل السكربت التالي بحساب المحرر، ويعرض مؤسساته، ثم ينشئ دعوة ADMIN ثانية ويفك محتوى التوكن JWT الذي في الرابط ليرى لأي مؤسسة صدرت:

```bash
#!/usr/bin/env bash
# Checks that the editor's ADMIN invite really belongs to the Lab Ministry organisation
# (registering through an invite also gives the editor a personal organisation where he is SUPERADMIN).
B=http://127.0.0.1:24007/api; H=$(mktemp)
curl -s -D $H -o /dev/null -X POST $B/auth/login -H 'Content-Type: application/json' \
  -d '{"email":"editor@example.com","password":"Lab-Editor-2026!x","provider":"LOCAL"}'
E=$(grep -i '^auth:' $H | cut -d' ' -f2 | tr -d '\r')
echo "editor orgs:"; curl -s $B/user/organizations -H "auth: $E"; echo
ORG=$(curl -s $B/user/organizations -H "auth: $E" | python -I -c "import json,sys;print([o['id'] for o in json.load(sys.stdin) if o['name']=='Lab Ministry'][0])")
U=$(curl -s -X POST $B/settings/team -H "auth: $E" -H "showorg: $ORG" -H 'Content-Type: application/json' \
  -d '{"email":"outsider2@example.com","role":"ADMIN","sendEmail":false}')
echo "$U" | python -I -c "
import json,sys,base64
u=json.load(sys.stdin)['url']; p=u.split('org=')[1].split('.')[1]; p+='='*(-len(p)%4)
print(json.loads(base64.urlsafe_b64decode(p)))"
echo "Lab Ministry id: $ORG"; rm -f $H
```

والمخرج سوف يكون كما يلي:

```text
editor orgs:
[{"id":"b6f0368c-e14c-4e48-989e-21cfcf535c3f","name":"Editor desk","users":[{"disabled":false,"role":"SUPERADMIN"}],"subscription":null},{"id":"be9b4284-69c4-4cf6-a9cc-420a6822b6f9","name":"Lab Ministry","users":[{"disabled":false,"role":"USER"}],"subscription":null}]
{'email': 'outsider2@example.com', 'role': 'ADMIN', 'sendEmail': False, 'orgId': 'be9b4284-69c4-4cf6-a9cc-420a6822b6f9', 'timeLimit': '2026-10-17 14:35:47', 'id': 'DoAbX', 'iat': 1792074947}
Lab Ministry id: be9b4284-69c4-4cf6-a9cc-420a6822b6f9
```

والنتيجة واضحة: المحرر بدور USER في «Lab Ministry»، والدعوة التي أنشأها بدور ADMIN صادرة لمؤسسة «Lab Ministry» نفسها، وصالحة لمدة يومين. ولم نقبل هذه الدعوة بحساب ثالث، لأن التجربة بمستخدمين اثنين، ولكن الرابط يحمل كل ما يلزم لقبولها.

### الواجهة تخفي ما لا يمنعه الخادم

الصورة التالية تبين صفحة الفريق كما يراها المدير، وفيها المحرر بدور User وزر الحذف:

![صفحة Settings في Postiz على تبويب Teams، وفيها قائمة Team Members بصفين: Admin بدور Super Admin، وEditor بدور User وبجانبه زر Remove، وتحتهما زر Add another member](https://arabroot.io/content/images/2026/10/social-media-tools-04-postiz-team-admin.webp)

صفحة الفريق عند المدير: شخصان، ولا يظهر فيها رابط الدعوة الذي أنشأه المحرر لأن الدعوات لا تحفظ

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

![أعلى صفحة Settings عند المحرر: اسم المؤسسة الحالية Editor desk، وتحته قائمة منسدلة فيها Lab Ministry (User)](https://arabroot.io/content/images/2026/10/social-media-tools-05-postiz-org-switcher.webp)

المحرر له مؤسستان: مؤسسته الشخصية، ومؤسسة الوزارة بدور User

وبعد التنقل إلى مؤسسة الوزارة يختفي تبويب Teams من الإعدادات كما تبين الصورة التالية، وهذا يعطي انطباعاً بأن الدور مطبق، بينما الخادم قبل الطلب نفسه من سطر الأوامر قبل دقائق:

![صفحة Settings عند المحرر داخل Lab Ministry، والقائمة الجانبية فيها Global Settings وAgents وWebhooks وAuto Post وSets وSignatures وIntegrations وPlugs وApps، ولا يوجد فيها تبويب Teams](https://arabroot.io/content/images/2026/10/social-media-tools-06-postiz-editor-settings.webp)

تبويب Teams مخفي عن المحرر في الواجهة، ولكن نقطة الفريق في واجهة البرمجة تقبل طلبه

⚠️

هذه النتيجة تخص Postiz v2.25.1 المستضاف ذاتياً دون مفتاح Stripe، كما اختبرناه في 15 أكتوبر 2026، وقد يتغير ذلك في إصدار لاحق، فأعد السكربت نفسه على إصدارك قبل أن تعتمد على الأدوار. وإذا كنت ستستخدم Postiz في جهة، فاعتبر كل عضو في المؤسسة مديراً، ولا تضف إلا من تثق به بهذه الصفة.

### أين سجل من فعل ماذا؟

بعد أن أنشأ المحرر دعوة ADMIN بحثنا عن أي أثر لها، فبدأنا بقاعدة البيانات بالأوامر التالية:

```bash
docker exec lab-soc-db psql -U postgres -d postiz -c "select table_name from information_schema.tables where table_schema='public' and (table_name ilike '%audit%' or table_name ilike '%activity%' or table_name ilike '%log%' or table_name ilike '%history%') order by 1;" -c "select column_name from information_schema.columns where table_name='Post' and (column_name ilike '%user%' or column_name ilike '%author%' or column_name ilike '%created%' or column_name ilike '%approv%' or column_name ilike '%state%') order by 1;" -c "select unnest(enum_range(NULL::\"State\"));" -c "select u.email, uo.role, uo.\"createdAt\" from \"UserOrganization\" uo join \"User\" u on u.id=uo.\"userId\" join \"Organization\" o on o.id=uo.\"organizationId\" where o.name='Lab Ministry' order by uo.\"createdAt\";"
```

والمخرج سوف يكون كما يلي:

```text
        table_name
---------------------------
 TrendingLog
 mastra_knowledge_activity
(2 rows)

      column_name
------------------------
 approvedSubmitForOrder
 createdAt
 state
(3 rows)

  unnest
-----------
 QUEUE
 PUBLISHED
 ERROR
 DRAFT
(4 rows)

       email        |    role    |        createdAt
--------------------+------------+-------------------------
 admin@example.com  | SUPERADMIN | 2026-10-15 14:34:58.183
 editor@example.com | USER       | 2026-10-15 14:34:58.593
(2 rows)
```

في المخرج أعلاه لاحظ التالي:

- **لا يوجد جدول تدقيق**: الجدولان اللذان ظهرا يخصان المنشورات الرائجة وذاكرة الوكيل الذكي، وليس فيهما ما يخص المستخدمين.
- **المنشور بلا كاتب**: جدول المنشورات Post ليس فيه عمود للمستخدم الذي أنشأه، فإذا نشر شخصان من الفريق لا تعرف من نشر ماذا.
- **لا توجد حالة موافقة**: الحالات أربع، وليس بينها «بانتظار الموافقة».
- **الدعوة لا تحفظ**: الدعوة توكن JWT يحمل كل بياناته، ولا يكتب في القاعدة، فلم نجد لدعوة المحرر أي صف.

والأثر الوحيد الذي وجدناه هو سجل Nginx داخل Docker Container الخاص بـ Postiz، وهذه آخر أربعة أسطر منه بعد تشغيل سكربت التحقق:

```bash
docker exec lab-soc-postiz sh -c "tail -n 4 /var/log/nginx/access.log"
```

```text
172.22.0.1 - - [15/Oct/2026:14:35:47 +0000] "POST /api/auth/login HTTP/1.1" 200 14 "-" "curl/8.12.1"
172.22.0.1 - - [15/Oct/2026:14:35:47 +0000] "GET /api/user/organizations HTTP/1.1" 200 268 "-" "curl/8.12.1"
172.22.0.1 - - [15/Oct/2026:14:35:47 +0000] "GET /api/user/organizations HTTP/1.1" 200 268 "-" "curl/8.12.1"
172.22.0.1 - - [15/Oct/2026:14:35:47 +0000] "POST /api/settings/team HTTP/1.1" 201 355 "-" "curl/8.12.1"
```

والسطر الأخير هو دعوة ADMIN التي أنشأها المحرر، ولكنه لا يقول من أنشأها ولا لأي مؤسسة ولا بأي دور، فهو سجل وصول وليس سجل تدقيق.

### ما لم نستطع إظهاره

الصورة التالية تبين التقويم عند المدير بعد الدخول، ولا توجد فيه قنوات، لأننا لم نربط حساباً:

![شاشة Calendar في Postiz بعرض الأسبوع من 12 إلى 18 أكتوبر 2026، وعلى اليسار Channels مع زر Add Channel ورسالة No channels yet، وأسفلها رقم الإصدار v2.25.1](https://arabroot.io/content/images/2026/10/social-media-tools-03-postiz-calendar.webp)

التقويم دون قنوات مربوطة، ورقم الإصدار v2.25.1 أسفل القائمة

ولذلك فإن ما يلي لم يظهر في التجربة:

- إنشاء منشور ونشره، لأن المنشور في Postiz يحتاج قناة مربوطة.
- صفحة المعاينة والتعليقات التي أضيفت في v2.25.1، لأنها تعمل على منشور موجود.
- طريقة حفظ توكنات المنصات في القاعدة وتشفيرها.
- الدخول الموحد، لأننا لم نربط مزود هوية.

### إزالة التجربة

نزيل ما أنشأناه بأسمائه فقط، ومعه الصور الثلاث التي سحبناها للتجربة:

```bash
docker compose -p lab-soc down
docker volume rm lab-soc-db lab-soc-es lab-soc-uploads
docker image rm ghcr.io/gitroomhq/postiz-app:v2.25.1 temporalio/auto-setup:1.28.1 elasticsearch:7.17.27
```

## دليل القرار

الصورة التالية تختصر الاختيار في أربعة أسئلة:

![مخطط قرار من أربعة أسئلة: هل تنشر في Meta فقط؟ نعم فاستخدم Meta Business Suite بالأدوار. لا، فهل تحتاج موافقة قبل النشر وسجلاً لمن نشر؟ لا فأدوار كل منصة تكفي. نعم، فهل يجب أن تبقى البيانات على سيرفرك؟ لا فخدمة سحابية بخطة فيها الموافقة مثل Buffer Team أو Sprout Professional أو Hootsuite Advanced. نعم، فهل تستطيع شراء ترخيص؟ نعم فأداة مستضافة بموافقة مثل Mixpost Pro بعد اختبارها. لا فاترك الموافقة عملية خارج الأداة ولا تعتمد على أدوار Postiz](https://arabroot.io/content/images/2026/10/social-media-tools-02-decision.webp)

الموافقة والسجل هما ما يحدد الأداة، وليس عدد المنصات

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

## أخطاء شائعة

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

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- أداة النشر المشترك تحذف كلمة المرور المشتركة، ولكنها تجمع توكنات كل الحسابات في مكان واحد، فهي مقدم خدمة بحسب OSMACC وتحتاج تقييماً وعقداً.
- إذا كنت تنشر في Meta فقط، فإن Meta Business Suite بأدواره قد يكفي، والأداة المنفصلة تبرر نفسها بالموافقة والسجل.
- الموافقة قبل النشر في Hootsuite من الخطة Advanced، وفي Sprout Social من Professional، وفي Buffer في الخطة Team، والدخول الموحد في الخطط الخاصة.
- Postiz مفتوح المصدر ونشط، ولكن الإصدار v2.25.1 المستضاف ذاتياً لا يطبق الدور USER في الخادم، ولا يوجد فيه سجل تدقيق ولا حالة موافقة.
- Mixpost يصف في وثائقه حالة موافقة وصلاحية موافقة منفصلة عن الدور، ولكنها في نسخة Pro المدفوعة، ولم نختبرها.

وإذا قررت أن تبقى الأدوار في المنصات نفسها، فارجع إلى [جدول المنصات في المقال السابق](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D8%A7%D9%84%D8%B1%D8%B3%D9%85%D9%8A%D8%A9-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/#platforms)، وإلى [أنظمة قسم التسويق](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%AA%D9%8A-%D9%8A%D8%AD%D8%AA%D8%A7%D8%AC%D9%87%D8%A7-%D9%83%D9%84-%D9%82%D8%B3%D9%85-%D9%81%D9%8A-%D8%A7%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A9/#marketing) لترى أين تقع هذه الأداة بين أنظمة الجهة.

[![](https://arabroot.io/content/images/2026/10/social-accounts-access-cover-cover.webp)دليلمن يملك كلمة مرور حساب الجهة في منصات التواصل؟كيف تدير الوزارة أو الجامعة حساباتها الرسمية بأدوار لكل موظف بدلاً من كلمة مرور مشتركة، وماذا تفعل إذا سرق الحساب.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D9%88%D8%A7%D8%B5%D9%84-%D8%A7%D9%84%D8%B1%D8%B3%D9%85%D9%8A%D8%A9-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/password-manager-tools-cover-cover.webp)دليلBitwarden أم Vaultwarden أم Passbolt؟ مدير كلمات مرور لفريقكمقارنة بين مديري كلمات المرور للفرق في طريقة المشاركة والترخيص والسعر والمزايا، ودليل يساعدك على اختيار الأنسب لشركتك.](https://arabroot.io/articles/bitwarden-%D8%A7%D9%85-vaultwarden-%D8%A7%D9%85-passbolt/)[![](https://arabroot.io/content/images/2026/10/sso-roles-across-apps-cover-cover.webp)دليلمستخدم أم مدير؟ إدارة الأدوار عبر تطبيقاتك من authentikكيف تحدد من authentik من يدخل كل تطبيق ومن يكون مديراً فيه، وماذا يحدث للجلسات والتوكنات عندما تسحب الصلاحية.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D8%AF%D9%88%D8%A7%D8%B1-%D8%B9%D8%A8%D8%B1-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%83-%D9%85%D9%86-authentik/)[![](https://arabroot.io/content/images/2026/10/jml-cover-cover.webp)دليلدورة حياة حساب الموظف JML من أول يوم إلى آخر يومكيف تجعل الموارد البشرية مصدر كل حساب، فيجد الموظف ما يحتاجه في يومه الأول وتغلق كل أبوابه في يوم مغادرته.](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8-%D8%A7%D9%84%D9%85%D9%88%D8%B8%D9%81-jml/)[![](https://arabroot.io/content/images/2026/10/security-awareness-cover-cover.webp)دليلبرنامج التوعية بالأمن السيبراني بأدوات مفتوحة المصدرالمحاضرة السنوية لا تغير ما يفعله الموظف أمام الرسالة المشبوهة، لذلك تبني هنا برنامج توعية مستمراً وتقيس أثره بأدوات مفتوحة المصدر.](https://arabroot.io/articles/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D8%AC-%D8%A7%D9%84%D8%AA%D9%88%D8%B9%D9%8A%D8%A9-%D8%A8%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/dept-systems-cover-cover.webp)دليلما الأنظمة التي يحتاجها كل قسم في مؤسستك؟الحد الأدنى من الأنظمة لكل قسم في الشركة، ومتى يحتاجه، وكيف تربطه بالهوية وسجل الموظف وسجل العميل.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%AA%D9%8A-%D9%8A%D8%AD%D8%AA%D8%A7%D8%AC%D9%87%D8%A7-%D9%83%D9%84-%D9%82%D8%B3%D9%85-%D9%81%D9%8A-%D8%A7%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A9/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، وقراءة صفحات الأسعار لكل من Hootsuite وSprout Social وBuffer وPostiz وMixpost في 15 أكتوبر 2026، وقراءة كود Postiz في الوسم v2.25.1، وتشغيل التجربة في 15 أكتوبر 2026 على Docker Engine 29.8.0 مع Postiz v2.25.1 وTemporal auto-setup 1.28.1 وElasticsearch 7.17.27 وPostgreSQL 17.6 وRedis 7.2.16.