#الموافقة

#مقدمة

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

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

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

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

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

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

#ربط مجموعة

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

ثم، في نموذج إنشاء (أو تحرير) البيانات للمجموعة المقابلة، اربط سير العمل هذا بزر الإرسال:

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

#سحب

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

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

#إعدادات واجهة نموذج المُنشئ للموافقة

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

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

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

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

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

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

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

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

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

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

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

#طلباتي

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

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

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

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

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

#واجهة برمجة تطبيقات 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: مسودة، يشير إلى الحفظ دون الإرسال للموافقة.
  • 1: إرسال للموافقة، يشير إلى أن المُنشئ يرسل طلب الموافقة، للدخول في عملية الموافقة.

#حفظ وإرسال

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

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 يشير إلى "بعدي".