Permissions

View

viewReferralProgram
viewLedgerRecords
viewUserProfile
viewCurrency
viewUserRole
viewLiabilitiesAssests
viewBlockchain
viewMonitoring
viewUserDocument
viewUserBalance
viewOperation
viewPaymentInterface
viewWorkflow
viewTask
viewStaking
viewRole
viewAccountsAssets
viewWorkflowAudit
viewPermission
viewUser
viewDashboard

Edit / Create

editCurrency
editUserRole
editMarket
createCurrency
createMarket
reset2FA
editUserKYC
editStaking
editWorkflow
editRole
setSoftBan
editBlockchain
processOperation
editUserState
editPaymentInterface

Request

requestDeposit
requestWithdraw

Accept

securityAudit
useWorkspace
acceptWithdraw
acceptCurrency
acceptMarket
acceptReset2FA
acceprtSoftBan
acceptDeposit

Roles

Admin View - The Admin role in this system has limited permissions, focused on viewing information across all pages and details. This role enables users to access the admin panel but restricts them from initiating or approving actions. The primary function is to observe and gather insights, maintaining a comprehensive view of the system's data and activities.

Permissions for Admin View role:

Support - The Admin role with support permissions has exclusive access to requesting actions within the admin panel but lacks configuration capabilities. This user can submit requests, seeking assistance or changes, but is restricted from modifying system configurations. This focused role ensures streamlined support functionalities without compromising system integrity.

Permissions for Support role:

Business Analyst - The Admin role with Business Analyst permissions has broad access, viewing all pages and details. While equipped with configuration permissions, the role is limited to initiating requests rather than making direct changes. This ensures a comprehensive understanding of the system while maintaining controlled adjustments through the request-based workflow.

Permissions for Business Analyst role:

DevOps - The Admin role with DevOps permissions is specialized, allowing access solely to the DevOps page. This focused view empowers the user to oversee and manage specific aspects related to development and operations, streamlining their responsibilities within a targeted scope

Permissions for DevOps role:

Finance Controller - The Admin role with Finance Controller permissions enjoys comprehensive access to all pages, facilitating a thorough overview. With the authority to approve configuration requests, as well as deposit and withdrawal operations, this role plays a crucial role in financial management, ensuring control over critical actions within the system.

Permissions for Finance Controller role:

Super Admin - The Admin role with all available permissions is a central and powerful entity within the system. With access to all pages, this administrator can comprehensively oversee the entire platform. They possess the authority to make configurations without requiring approval, enabling swift adjustments. The ability to execute deposit and withdrawal operations without external validation streamlines financial processes. Furthermore, this Admin can manage user privileges by editing and adding other privileged users, fostering user management flexibility. The capability to edit permissions for privileged users ensures a tailored access control mechanism. Additionally, the administrator can view, edit, and create workflows, contributing to a dynamic and adaptable system. This broad spectrum of permissions grants the Admin unparalleled control, emphasizing their pivotal role in managing and shaping the platform's functionalities.

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: Web Component Selection
Assignee User:
Selection of the person to whom the task will be assigned by choosing a task solution in the Workflow -> openTasks section. Only this user will see the creation of the task. You can choose only one: Assignee User | Assignee Role | Assignee Permission
Assignee Role:
Only users with the selected role will be assigned to choose a solution for a task in the Workflow -> openTasks section. You can choose only one: Assignee User | Assignee Role | Assignee Permission
Assignee Permission:
Only users with selected access will be assigned to select a solution for a task in the Workflow -> openTasks section. You can choose only one: Assignee User | Assignee Role | Assignee Permission
Params Key:
Specify the key in which the data will be displayed when choosing a solution to the problem. By default, it is initialData
Out port N:
An option for solving the given problem that will lead to the next node in the chain
- Name: The name of the solution
- Primary: The button will be painted in the basic color of the platform (oriented towards a positive decision)
- Danger: The button will be painted in red (oriented towards request rejection)
+Add Out Port:
Adding additional options for solving the problem
In: This signifies the connection of the previous node and the transfer of data regarding the task.
Out Port: This port is where the request will depart to the next connected node or exit. Multiple ports may exist, depending on the created options for problem resolution.

actionCall [Call any action of any service]

Action: Functionality available in the GraphQL noise of the project, to be called with the passed parameters.
Params Key: The key containing the data passed to the function call. Default is initialData.
Result Key: A key containing data resulting from the function—standard result.
In: Connects the previous node and transfers data.
Success: Connects to the next node upon successful execution of the function.
Error: Connects to the next node when execution fails.

CheckPermissions [Check permissions]

Params Key: Specifies the key containing the permissions of the user whose access needs to be checked. The default is initialMeta.permissions
Permissions: Selection of permissions that will determine the transition to the true port.
In: Connects the previous node and transfers data.
True: Connects to the next node if the selected accesses match the selected user's access.
False: Connects to the next node if the selected accesses do not match the selected user's access.

checkRoles [Check roles]

Params Key: Specifies the key containing the ID of the user whose roles need to be checked. The default is initialMeta.user.id
Roles: Selection of roles that will determine the transition to the true port.
In: Connects the previous node and transfers data.
True: Connects to the next node if the selected roles match the role of the selected user.
False: Connects to the next node if the selected roles do not match the selected user's role.

copy [Copy data]

From: The key containing the data to be copied.
To: The key where the data to be copied will be located.
+Add Copy action: Creates additional keys whose data will be copied to other keys.
In: Connects the previous node and transfers data.
Out: Connects to the next node and transmits data.

delete [Delete values]

Delete Item: A key with a value that will be deleted and passed on without this data.
Add Delete action: Adds fields where the key for deleting data will be specified.
In: Connects the previous node and transfers data.
Out: Connects to the next node and transmits data.

if [If condition]

Condition: Description of the condition under which the connection of the next node will be directed through the true output. For example, wallets.length > 0.
In: Connects the previous node and transfers data.
True: Connects to the next node and transfers data when the specified condition is met.
False: Connects to the next node and transfers data if the specified condition is not fulfilled.

set [Set values]

Key: The identifier where the transferred data in the Value field will be stored.
Type: The data type to be saved:
- String
- Number
- Boolean
- Expression
When selecting ‘Expression’, - concatenate strings with values to return a string type. For example, "Create a new currency: " + initialData.id, where initialData.id represents the ID of the new currency. The resulting value might be, for instance, "Create a new currency: USDT".
Value: The data to be saved.
Add Set action: Adds another block for setting data.
In: Connects the previous node and transfers data.
Out: Connects to the next node and transmits data.

startNode [Starting point of any workflow]

Out: Establishes the connection to the next node and facilitates the transfer of data.

endNode [End point of workflow]

In: Connects the previous node and completes the Workflow execution.

Workflows

Admin Deposit

Conditions for nodes:

Conditions for permissions:
Requester Role:
Approver Role:

Audit logs:

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:
Audit logs:

_______________________________________

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:

Requester Role:
- Can initiate actions or requests.
- Submits necessary information for the requested action.
- Limited permissions, primarily focused on initiating requests.
Approver Role:
- Reviews and approves/rejects requested actions.
- Has broader permissions to manage approvals.

Workflow:

Request Initiation:
- The Requester logs into the admin panel.
- Navigates to the section for initiating actions or requests.
- Fills out a request form, providing all necessary details.
- Submits the request.
Request Review:
- The system logs the request and notifies the Approver role.
- The Approver logs into the admin panel.
- Navigates to the pending requests section.
- Reviews the details of the request.
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.
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.
Status Updates:
- The system updates the status of the request to reflect whether it was approved, rejected, or is still pending.
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 increase.
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.

Puppeteer Workflows and Roles