Identidad, roles, conjuntos de permisos, acceso a registros y seguridad de campos — todo el modelo de acceso en una sola página.

Permisos

ObjectOS tiene un modelo de acceso en capas tomado del manual que ha funcionado en el software empresarial durante dos décadas: identidad → roles → conjuntos de permisos → acceso a registros → seguridad de campos. Cada capa responde a una pregunta diferente, y puedes ignorar las que no necesites.

El modelo en un solo diagrama

Authentication       Who is the caller?
        ↓
Identity             Which user/org/membership is active?
        ↓
Roles                Where do they sit in the hierarchy?
        ↓
Permission sets      What CAN they do — apps, objects, fields, system?
        ↓
Record access        WHICH records can they touch?
        ↓
Field security       For those records, which FIELDS are readable / writable?

Cada capa es aplicada por el plugin de seguridad. Puedes usar solo conjuntos de permisos (sin roles, sin reglas de uso compartido) para aplicaciones simples y añadir el resto a medida que aparezca el requisito.

Capa 1 — Identidad

Los objetos de identidad residen en la base de datos de tu proyecto. Los más importantes:

Objeto	Qué representa
`sys_user`	Una persona o cuenta de servicio que puede autenticarse
`sys_organization`	Límite de inquilino / espacio de trabajo (aplicaciones multiinquilino)
`sys_member`	La pertenencia de un usuario a una organización (rol asignado por pertenencia)
`sys_department`, `sys_team`	Estructura organizativa opcional para las reglas de uso compartido
`sys_invitation`	Invitación pendiente a la espera de ser aceptada
`sys_session`	Sesión autenticada activa
`sys_api_key`	Credencial programática de larga duración vinculada a un usuario

En un despliegue multiinquilino:

Los usuarios están delimitados a la base de datos del proyecto.
Las sesiones están delimitadas al nombre de host del proyecto.
Las comprobaciones a nivel de fila usan la organización y los permisos del usuario actual.
Los usuarios del plano de control no son automáticamente usuarios de negocio — deben mapearse mediante SSO de la plataforma o aprovisionamiento explícito.

Creas/gestionas estos desde la Console (/_console/) en tiempo de ejecución, o los precargas en objectstack.config.ts para entornos nuevos.

Capa 2 — Roles

Los roles modelan el organigrama (CFO → Gerente de Finanzas → Analista). Existen principalmente para que las reglas de uso compartido y los informes puedan decir cosas como "el gerente del propietario del registro". Usa roles cuando necesites acceso jerárquico; omítelos para equipos planos.

Consulta Roles.

Capa 3 — Conjuntos de permisos

Los conjuntos de permisos son la forma principal de otorgar capacidades. Se adjuntan a los usuarios directamente o a través de roles.

Qué otorgan

Tipo	Ejemplos
Acceso a aplicaciones	Abrir CRM, abrir el portal de soporte
Permisos de objeto	Crear / leer / actualizar / eliminar registros de un objeto
Permisos de campo	Leer o actualizar campos específicos
Permisos de sistema	Acceder a Console, ejecutar informes, exportar datos, ver el registro de auditoría
Permisos de integración	Usar claves de API, configurar webhooks, ejecutar acciones de administrador

Indicadores de permisos de objeto

Estos son los nombres exactos de los indicadores que comprueba el plugin de seguridad:

Indicador	Significado
`allowRead`	Leer registros que el usuario puede ver mediante el acceso a registros
`allowCreate`	Crear nuevos registros
`allowEdit`	Actualizar registros que el usuario puede ver
`allowDelete`	Eliminar registros que el usuario puede ver
`viewAllRecords`	Leer todos los registros del objeto, ignorando las reglas de acceso a registros
`modifyAllRecords`	Actualizar/eliminar todos los registros; implica `viewAllRecords`

viewAllRecords y modifyAllRecords son concesiones de superusuario a nivel de inquilino para ese objeto. Resérvalas para conjuntos de permisos administrativos explícitos y mantenlas fuera de cualquier rol orientado al usuario.

Consulta Permission Sets.

Capa 4 — Acceso a registros

Para los usuarios sin viewAllRecords, ¿qué filas pueden ver?

El modelo admite:

Propiedad implícita (filas que el usuario creó o posee)
Reglas de uso compartido (declarativas — "el equipo A ve los registros del equipo A")
Compartidos explícitos (filas sys_record_share — compartidos puntuales)
Delimitación por organización (el organization_id de la fila coincide con la organización del usuario)

Consulta Record Access.

Capa 5 — Seguridad de campos

Incluso cuando un usuario puede ver un registro, los campos individuales pueden ser:

Ocultos — el campo se elimina de las respuestas de la API y la UI.
De solo lectura — el campo se devuelve pero se rechaza al escribir.

La seguridad de campos es por objeto + por conjunto de permisos. Uso típico:

Ocultar salary en sys_user a cualquiera fuera de RR. HH.
Hacer que external_account_id sea legible pero no editable para los representantes de soporte.

Se aplica en el mismo evaluador que los permisos de objeto, por lo que se aplica de manera uniforme en REST, ObjectQL y Console.

Por dónde empezar

Si estás construyendo …	Usa
Una herramienta interna de un solo equipo	Solo conjuntos de permisos
Una aplicación multiequipo con gerentes que ven informes	Roles + conjuntos de permisos
Una aplicación con forma de SaaS multiinquilino	Delimitación por organización + conjuntos de permisos
Una aplicación regulada con PII	Añade seguridad de campos por encima
Una aplicación compleja estilo CRM	La pila completa

Diagnosticar y auditar

/_console/ muestra los permisos efectivos de cualquier usuario tal como se evalúan.
El registro de auditoría (sys_audit_log) registra los cambios sensibles a permisos — concesiones, asignaciones de roles, ediciones de conjuntos de permisos.
Las solicitudes denegadas registran la regla que falló (permiso de objeto vs acceso a registros vs seguridad de campos) para que el soporte pueda responder rápidamente "¿por qué no puedo ver esto?".

Permisos

On this page