Skip to main content
TaskFlow Pro uses role-based access control (RBAC) with three roles. Every user account is assigned exactly one role, stored as an integer in the database and embedded in their JWT token at login. All protected API routes check this role before allowing the action.

​
The three roles

Developer

Role value: 1. Works on assigned tasks. Can move their own tasks through the workflow but cannot create projects or manage other users.

Project Manager

Role value: 2. Creates and manages projects, assigns tasks, and oversees workflow progress across their own projects.

Admin

Role value: 3. Full platform access. Manages users, projects, and tasks across the entire system with no ownership restrictions.

​
How roles are assigned

The rol field on a user account defaults to 1 (Developer) on registration. Only an Admin can change a user’s role.
  • PUT /usuario — Admin sets any user’s role to any value
  • PUT /usuario/pm — Admin promotes a user to Project Manager (role 2)
Role changes take effect on the user’s next login. The JWT token is issued at login time and carries the role value that was active then. An existing token is not invalidated when a user’s role changes.

​
How the JWT carries role information

When a user logs in, the server signs a JWT containing the user’s id and rol:
token payload
{
  "id": 42,
  "rol": 2
}
The token expires after 30 minutes. Every protected request must include it in the Authorization header:
request header
Authorization: Bearer <token>
The authenticateToken middleware verifies the signature and decodes the payload into req.usuario. The authorizeRole middleware then performs a live database lookup to confirm the user’s current role before allowing the action.
The role is re-fetched from the database on every authorized request — not read from the token alone. This means a role change takes effect on the next request after the user’s token is re-issued at their next login.

​
What happens on an unauthorized request

If a user’s role is not in the allowed list for a route, the API returns:
403 response
{
  "mensaje": "No tienes permiso para esta acción"
}
If the token is missing entirely, the API returns 401. If the token signature is invalid, it returns 403 with a different message.

​
Permissions reference

The table below maps every action in the platform to the roles that can perform it.
ActionDeveloperProject ManagerAdmin
View own assigned tasks✓✓✓
Move own task to In Progress✓✓✓
Move own task to In Review✓✓✓
Move any task to In Progress—✓✓
Move any task to In Review—✓✓
Mark any task as Done—✓✓
View tasks by project—✓✓
Delete a task—✓✓
Create a task✓✓✓
Create a project—✓✓
View own projects—✓✓
Archive own project—✓—
Edit a project—✓✓
View all projects——✓
Archive any project——✓
Delete a project——✓
Edit any task (full edit)——✓
View all tasks (paginated)——✓
View all users——✓
Change user role——✓
Enable/disable a user account——✓
Edit any user account——✓
Search users—✓✓
Edit own profile✓✓✓
View own profile✓✓✓
Project Managers can only archive and manage projects where they are the owner_id. The service layer enforces this ownership check in addition to the role check, so a PM cannot modify another PM’s project even if they share the same role.

Build docs developers (and LLMs) love

Get started for freeTalk to us