Mastering Testany Platform Permission and User Status Control System: A Guide

In our commitment to secure and efficient operations, we've developed a comprehensive permission control system that adheres to the principle of least privilege. This approach ensures users are granted the minimum levels of access-or permissions-necessary to perform their functions. Below, we explain how this principle is applied and how user statuses fit into the overall framework.

User Statuses: The Foundation of Access

We categorize user engagement with the platform into four distinct statuses:

  • Invited: Users with a pending invitation to join the platform.
  • Active: Fully registered users engaging with the platform's resources.
  • Suspended: Users with temporarily restricted access.
  • Disabled: Users with permanently revoked access and no platform interaction.

Understanding 'Suspended' and 'Disabled' Statuses

  • (user) Suspended: A reversible status that maintains the user's data integrity but limits platform interaction.

    • Cannot log in or perform operations.
    • Won't receive notifications but retains resource ownership.
    • Global Admins can lift this status, fully restoring the user's access.
  • (user) Disabled: An irreversible status signifying complete disengagement from the platform.

    • Users are removed from all operational roles and cannot log in or receive notifications.
    • This status is final unless a Global Admin intervenes under exceptional circumstances.

The Principle of Least Privilege in Action

Our permission control system is built on the principle of least privilege. This means:

  • Users are only provided access to what is necessary to perform their roles, reducing the risk of accidental or malicious breaches.
  • Permissions are carefully allocated based on roles and user statuses to ensure security and functionality.

Permissions at a Glance

Permissions vary by role and are clearly defined by our permission matrix:

  • List: View a collection of resources.
  • Create: Add new resources.
  • Read: Access the details of a resource.
  • Edit (Update): Modify existing resources.
  • Delete: Remove resources.
  • Special Permissions: Role-specific actions such as granting and revoking access.

Each role has specific permissions for each action, with green (allowed) and red (denied) indicators providing at-a-glance understanding.

Best Practices for Users and Admins

  • Admins: Conduct regular permissions audits to ensure adherence to the least privilege principle.
  • Users: Stay informed of your current status and permissions, and understand how they impact your platform interaction.

In Conclusion

By implementing the least privilege principle and detailed user statuses, we've created a secure, efficient, and user-centric permission control system. This system empowers users to perform their roles effectively while safeguarding the platform's integrity.

Appendix: Permission Matrix V2.6

Object (Resource)ActionObject (Resource) OwnerGlobal Admin (non Resource Owner)Workspace Admin (non Resource Owner)Workspace Member (non Resource Owner)Non-Workspace-Roles
Caselist
create
read
edit (update)
delete
Workspacelist
create
read
edit (update)
grant_access
revoke_access
assign_owner
Pipelinelist
create
read
edit (update)
manual_trigger_execution
delete
Planlist
create
read
edit (update)
delete
Gatekeeper (coming soon)list
create
read
edit (update)
delete
Userlist
list_all_status
add
read
edit
suspend
disable
assign_global_admin
assign_workspace_admin
grant_workspace_access
revoke_workspace_access
Notification Receiver (coming soon)list
create
read
edit (update)
delete
activate
Tenantaccess
create
read
edit (update)
delete

Please note that this matrix is for reference only; the actual permissions are subject to the results within the application.

×

Still have questions?

Our team is here to help. Get in touch and we'll get back to you as soon as possible.