voiqq keeps customer work inside an organization workspace. The permission model starts with a verified account and an active organization membership, then narrows access through role, project membership, finding assignment, or a signed public-share grant. This layered model prevents a project link from becoming a substitute for membership and prevents ordinary collaborators from changing ownership.
The Team leader is the ownership boundary
Each workspace has one canonical owner represented by the Team leader role and the organization owner reference. Database rules prevent a second active owner and prevent owner removal through ordinary member actions. Projects owned by a departing member are reassigned through the protected membership workflow. A shared workspace must receive a new owner before the current owner can delete the account.
Workspace role matrix
- Team leader: ownership transfer, member-role changes, project deletion authority, plan and billing management, and all Team admin capabilities.
- Team admin: project creation and management, team invitations allowed by the role matrix, finding administration, and removal of eligible Workspace members.
- Workspace member: access to explicitly available projects and assigned findings, with finding actions controlled by project and database policies.
- Public visitor: no workspace membership. Access exists only after a project-specific Turnstile challenge and signed, short-lived share grant.
Invitation lifecycle
The Team page sends invitations through the existing invitation API. The server chooses the token and expiry, checks the inviter's role, stores the intended Team admin or Workspace member role, and emails the recipient. Acceptance verifies the current signed-in address and creates the organization membership in one protected flow. Rejected, expired, or revoked invitations do not create access.
Project and finding access
Team leaders and Team admins can manage projects in their workspace. Workspace members need project membership or an assigned finding according to the project policies. Finding updates still pass immutable ownership-field checks, assignment checks, and library mapping rules. A role therefore authorizes a class of work; it does not bypass project integrity.
Public share grants are isolated
A project set to Anyone with link can expose View only, Commenter, or Editor capability for that project. The share token must match the project, Turnstile must succeed, and the server issues a short-lived signed grant. Public editors cannot create or delete projects or findings, cannot manage team members, and never receive the private activity widget. Setting the project to Private invalidates the public path.
Audit trail and retention
Invitations, acceptance, rejection, removal, departure, and role changes create team activity records. Finding history remains attached to the finding. The activity widget is intended for collaboration signals and does not replace the detailed finding history. Retention limits keep operational feeds bounded while preserving the records needed for the current project workflow.
Permission review checklist
- Confirm the organization owner and Team leader identify the same active person.
- Review Team admins regularly and remove administrative access that is no longer needed.
- Use project membership and assignment instead of broadening workspace roles.
- Treat Commenter and Editor share links as external access and disable them when the review ends.
- Transfer ownership before removing the current owner or deleting that account.
- Test sensitive permission changes with a second account rather than relying on the interface label alone.