Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

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.

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.

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.

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

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.

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.

Admin Deposit


Approve_Deposit_Test_Bank_PI

Conditions for permissions:
Requester Role: requestDeposit
Approver Role: acceptDeposit

Screenshot from 2024-01-09 19-25-54.png

  1. Start node

  2. Copy node

    Screenshot from 2024-01-09 19-30-52.png

  3. Copy node

    Screenshot from 2024-01-09 19-39-06.png

  4. Action Call node

    Screenshot from 2024-01-09 19-40-34.png

    A. Success → Set Fields node

    Screenshot from 2024-01-09 19-42-36.png

    B. Error → End node

  5. Set Fields node

  6. User Decision node

    Screenshot from 2024-01-09 19-55-41.png

    A. ‘Accept’ out port → Action Call node

    Screenshot from 2024-01-09 19-57-51.png

    • Success → End node

    • Error → End node

B. ‘Reject’ out port → End node

C. ‘Delete request’ node → End node


_______________________________________

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 to the section for initiating actions or requests.

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

    • Submits the request.

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

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

  • No labels