#Roles Overview – Access Control Guide
Roles define what users can see and do inside Hawzu. Hawzu’s role system is designed to be clear, additive, and transparent, making it easy to understand exactly who has access to what — and why.
#Role Hierarchy in Hawzu
Hawzu uses a two-level role model:
- Workspace Roles – Control access at the workspace level
- Project Roles – Control access within individual projects
Workspace roles define administrative scope.
Project roles define functional access.
#Workspace Roles
Workspace roles control what a user can do across the entire workspace, independent of any specific project.
#Available Workspace Roles
#Owner
- Full control over the workspace
- Manage users, groups, roles, integrations, and settings
- Create and delete projects
- Cannot be removed or downgraded by others
#Workspace Manager
- Invite and manage workspace users
- Assign users and groups to projects
- Manage groups
- Cannot modify workspace-level configurations
#Workspace Coordinator
- Assist with workspace organization
- View users, groups, and projects
- Limited management capabilities
- No destructive permissions
#Workspace Member
- Standard workspace access
- No administrative privileges
- Project access depends entirely on project roles
#Workspace Viewer
- Read-only access to workspace-level information
- Cannot modify users, groups, or projects
Workspace roles do not automatically grant project access.
#Project Roles
Project roles define what actions a user can perform inside a specific project.
#Available Project Roles
#Project Manager
- Full control over the project
- Manage test cases, test runs, releases, and defects
- Manage project users and roles
- Configure project-level settings
#Project Coordinator
- Coordinate test execution activities
- Create and update test cases and executions
- Manage defects and releases
- Limited administrative permissions
#Project Member
- Execute test cases
- Create and update defects
- Contribute to executions and test runs
- No project-level configuration access
#Project Viewer
- Read-only access to project data
- View test cases, executions, defects, and reports
- No modification permissions
#Role Assignment Methods
Users can receive project roles in two ways:
#1. Direct Assignment
- Assigned explicitly to a user
- Clearly visible in access views
- Ideal for individual or exception-based access
#2. Group-Based Assignment
- Users inherit roles through group membership
- Groups are assigned roles per project
- Access updates automatically when group membership changes
#Direct, Inherited, and Combined Access
Hawzu clearly distinguishes how access is granted:
- Direct – Assigned explicitly to the user
- Inherited – Gained through one or more groups
- Both – Assigned directly and inherited via groups
#Effective Permission Calculation
Hawzu uses an additive permission model:
Direct Project Roles
• Group-Inherited Project Roles
= Effective Permissions
#Important Characteristics
- No deny rules
- No hidden overrides
- Multiple roles can coexist
- Permissions are never silently removed
If a user has access, Hawzu always shows where it came from.
#Why Hawzu Uses Additive Roles
This model ensures:
- Predictable permission behavior
- Easy debugging and audits
- Clear access explanations for teams
- Enterprise-friendly compliance and reviews
#Best Practices
- Use groups for team-based access
- Use direct roles sparingly for exceptions
- Keep workspace roles minimal
- Review access regularly using Access Overview
- Prefer project roles over workspace roles for day-to-day control
#Next Steps