#Схвалення

#Вступ

Схвалення — це форма процесу, спеціально розроблена для того, щоб ініціюватися та оброблятися людьми для прийняття рішення щодо статусу відповідних даних. Зазвичай він використовується для автоматизації офісних процесів або інших завдань, що вимагають ручного прийняття рішень, наприклад, для створення та керування ручними процесами для таких сценаріїв, як «заяви на відпустку», «схвалення відшкодування витрат» та «схвалення закупівлі сировини».

Плагін схвалення надає спеціальний тип робочого процесу (тригер) «Схвалення (подія)» та спеціальний вузол «Схвалення» для цього процесу. У поєднанні з унікальними користувацькими колекціями та користувацькими блоками NocoBase ви можете швидко та гнучко створювати та керувати різноманітними сценаріями схвалення.

#Створення робочого процесу

При створенні робочого процесу виберіть тип «Схвалення», щоб створити робочий процес схвалення:

Після цього в інтерфейсі конфігурації робочого процесу натисніть на тригер, щоб відкрити діалогове вікно для додаткових налаштувань.

#Конфігурація тригера

#Прив'язка колекції

Плагін схвалення NocoBase базується на гнучкому дизайні та може використовуватися з будь-якою користувацькою колекцією. Це означає, що конфігурація схвалення не вимагає повторного налаштування моделі даних, а безпосередньо використовує вже створену колекцію. Тому після входу в конфігурацію тригера спочатку потрібно вибрати колекцію, щоб визначити, для даних якої колекції буде проводитися цей процес схвалення:

#Спосіб тригера

При ініціюванні схвалення для бізнес-даних ви можете вибрати один із двох наступних способів тригера:

• Перед збереженням даних

  Ініціює схвалення перед збереженням надісланих даних. Підходить для сценаріїв, де дані мають бути збережені лише після проходження схвалення. У цьому режимі дані під час ініціювання схвалення є лише тимчасовими й будуть офіційно збережені у відповідній колекції тільки після схвалення.

• Після збереження даних

  Ініціює схвалення після збереження надісланих даних. Підходить для сценаріїв, де дані можна спочатку зберегти, а потім схвалити. У цьому режимі дані вже збережені у відповідній колекції на момент початку схвалення, і будь-які зміни під час процесу схвалення також будуть збережені.

#Місце ініціювання схвалення

Ви можете вибрати, де в системі можна ініціювати схвалення:

• Лише в блоках даних

  Ви можете прив'язати дію будь-якого блоку форми цієї колекції до цього робочого процесу для ініціювання схвалення, а також обробляти та відстежувати процес схвалення в блоці схвалення окремого запису. Зазвичай це підходить для бізнес-даних.

• У блоках даних та центрі завдань

  Окрім блоків даних, схвалення також можна ініціювати та обробляти в глобальному центрі завдань. Це зазвичай підходить для адміністративних даних.

#Хто може ініціювати схвалення

Ви можете налаштувати права доступу на основі діапазону користувачів, щоб визначити, які користувачі можуть ініціювати це схвалення:

• Усі користувачі

  Усі користувачі в системі можуть ініціювати це схвалення.

• Лише вибрані користувачі

  Дозволяє ініціювати схвалення лише користувачам із вказаного діапазону. Можна вибрати декілька варіантів.

  

#Конфігурація інтерфейсу форми ініціатора

Нарешті, потрібно налаштувати інтерфейс форми ініціатора. Цей інтерфейс буде використовуватися для операцій подання при ініціюванні з блоку центру схвалення та при повторному поданні після відкликання користувачем. Натисніть кнопку конфігурації, щоб відкрити діалогове вікно:

Ви можете додати форму для заповнення на основі прив'язаної колекції або додати описовий текст (Markdown) для підказок та вказівок. Додавання блоку форми є обов'язковим, інакше ініціатор не зможе виконувати дії після входу в цей інтерфейс.

Після додавання блоку форми, як і в звичайному інтерфейсі конфігурації форми, ви можете додавати компоненти полів відповідної колекції та розташовувати їх довільно для організації вмісту форми:

На відміну від кнопки прямого подання, ви також можете додати кнопку дії «Зберегти як чернетку» для підтримки процесу тимчасового збереження:

Якщо робочий процес схвалення дозволяє ініціатору відкликати запит, необхідно ввімкнути кнопку «Відкликати» в конфігурації інтерфейсу ініціатора:

Після ввімкнення схвалення, ініційоване цим процесом, може бути відкликане ініціатором до того, як його обробить будь-який схвалювач. Однак після того, як запит буде оброблений схвалювачем у будь-якому наступному вузлі схвалення, його більше не можна буде відкликати.

#Картка «Мої запити» 2.0+

Використовується для налаштування карток завдань у списку «Мої запити» в центрі завдань.

На картці можна вільно налаштувати бізнес-поля (крім полів зв'язку), які ви хочете відобразити, або інформацію, пов'язану зі схваленням.

Після створення запиту на схвалення ви зможете побачити налаштовану картку завдання в списку центру завдань:

#Режим відображення записів у процесі

• Знімок

  У процесі схвалення ініціатор та схвалювачі бачать стан запису на момент входу в процес, і після подання вони бачать лише змінені ними записи — вони не бачитимуть оновлень, зроблених іншими пізніше.

• Останні дані

  У процесі схвалення ініціатор та схвалювачі завжди бачать останню версію запису протягом усього процесу, незалежно від того, в якому стані був запис до їхньої дії. Після завершення процесу вони побачать фінальну версію запису.

#Вузол схвалення

У робочому процесі схвалення необхідно використовувати спеціальний вузол «Схвалення» для налаштування логіки дій схвалювачів (схвалити, відхилити або повернути). Вузол «Схвалення» можна використовувати лише в робочих процесах схвалення. Зверніться до Вузол схвалення для отримання детальної інформації.

#Конфігурація ініціювання схвалення

Після налаштування та ввімкнення робочого процесу схвалення ви можете прив'язати цей робочий процес до кнопки подання форми відповідної колекції, щоб користувачі могли ініціювати схвалення під час подання:

Після цього подання користувачем цієї форми запустить відповідний робочий процес схвалення. Надіслані дані не лише зберігаються у відповідній колекції, але й фіксуються як знімок у процесі схвалення для подальшого перегляду схвалювачами.

#Центр завдань

Центр завдань надає єдиний вхід для зручного перегляду та обробки завдань користувачами. До схвалень, ініційованих поточним користувачем, та завдань до виконання можна перейти через центр завдань на верхній панелі інструментів, а також переглядати різні типи завдань через навігацію зліва.

#Мої запити

#Перегляд ініційованих схвалень

#Безпосереднє ініціювання нового схвалення

#Мої завдання

#Список завдань

#Деталі завдання

#HTTP API

#Ініціатор

#Ініціювання з колекції

З блоку даних ініціювання можна викликати так (на прикладі кнопки створення в таблиці 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 — це ключ робочого процесу, декілька ключів розділяються комами. Цей ключ можна отримати, навівши курсор на назву робочого процесу у верхній частині полотна робочого процесу:

Після успішного виклику буде запущено робочий процес схвалення для відповідної колекції 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: ID робочого процесу для ініціювання схвалення, обов'язково.
• 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>: ID запису схвалення для відкликання, обов'язково.

#Схвалювач

Після того як процес схвалення входить у вузол схвалення, для поточного схвалювача створюється завдання. Схвалювач може виконати завдання через інтерфейс або через виклик HTTP API.

#Отримання записів обробки схвалення

Завдання до виконання — це записи обробки схвалення. Ви можете отримати всі записи обробки схвалення поточного користувача через наступний інтерфейс:

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>: 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>: ID запису для обробки, обов'язково.
• returnToNodeKey: Ключ цільового вузла для повернення, опціонально. Якщо у вузлі налаштовано діапазон вузлів для повернення, цей параметр можна використовувати для вказівки вузла. Якщо не налаштовано, параметр не потрібен, і за замовчуванням повернення відбудеться до початкової точки для повторного подання ініціатором.

#Делегування

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

Параметри

• <record id>: ID запису для обробки, обов'язково.
• assignee: ID користувача, якому делегується завдання, обов'язково.

#Додавання підписанта

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

Параметри

• <record id>: ID запису для обробки, обов'язково.
• assignees: Список ID користувачів для додавання, обов'язково.
• order: Порядок додавання, -1 означає перед «мною», 1 означає після «мене».