#الموافقة

#مقدمة

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

توفر إضافة الموافقة نوعًا مخصصًا من سير العمل (المشغل) باسم "موافقة (حدث)" وعقدة "موافقة" مخصصة لهذا السير العمل. بالاقتران مع ميزات NocoBase الفريدة مثل المجموعات المخصصة والكتل المخصصة، يمكنك إنشاء وإدارة سيناريوهات الموافقة المختلفة بسرعة ومرونة.

#إنشاء سير عمل

عند إنشاء سير عمل، اختر نوع "الموافقة" لإنشاء سير عمل موافقة:

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

#إعدادات المشغل

#ربط مجموعة

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

#طريقة التشغيل

عند بدء الموافقة لبيانات الأعمال، يمكنك الاختيار من بين طريقتي التشغيل التاليتين:

• قبل حفظ البيانات

  بدء الموافقة قبل حفظ البيانات المرسلة، وهو مناسب للسيناريوهات التي تتطلب الموافقة قبل حفظ البيانات فعليًا. في هذا الوضع، تكون البيانات عند بدء الموافقة مؤقتة فقط، ولن يتم حفظها رسميًا في المجموعة المقابلة إلا بعد الموافقة عليها.

• بعد حفظ البيانات

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

#موقع بدء الموافقة

يمكنك اختيار المواقع التي يمكن فيها بدء الموافقة داخل النظام:

• البدء في كتل البيانات فقط

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

• البدء في كتل البيانات ومركز المهام المعلقة معًا

  بالإضافة إلى كتل البيانات، يمكن أيضًا بدء ومعالجة الموافقات في مركز المهام المعلقة العام، وهو ما يناسب عادةً البيانات الإدارية.

#من يمكنه بدء الموافقة

يمكنك تكوين الأذونات بناءً على نطاق المستخدمين لتحديد من يمكنه بدء هذه الموافقة:

• جميع المستخدمين

  يمكن لجميع المستخدمين في النظام بدء هذه الموافقة.

• المستخدمون المختارون فقط

  يُسمح فقط للمستخدمين ضمن النطاق المحدد بدء هذه الموافقة، مع دعم الاختيار المتعدد.

  

#إعداد واجهة نموذج بدء الموافقة

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

يمكنك إضافة نموذج تعبئة لواجهة المُنشئ بناءً على المجموعة المرتبطة، أو إضافة نصوص وصفية (Markdown) للتوجيه والإرشاد. يُعد إضافة النموذج أمرًا إلزاميًا؛ وإلا فلن يتمكن المُنشئ من إجراء أي عمليات عند الدخول إلى هذه الواجهة.

بعد إضافة كتلة نموذج، تمامًا كما في واجهة إعدادات النموذج العادية، يمكنك إضافة مكونات الحقول من المجموعة المقابلة وترتيبها بحرية لتنظيم المحتوى المطلوب تعبئته:

على عكس زر الإرسال المباشر، يمكنك أيضًا إضافة زر إجراء "حفظ كمسودة" لدعم عمليات الحفظ المؤقت:

إذا كان سير عمل الموافقة يسمح للمُنشئ بالسحب، فيجب تمكين زر "سحب" في إعدادات واجهة المُنشئ:

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

#بطاقة "طلباتي" 2.0+

تُستخدم لتكوين بطاقات المهام في قائمة "طلباتي" داخل مركز المهام المعلقة.

يمكنك تكوين حقول الأعمال التي ترغب في عرضها بحرية (باستثناء حقول العلاقات) أو معلومات متعلقة بالموافقة داخل البطاقة.

بعد إنشاء طلب الموافقة، ستظهر بطاقة المهام المخصصة في قائمة مركز المهام المعلقة:

#وضع عرض السجل في سير العمل

• لقطة

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

• الأحدث

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

#عقدة الموافقة

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

#إعداد بدء الموافقة

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

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

#مركز المهام المعلقة

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

#طلباتي

#عرض الموافقات التي بدأتُها

#بدء موافقة جديدة مباشرةً

#مهامي المعلقة

#قائمة المهام المعلقة

#تفاصيل المهام المعلقة

#واجهة برمجة تطبيقات HTTP

#المُنشئ

#البدء من مجموعة

للبدء من كتلة بيانات، يمكنك إجراء استدعاء كهذا (باستخدام زر إنشاء جدول posts كمثال):

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post."
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey"

حيث المعامل triggerWorkflows في عنوان URL هو مفتاح سير العمل؛ يتم فصل مفاتيح سير العمل المتعددة بفاصلات. يمكن الحصول على هذا المفتاح عن طريق تمرير مؤشر الماوس فوق اسم سير العمل في الجزء العلوي من لوحة سير العمل:

عند نجاح الاستدعاء، سيتم تشغيل سير عمل الموافقة للمجموعة posts المقابلة.

إذا كنت بحاجة إلى تشغيل أحداث لبيانات مرتبطة بعلاقة واحد إلى واحد (واحد إلى متعدد غير مدعوم حاليًا) في هذه العملية، يمكنك استخدام ! في المعامل لتحديد بيانات المشغل لحقل الارتباط:

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post.",
    "category": {
      "title": "Test category"
    }
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey!category"

عند نجاح الاستدعاء أعلاه، سيتم تشغيل حدث الموافقة للمجموعة categories المقابلة.

#البدء من مركز الموافقة

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "collectionName": "<collection name>",
    "workflowId": <workflow id>,
    "data": { "<field>": "<value>" },
    "status": <initial approval status>,
  }'
  "http://localhost:3000/api/approvals:create"

المعاملات

• collectionName: اسم المجموعة المستهدفة لبدء الموافقة، إلزامي.
• workflowId: معرف سير العمل المستخدم لبدء الموافقة، إلزامي.
• data: حقول سجل المجموعة المنشأة عند بدء الموافقة، إلزامي.
• status: حالة السجل المنشأ عند بدء الموافقة، إلزامي. القيم المتاحة تشمل:
  • 0: مسودة، تعني الحفظ دون الإرسال للموافقة.
  • 2: إرسال للموافقة، تعني قيام المُنشئ بإرسال طلب الموافقة والدخول في العملية.

#حفظ وإرسال

عندما تكون الموافقة التي تم بدؤها (أو سحبها) في حالة مسودة، يمكنك الحفظ أو الإرسال مرة أخرى عبر الواجهة التالية:

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "data": { "<field>": "<value>" },
    "status": 2
  }'
  "http://localhost:3000/api/approvals:update/<approval id>"

#الحصول على قائمة الموافقات التي تم بدؤها

curl -X GET -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' \
  "http://localhost:3000/api/approvals:listMine"

#سحب

يمكن للمُنشئ سحب السجلات التي هي قيد الموافقة حاليًا عبر الواجهة التالية:

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  "http://localhost:3000/api/approvals:withdraw/<approval id>"

المعاملات

• <approval id>: معرف سجل الموافقة المراد سحبه، إلزامي.

#الموافق

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

#الحصول على سجلات معالجة الموافقة

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

curl -X GET -H 'Authorization: Bearer <your token>' \
  "http://localhost:3000/api/approvalRecords:listMine"

بما أن approvalRecords تعمل كمورد مجموعة، يمكنك أيضًا استخدام شروط الاستعلام العامة مثل filter و sort و pageSize و page.

#الحصول على سجل معالجة موافقة واحد

curl -X GET -H 'Authorization: Bearer <your token>' \
  "http://localhost:3000/api/approvalRecords:get/<record id>"

#الموافقة والرفض

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "status": 2,
    "comment": "Looks good to me.",
    "data": { "<field to modify>": "<value>" }
  }'
  "http://localhost:3000/api/approvalRecords:submit/<record id>"

المعاملات

• <record id>: معرف السجل المراد معالجته، إلزامي.
• status: حالة معالجة الموافقة، 2 تعني "موافقة"، -1 تعني "رفض"، إلزامي.
• comment: ملاحظات معالجة الموافقة، اختياري.
• data: التعديلات التي ستجرى على سجل المجموعة في عقدة الموافقة الحالية بعد الموافقة، اختياري (فعال فقط عند الموافقة).

#الإرجاع v1.9.0+

قبل الإصدار v1.9.0، كان الإرجاع يستخدم نفس واجهة "الموافقة" و"الرفض" مع استخدام "status": 1 لتمثيل الإرجاع.

بدءًا من الإصدار v1.9.0، أصبح للإرجاع واجهة منفصلة:

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "returnToNodeKey": "<node key>",
  }'
  "http://localhost:3000/api/approvalRecords:return/<record id>"

المعاملات

• <record id>: معرف السجل المراد معالجته، إلزامي.
• returnToNodeKey: مفتاح العقدة المستهدفة للإرجاع، اختياري. عند تكوين نطاق العقد القابلة للإرجاع في العقدة، يمكن استخدام هذا المعامل لتحديد العقدة التي سيتم الرجوع إليها. في حال عدم التكوين، لا يلزم تمرير قيمة، وسيعود افتراضيًا إلى البداية ليقوم المُنشئ بإعادة الإرسال.

#التفويض (تحويل التوقيع)

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "assignee": <user id>,
  }'
  "http://localhost:3000/api/approvalRecords:delegate/<record id>"

المعاملات

• <record id>: معرف السجل المراد معالجته، إلزامي.
• assignee: معرف المستخدم المراد التفويض إليه، إلزامي.

#إضافة موقّع

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "assignees": [<user id>],
    "order": <order>,
  }'
  "http://localhost:3000/api/approvalRecords:add/<record id>"

المعاملات

• <record id>: معرف السجل المراد معالجته، إلزامي.
• assignees: قائمة معرفات المستخدمين المراد إضافتهم، إلزامي.
• order: ترتيب الإضافة، -1 تعني قبل "أنا"، 1 تعني بعد "أنا".