#אישור

#מבוא

אישור הוא צורה של תהליך עבודה המיועדת במיוחד ליזום ועיבוד על ידי בני אדם כדי לקבוע את סטטוס הנתונים הרלוונטיים. הוא משמש בדרך כלל לניהול תהליכים של אוטומציה משרדית או ענייני קבלת החלטות אנושיים אחרים, לדוגמה, ניתן ליצור ולנהל תהליכים ידניים עבור תרחישים כגון "בקשת חופשה", "אישור החזר הוצאות" ו"אישור רכש חומרי גלם".

תוסף האישור מספק סוג תהליך עבודה ייעודי (טריגר) "אישור (אירוע)" וצומת "אישור" ייעודי לתהליך זה, בשילוב עם האוספים המותאמים אישית והבלוקים המותאמים אישית הייחודיים של NocoBase, ניתן ליצור ולנהל במהירות ובגמישות סוגים שונים של תרחישי אישור.

#יצירת תהליך עבודה

בעת יצירת תהליך עבודה, בחרו בסוג "אישור" כדי ליצור תהליך אישור:

לאחר מכן, בממשק הגדרות תהליך העבודה, לחצו על הטריגר כדי לפתוח חלון קופץ להגדרות נוספות.

#הגדרות טריגר

#קישור אוסף

תוסף האישור של NocoBase מבוסס על עיצוב גמיש וניתן להשתמש בו עם כל אוסף מותאם אישית, כלומר הגדרות האישור אינן דורשות הגדרה מחדש של מודל הנתונים, אלא עושות שימוש חוזר ישיר באוספים שכבר נוצרו. לכן, לאחר הכניסה להגדרות הטריגר, עליכם לבחור תחילה אוסף כדי לקבוע עבור נתוני איזה אוסף מיועד התהליך:

#שיטת טריגר

בעת יזום אישור עבור נתונים עסקיים, ניתן לבחור בין שתי שיטות הטריגר הבאות:

• לפני שמירת נתונים

  יזום האישור לפני שמירת הנתונים שהוגשו, מתאים לתרחישים בהם יש לשמור את הנתונים רק לאחר קבלת האישור. במצב זה, הנתונים בעת יזום האישור הם נתונים זמניים בלבד, ורק לאחר קבלת האישור הם יישמרו רשמית באוסף המתאים.

• לאחר שמירת נתונים

  יזום האישור לאחר שמירת הנתונים שהוגשו, מתאים לתרחישים בהם ניתן לשמור את הנתונים תחילה ולאחר מכן לבצע אישור. במצב זה, הנתונים בעת יזום האישור כבר נשמרו באוסף המתאים, ושינויים בהם במהלך תהליך האישור יישמרו גם כן.

#מיקום יזום האישור

ניתן לבחור את המיקום במערכת ממנו ניתן ליזום את האישור:

• יזום בבלוקי נתונים בלבד

  ניתן לקשור את הפעולה של כל בלוק טופס של אוסף זה לתהליך העבודה כדי ליזום אישור, ולטפל ולעקוב אחר תהליך האישור בבלוק האישור של רשומה בודדת, בדרך כלל מתאים לנתונים עסקיים.

• יזום בבלוקי נתונים ובמרכז המשימות לביצוע

  בנוסף לבלוקי נתונים, ניתן גם ליזום ולטפל באישורים במרכז המשימות לביצוע הגלובלי, בדרך כלל מתאים לנתונים אדמיניסטרטיביים.

#מי יכול ליזום אישור

ניתן להגדיר הרשאות המבוססות על טווח משתמשים כדי לקבוע אילו משתמשים יכולים ליזום את האישור:

• כל המשתמשים

  כל המשתמשים במערכת יכולים ליזום את האישור.

• משתמשים נבחרים בלבד

  רק משתמשים בטווח המוגדר מורשים ליזום את האישור, ניתן לבחור מספר משתמשים.

  

#הגדרות ממשק טופס המייזם

לבסוף, עליכם להגדיר את ממשק הטופס של המייזם, ממשק זה ישמש לפעולות הגשה בעת יזום מבלוק מרכז האישורים ובעת יזום מחדש לאחר משיכה על ידי המשתמש. לחצו על כפתור ההגדרות כדי לפתוח את החלון הקופץ:

ניתן להוסיף לממשק המייזם טופס מילוי המבוסס על האוסף המקושר, או טקסט הסבר (Markdown) לצורך הנחיה והכוונה. הוספת בלוק טופס היא חובה, אחרת המייזם לא יוכל לבצע פעולות לאחר הכניסה לממשק זה.

לאחר הוספת בלוק טופס, בדומה לממשק הגדרות טופס רגיל, ניתן להוסיף רכיבי שדות מהאוסף המתאים ולסדר אותם כרצונכם כדי לארגן את התוכן שיש למלא בטופס:

בשונה מכפתור הגשה ישירה, ניתן גם להוסיף כפתור פעולה "שמור כטיוטה" כדי לתמוך בתהליכי שמירה זמנית:

אם תהליך אישור מאפשר למייזם למשוך את הבקשה, עליכם להפעיל את כפתור "משיכה" בהגדרות ממשק המייזם:

לאחר ההפעלה, אישור שיזום בתהליך זה יכול להימשך על ידי המייזם לפני שכל מאשר מטפל בו, אך לאחר שמאשר כלשהו בצומת אישור עוקב טיפל בבקשה, לא ניתן יהיה למשוך אותה עוד.

#כרטיס "הבקשות שלי" 2.0+

משמש להגדרת כרטיסי המשימות ברשימת "הבקשות שלי" במרכז המשימות לביצוע.

ניתן להגדיר בחופשיות את השדות העסקיים (למעט שדות קשרים) או מידע הקשור לאישור שברצונכם להציג בכרטיס.

לאחר יצירת בקשת האישור, ניתן לראות את כרטיס המשימה המותאם אישית ברשימת מרכז המשימות לביצוע:

#מצב תצוגת רשומה בתהליך

• תמונת מצב (Snapshot)

  בתהליך האישור, מצב הרשומה כפי שרואים המבקש והמאשרים בעת הכניסה, ולאחר ההגשה הם יכולים לראות רק את הרשומות שהם עצמם שינו - הם לא יראו עדכונים שבוצעו על ידי אחרים לאחר מכן.

• העדכני ביותר (Latest)

  בתהליך האישור, המבקש והמאשרים רואים תמיד את הגרסה העדכנית ביותר של הרשומה לאורך כל התהליך, ללא קשר למצב הרשומה לפני פעולתם. לאחר סיום התהליך, הם יראו את הגרסה הסופית של הרשומה.

#צומת אישור

בתהליך עבודה של אישור, עליכם להשתמש בצומת "אישור" הייעודי כדי להגדיר את הלוגיקה התפעולית עבור המאשרים לטיפול (אישור, דחייה או החזרה) באישור שיזום, צומת "אישור" ניתן לשימוש רק בתהליכי עבודה של אישור. עיינו בצומת אישור לפרטים נוספים.

#הגדרות יזום אישור

לאחר הגדרה והפעלה של תהליך עבודה של אישור, ניתן לקשור את תהליך העבודה לכפתור הגשת הטופס של האוסף המתאים, כדי לאפשר למשתמשים ליזום אישור בעת ההגשה:

לאחר מכן, הגשת הטופס על ידי המשתמש תפעיל את תהליך העבודה של האישור המתאים. הנתונים שהוגשו לא רק נשמרים באוסף המתאים, אלא גם נשמרים כתמונת מצב בתהליך האישור, לשימוש ובדיקה על ידי אנשי האישור הבאים.

#מרכז משימות לביצוע

מרכז המשימות לביצוע מספק נקודת כניסה אחידה המאפשרת למשתמשים לצפות ולטפל במשימות לביצוע. אישורים שיזמו על ידי המשתמש הנוכחי ומשימות לביצוע ניתנים לגישה דרך מרכז המשימות לביצוע בסרגל הכלים העליון, וניתן לצפות בסוגים שונים של משימות לביצוע דרך ניווט הקטגוריות בצד שמאל.

#הבקשות שיזמתי

#צפייה באישורים שכבר יזמתי

#יזום ישיר של אישור חדש

#המשימות שלי לביצוע

#רשימת משימות לביצוע

#פרטי משימה לביצוע

#API 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"

כאשר פרמטר ה-URL triggerWorkflows הוא ה-key של תהליך העבודה, ניתן להפריד מספר תהליכי עבודה בפסיקים. ניתן לקבל key זה על ידי ריחוף עם העכבר מעל שם תהליך העבודה בחלק העליון של קנבס תהליך העבודה:

לאחר קריאה מוצלחת, יופעל תהליך העבודה של האישור עבור אוסף ה-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>: מזהה רשומת האישור למשיכה, חובה.

#המאשר

לאחר שתהליך האישור נכנס לצומת אישור, תיווצר משימה לביצוע עבור המאשר הנוכחי. המאשר יכול להשלים את משימת האישור דרך פעולות בממשק, או דרך קריאה ל-API 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: ה-key של צומת היעד להחזרה, אופציונלי. כאשר מוגדר בצומת טווח צמתים שניתן להחזיר אליהם, ניתן להשתמש בפרמטר זה כדי לציין לאיזה צומת להחזיר. במקרה שלא הוגדר, אין צורך להעביר ערך לפרמטר זה, והוא יחזור כברירת מחדל לנקודת ההתחלה להגשה מחדש על ידי המייזם.

#העברה (Delegate)

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

פרמטרים

• <record id>: מזהה הרשומה לטיפול באישור, חובה.
• assignee: מזהה המשתמש שאליו מועברת המשימה, חובה.

#הוספת חותם (Add Signer)

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 מציין אחרי "אני".