Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Permissions

View Permission: This permission grants the admin access to particular information or functionalities within the system. Admins with view permission can browse through data, reports, or sections of the application, gaining insight into various aspects of the system's operations. However, they do not possess the authority to make any alterations or edits. Instead, their access is limited to viewing and analyzing the existing data or reports. This permission is crucial for admins who need to monitor the system's performance, review analytics, or access specific information without the need to modify it.

  1. viewWithdrawalRestrictions
    Grants access to view the Withdrawal Restrictions page, allowing administrators to review withdrawal limits, eligibility criteria, and other relevant information without modifying settings.

  2. viewKYCWaiting
    Allows access to the KYC Waiting sub-menu on the Users page for administrators to review pending Know Your Customer (KYC) verifications without the ability to alter or approve submissions.

  3. viewAudit
    Enables access to the Audit Logs sub-menu located within the Security page, allowing administrators to review system activity logs for monitoring purposes, without the capability to modify or delete audit entries.

  4. viewUserBalance
    Grants access to the user balance sub-menu within individual user details on the Users page, allowing administrators to review the balance and financial information associated with user accounts, without the ability to modify or alter this data.

  5. viewEmployees
    Grants access to the employees sub-menu located within the Security page, enabling administrators to review employee accounts, and roles without the ability to modify or delete employee information.

  6. viewReferralProgram
    Grants access to the referral program page, allowing administrators to review details, statistics, and settings related to the referral program without the ability to modify or alter its configurations.

  7. viewStaking
    Grants access to the staking page, enabling administrators to review information, statistics, and settings related to staking activities without the ability to modify or alter staking configurations.

  8. viewSoftban
    Allows access to the Softban sub-menu located within the Security page, enabling administrators to review and manage Softban settings and configurations without the ability to modify or delete them.

  9. viewUserGeneral
    Grants access to the user general submenu within individual user details on the Users page, allowing administrators to review general information and settings associated with user accounts without the ability to modify or alter this data.

  10. viewMarkets
    Grants access to the markets sub-menu within the Configurations page, enabling administrators to review market-related settings, such as swap and trading settings, without the ability to modify or alter them.

  11. viewStatistics ?

  12. viewUserTracking
    Grants access to the tracking submenu within individual user details on the Users page, allowing administrators to review tracking information and activity associated with user accounts, without the ability to modify or alter this data.

  13. viewUserAccounting ?
    Grants access to view the user accounting details within the user's balance submenu on the Users page, enabling administrators to review financial transactions and accounting information associated with user accounts without the ability to modify or alter this data.

  14. viewBlockchains
    Grants access to the blockchains sub-menu within the Configurations page, allowing administrators to review and manage settings related to blockchain integration, configurations, or network parameters without the ability to modify or alter them.

  15. viewWorkflows
    Grants access to the workflows sub-menu within the Configurations page, enabling administrators to review workflow settings, including approval processes and task assignments, without the ability to modify or alter them.

  16. viewSystemHealth
    Grants access to the System Health sub-menu within the Dashboard page, allowing administrators to monitor and review the overall health and performance metrics of the system without the ability to modify or alter these settings.

  17. viewExchangeRates
    Grants access to the Exchange rates sub-menu within the Configurations page, enabling administrators to review settings related to market exchange rates without the ability to modify or alter them.

  18. viewCurrencies
    Grants access to the currencies sub-menu within the Configurations page, enabling administrators to review settings related to currencies, such as currency types, currency precision, or currencies payment interface, without the ability to modify or alter them.

  19. viewUserKYC
    Grants access to the KYC (Know Your Customer) sub-menu within individual user details on the Users page, enabling administrators to review KYC information and verification statuses associated with specific user accounts without the ability to modify or alter them.

  20. viewPermissions
    Grants access to the Permissions sub-menu within the Security page, allowing administrators to review user permissions, roles, and access levels without the ability to modify or alter them.

  21. viewManualRateSources
    Grants access to the manual rate source sub-menu within the Configuration page, allowing administrators to review settings related to manual rate sources for the market without the ability to modify or alter them.

  22. viewRoles
    Grants access to the Roles sub-menu within the Security page, allowing administrators to review user roles and permissions without the ability to modify or alter them.

  23. viewOperations
    Grants access to view the operations page, allowing administrators to monitor and review operational activities and processes within the system without the ability to modify or alter them.

  24. viewPaymentInterfaces
    Grants access to the Payment interfaces sub-menu within the Configurations page, enabling administrators to review settings related to payment methods, gateways, or interfaces without the ability to modify or alter them.

Edit/Create Permission: With edit permission, the admin gains the ability to modify and update existing data or settings within the system. This includes making changes to user information and adjusting configurations to better suit the organization's needs. Additionally, in scenarios involving workflow settings, admins with edit permission can initiate changes directly. Moreover, if necessary, they can request approval for proposed alterations from another administrator, ensuring proper oversight and governance over system modifications. This permission empowers admins to actively manage and customize the system according to evolving requirements and preferences.

  1. editPaymentInterface
    Grants the ability to modify and customize settings associated with payment interfaces

  2. editEmployee
    Grants the ability to modify and update information related to an employee, such as their roles, permissions, or employment status.

  3. editWithdrawalRestriction
    Grants the ability to modify existing withdrawal restriction levels or create new ones. This includes adjusting withdrawal limits, eligibility criteria, or any other parameters governing withdrawal transactions.

  4. editUserKYC
    Grants the ability to modify the KYC (Know Your Customer) status of a user. This includes updating the verification status or marking the user as verified or unverified based on the provided documentation and information.

  5. editManualRate
    Grants the ability to modify the manual rate source for a specific market or create a new manual rate source for an existing market. This includes updating the exchange rates manually or adding new rate sources for the specified market.

  6. setSoftBan
    Grants the ability to impose a soft ban on either a specific user or on all users. This includes restricting access or certain functionalities for the designated user(s), typically as a temporary measure, without permanently suspending their account(s).

  7. reset2FA
    Grants the ability to turn off or disable the enabled two-factor authentication (2FA) for a specific user. This action removes the requirement for the user to provide additional authentication beyond their password when logging into their account or to confirm withdrawal operation.

  8. editStaking ?

  9. editMarket
    Grants the ability to modify existing market settings or create a new market. This includes adjusting parameters such as fees, minimum amounts for operations, or any other settings relevant to the operation of the market.

  10. editCurrency
    Grants the ability to modify existing currency settings or payment interfaces associated with currencies, or to create entirely new currency settings or payment interfaces. This includes adjusting parameters such as currency types, precision, deposit and withdrawal settings, or Staking configuration.

  11. editRole
    Grants the ability to modify existing roles or create new ones within the system. This includes defining role permissions, access levels, and privileges for different user groups, and ensuring appropriate access and security measures are in place.

  12. editWorkflow
    Grants the ability to modify existing workflows or create entirely new workflow configurations within the system. This includes defining workflow steps, approval processes, task assignments, and automation rules to streamline business operations and improve efficiency.

  13. manageTasks ?

  14. editBlockchain
    Grants the ability to modify existing blockchain configurations within the system. This includes adjusting parameters such as network settings, consensus mechanisms, or block validation rules to accommodate changes in blockchain technology or network requirements.

  15. editUserStatus
    Grants the ability to modify the status of a user account, either banning or unbanning the user. This action restricts or restores the user's ability to access the system and perform activities based on their account status.

  16. editUserWithdrawalRestriction
    Grants the ability to adjust the withdrawal restriction level for a verified user, either increasing or decreasing it. This action modifies the withdrawal limits, eligibility criteria, or processing times for the user's withdrawal transactions based on their verified status.

Request Operation Permission: These permissions grant administrators the ability to perform operational tasks within the system. This may include managing user balance through deposit and withdrawal operations, managing operations, and performing other administrative duties necessary for the smooth operation of the system.

  1. resolveOperationError
    This permission allows administrators to manage operations that encounter errors. Administrators can choose to retry collection for deposit operations, retry or reject withdrawal operations, and retry exchange operations to ensure smooth processing and resolve any issues that may arise.

  2. useWorkspace ?

  3. cancelOrder
    This permission enables administrators to cancel open orders placed by users within the system. It allows administrators to intervene in trading activities and manage order books effectively, ensuring the integrity and stability of the trading platform.

  4. requestWithdrawal
    This permission allows the Admin to request the transfer of funds from the User`s wallet balance to an internal account of the system.

  5. requestDeposit
    This permission allows the Admin to request deposit operations, initiating the transfer of funds from an internal system account to the User`s wallet balance.

Approval Permission: grants users the authority to approve or reject requests, transactions, or configurations from other Employees. It enables Admin to review and take action on pending requests, ensuring compliance with established procedures and maintaining operational integrity.

  1. acceptWithdraw
    This permission allows administrators to approve withdrawal requests submitted by other Employees, initiating the transfer of funds from the user's account to the specified destination.

  2. acceptCurrency
    This permission grants employees the authority to review and approve requests from their peers to modify existing currency settings or payment interfaces or to create new ones. It ensures that changes to currency-related configurations are properly vetted and authorized before implementation.

  3. acceptSoftBan
    This permission allows employees to review and approve requests from their peers to modify the softban status for specific users or all users in the system. It ensures that changes to softban statuses are properly reviewed and authorized before being applied to user accounts.

  4. acceptMarket
    This permission grants employees the authority to review and approve requests from their peers to modify existing market settings or create entirely new markets. It ensures that changes to market-related configurations are properly vetted and authorized before implementation.

  5. acceptReset2FA
    This permission allows employees to review and approve requests from their peers to reset the two-factor authentication (2FA) verification for a user. It ensures that such requests are properly reviewed and authorized before the user's 2FA settings are reset.

  6. acceptDeposit
    This permission enables employees to review and approve requests from their peers to initiate deposit operations for users, facilitating the transfer of funds from an internal system account to the user's wallet balance. It ensures that such requests are properly vetted and authorized before funds are transferred.

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: 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. startNode [Starting point of any workflow]

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

  1. endNode [End point of workflow]

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

...

  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