Permissions

View

1. viewReferralProgram

2. viewLedgerRecords

3. viewUserProfile

4. viewCurrency

5. viewUserRole

6. viewLiabilitiesAssests

7. viewBlockchain

8. viewMonitoring

9. viewUserDocument

10. viewUserBalance

11. viewOperation

12. viewPaymentInterface

13. viewWorkflow

14. viewTask

15. viewStaking

16. viewRole

17. viewAccountsAssets

18. viewWorkflowAudit

19. viewPermission

20. viewUser

21. viewDashboard

Edit / Create

1. editCurrency

2. editUserRole

3. editMarket

4. createCurrency

5. createMarket

6. reset2FA

7. editUserKYC

8. editStaking

9. editWorkflow

10. editRole

11. setSoftBan

12. editBlockchain

13. processOperation

14. editUserState

15. editPaymentInterface

Request

1. requestDeposit

2. requestWithdraw

Accept

1. securityAudit

2. useWorkspace

3. acceptWithdraw

4. acceptCurrency

5. acceptMarket

6. acceptReset2FA

7. acceprtSoftBan

8. acceptDeposit

Roles

...

Workflow nodes

New Workflow:

...

• Edit name for Workflow

• Workflow JSON : …..

• Select ‘Workflow Initial Component’ : ….

• + Add param
  - Key:
  - Data type:

• 'Enabled' toggle
  

1. userDecision [Flexible user decision]

...

• Component: Вибір веб компонента який буде відмальовувати ті данні які будуть відображатись в розділі Workflow -> openTasks у задачі яка була створена при відкритті деталей по ній

• Assignee User: Вибір того на кого буде назначенне завдання по вибору рішеня по завданню в розділі Workflow -> openTasks. Тільки цей користувач буде бачити створення завдання. Можна вибрати тільки одне: Assignee User | Assignee Role | Assignee Permission

• Assignee Role: Тільки користувачі з вибранною ролью буду назначені на вибір рішення по задачі в розділі Workflow -> openTasks. Можна вибрати тільки одне: Assignee User | Assignee Role | Assignee Permission

• Assignee Permission: Тільки користувачі з вибранним доступом буду назначені на вибір рішення по задачі в розділі Workflow -> openTasks. Можна вибрати тільки одне: Assignee User | Assignee Role | Assignee Permission

• Params Key: Вказання ключа в якому будут знаходитись данні для відображення під час вибору рішення по задачі. Стандартно це initialData

• Out port N: Варіант по рішенню посталенної задачі який буду вести до наступної ноди в ланцюгу
  - Name: Назва рішення
  - Primary: Кнопка буде окращена в зелений
  - Danger: Кнопка буде окращена в червоний

• +Add Out Port: Додача додаткових варінтів вирішення задачі

In: Підключення попередньої ноди і передача данних по задачі

Out Port: Порт з якого буде йти далі запит до наступної підключенної ноди або виходу. Може бути декілька в залежності від створенних варіантв вирішення задачі

2. actionCall [Call any action of any service]

...

• Action: Функціонал який є доступний в GQL схумі проекту і який буде викликанний з переданними параметрами

• Params Key: Ключ який має данні які будуть передані в виклик функції. Стандартно initialData

• Result Key: Ключ який має данні з результатом виконання функції. Стандартно result

In: Підключення попередньої ноди і передача данних

Success: Підключення наступної ноди при успішному виконанні функції.

Error: Підключення наступної ноди при провалі виконання

функції.

3. checkPermissions [Check permissions]

...

• Params Key: Вказання ключа в якому знаходиться id користувача у якого треба перевірити доступи. Стандартно initialMeta.user.id

• Permissions: Вибір доступів які будуть направляти перехід в порт true

In: Підключення попередньої ноди і передача данних

True: Підключення наступної ноди в випадку якщо вибрані доступи будуть співпадать з доступом вибранного користувача

False: Підключення наступної ноди в випадку якщо вибрані доступи не будуть співпадать з доступом вибранного користувача

4. checkRoles [Check roles]

...

• Params Key: Вказання ключа в якому знаходиться id користувача у якого треба перевірити ролі. Стандартно initialMeta.user.id

• Roles: Вибір ролів які будуть направляти перехід в порт true

In: Підключення попередньої ноди і передача данних

True: Підключення наступної ноди в випадку якщо вибрані ролі будуть співпадать з ролью вибранного користувача

False: Підключення наступної ноди в випадку якщо вибрані ролі не будуть співпадать з ролью вибранного користувача

5. copy [Copy data]

...

• From: Ключ в якому знаходяться данні які треба скоріювати

• To: Ключ в якому будуть знаходитись данні які треба скоріювати

• +Add Copy action: Створити додаткові ключі данні яких будуть скопійовані в інші ключі

In: Підключення попередньої ноди і передача данних
Out: Підключення наступної ноди і передача данних

6. delete [Delete values]

...

• Delete Item: Ключ з значенням які будуть видалені та передані далі без цих данних

• Add Delete action: Додавання полей в яких буде вказаний ключ для виданлення данних

In: Підключення попередньої ноди і передача данних

Out: Підключення наступної ноди і передача данних

7. if [If condition]

...

• Condition: Опис умови при якій буде направленно підключення наступної ноди через вихід true. Наприклад wallets.lenght > 0

In: Підключення попередньої ноди і передача данних

True: Підключення наступної ноди і передача данних при виконнанні вказанної умови

False: Підключення наступної ноди і передача данних при НЕ виконнанні вказанної умови

8. set [Set values]

...

• Key: Ключ в якому будуть збереженні данні які ми передамо в полі Value

• Type: Тип данних який буде збереженний

  • String

  • Number

  • Boolean

  • Expression

    • При виборі данного типу ви можете написати в Value строки які будуть зєднуватись з значеннями які у вас є і повертати тип строку. Наприклад "Create new currency: " + initialData.id де initialData.id це данні які вам надходять з вказуванням id нової валюти, значення яке буде відображатись буде наприклад таким: “Create new currency: USDT“

• Value: Данні які будуть збереженні

• Add Set action: додавання ще одного блоку для задавання данних

In: Підключення попередньої ноди і передача данних

Out: Підключення наступної ноди і передача данних

9. startNode [Starting point of any workflow]

Out: Підключення наступної ноди і передача данних

10. endNode [End point of workflow]

In: Підключення попередньої ноди і заверщення виконання Workflow

...

1. Admin Deposit

Conditions for nodes:

...

Admin Withdraw
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Turn off user 2 FA
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

User soft ban
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update Currency
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update Market
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

User KYC
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Operations with error / Cancel order
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update referrals groups
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Blockchains configuration
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update Workflow
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update Manual rates
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update roles
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Create / Update Privileged Users
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

Soft ban / Soft unban all users
Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

...

Creating a workflow for an admin panel with distinct roles for requesting and approving actions involves defining a series of steps and permissions. Below is a basic outline of the workflow, along with the roles and their respective responsibilities. Keep in mind that the actual implementation may vary depending on your specific requirements and the technology stack you are using.

Roles:

1. Requester Role:

   • Can initiate actions or requests.

   • Submits necessary information for the requested action.

   • Limited permissions, primarily focused on initiating requests.

2. Approver Role:

   • Reviews and approves/rejects requested actions.

   • Has broader permissions to manage approvals.

Workflow:

1. Request Initiation:

   • The Requester logs into the admin panel.

   • Navigates Navigate to the section for initiating actions or requests.

   • Fills out a request form, providing all necessary details.

   • Submits Submit the request.

2. Request Review:

   • The system logs the request and notifies the Approver role.

   • The Approver logs into the admin panel.

   • Navigates Navigate to the pending requests section.

   • Reviews Review the details of the request.

3. Approval Process:

   • The Approver has the option to approve or reject the request.

   • If approved, the system proceeds with the requested action.

   • If rejected, the system notifies the Requester with a reason for rejection.

4. Action Execution:

   • If the request is approved, the system executes the requested action.

   • This may involve database updates, changes in configurations, or other relevant operations.

5. Status Updates:

   • The system updates the status of the request to reflect whether it was approved, rejected, or is still pending.

6. Notification:

   • Both the Requester and Approver receive notifications on the status of the request.

   • Notifications may be in-app alerts, emails, or any other preferred communication method.

Additional Considerations:

• Logging and Auditing:

  • Maintain detailed logs of all actions, including who initiated requests and who approved them.

  • This helps with accountability and auditing.

• Role-Based Access Control (RBAC):

  • Ensure that permissions are well-defined for each role to prevent unauthorized access.

• User Interface:

  • Design a user-friendly interface that clearly indicates the status of requests and provides necessary information for both roles.

• Security:

  • Implement proper security measures to protect sensitive data and actions.

• Scalability:

  • Design the system to scale as the number of requests and users increaseincreases.

• Customization:

  • Allow for customization of approval workflows based on specific business needs.

Customize this basic outline according to your specific requirements, and consider involving stakeholders and end-users in the design process to ensure the workflow meets their needs effectively.

Troubleshooting

1. Common Issues and Solutions

2. Error Messages and Their Meanings

Glossary

1. Definitions of Key Terms Used in the Documentation

Appendix

1. Additional Resources

2. Contact Information for Support