Roles and permissions

Per-project roles with five levels across fourteen sections, trimming access without ever adding permissions.

  • Category: Projects and companies
  • Status: Available
  • Requirements: Be the project manager to create and assign roles
  • MCP tools (Read only): listar_miembros_proyecto, ver_proyecto, ver_contexto_inicial

Markdown

What can you do with it?

LevelWhat it allows
ningunoDoes not see the section
verReads, does not touch
aportarCreates, and edits or deletes only its own
editarModifies anyone's content, without deleting
borrarFull control of the section

The configurable sections are: proyecto, etapas, tareas, comentarios, adjuntos, calendario, grabaciones, miembros, recursos, github, logs, papelera, finanzas and finanzas_balance. Reading and signing policies is not configurable: it is never denied to anyone.

When should you use it?

  • To add a client who comments and uploads files without being able to delete others' work.
  • So a collaborator only sees their part of the finances.

How does it work in ArduMaker?

  • Each project starts with 14 roles with full permissions (Client, Manager, Developer, DevOps, QA / Tester and others). They cannot be deleted but can be edited; the manager creates their own.
  • A role trims someone's access: it never adds permissions. A member with no assigned role can do everything.
  • Inside the project the project role rules, even if the person is a company admin. Only the system admin is above it.
  • The manager is whoever has a manager role, created the project, is an admin of an associated company, or is the system admin. The manager administers roles and policies, but their own role still limits them in the sections.
  • A new section a role has not written is resolved with its level for future sections.

What actually changes?

  • Changing a member's role changes their permissions and which policies they must sign, and is recorded in the history.
  • The project detail omits fields of sections the person cannot see.

Diagram

  1. Base access: member, admin or member of an associated company
  2. Project role: trims per section
  3. Pending policy: blocks entry until signed
  4. Effective permission: mis_permisos in the detail
How a permission is decided

Expected result

Each person sees in the project detail their effective permissions per section and whether they are a manager, so the interface shows only what they can do.

Errors and troubleshooting

  • An error of type permiso_de_rol means the role does not reach that section.
  • An error of type politica_pendiente means a policy still needs signing.
  • Only the project manager can change a member's role: only the manager reassigns roles.

MCP access

An MCP agent acts with its owner's permissions, trimmed by the scope it was given. It can read members and permissions, but never adds or removes members, changes roles or creates, edits or deletes roles.

  • listar_miembros_proyecto: members and their role.
  • ver_proyecto: includes the permisos block.
  • ver_contexto_inicial: the agent's scope and the operations no agent can perform.

See also MCP permissions and /mcp/docs.

Related features