Miembros y permisos de Autodesk: comprobar responsables con Issues API
En esta prueba apareció una diferencia que merece la pena ver antes de crear incidencias: una cuenta podía crear, pero no tenía empresa asignada para comprobar una asignación limitada a su misma empresa. He separado esas dos capacidades en Issues Manager. En esta entrega consultaremos los miembros del proyecto y los permisos de Issues para comprobar un posible responsable antes de enviar nada.
Entrar en el proyecto no responde a todas las preguntas
En la entrega anterior consultamos los proyectos accesibles con la cuenta conectada y comprobamos la selección en FastAPI. Eso permite situar el trabajo en una obra concreta. Todavía falta saber quién participa en ella y qué operaciones admite Autodesk para esa cuenta.
Imagina que quieres asignar la revisión de un encuentro entre instalaciones y estructura a una persona de otra empresa. Puede aparecer como miembro del proyecto y tener acceso a sus archivos, mientras tu permiso de incidencias solo permite asignar dentro de tu propia empresa. La lista de personas es correcta; la operación que quieres hacer con una de ellas necesita otra comprobación.
Por eso vamos a separar tres preguntas: si puedes utilizar nuestra demostración, si puedes consultar ese proyecto y si puedes realizar la operación sobre sus incidencias. La lista de acceso de Issues Manager resuelve la primera. Autodesk sigue siendo quien determina el acceso al proyecto y las capacidades sobre sus datos.
Autodesk vuelve a pedir un permiso de lectura
Para consultar los miembros añadimos account:read a los permisos que ya teníamos: lectura del perfil y lectura de datos. El nombre puede resultar amplio, pero aquí se utiliza para consultar información de los miembros mediante la API Admin. Esta versión no solicita permisos de escritura ni permite añadir personas, cambiar sus accesos o modificar incidencias.
Si estás siguiendo el código desde la entrega anterior, desconecta Autodesk en Issues Manager y vuelve a iniciar sesión. Revisa el nuevo consentimiento antes de aceptarlo. La renovación del token anterior conserva sus permisos; no añade el nuevo acceso de lectura por el hecho de haber actualizado la aplicación.
Mantenemos el mismo Client ID, el secreto privado y el callback. En APS debes tener habilitado el acceso a las APIs de construcción y la integración debe estar registrada en la cuenta, como vimos al consultar los proyectos. El secreto continúa en el servidor: no se pega en el navegador ni se comparte para probar este paso.
Una consulta para los miembros y otra para tus capacidades
Los miembros se obtienen con Admin API, que devuelve sus identificadores, nombres, correos, empresa y estado, entre otros datos. Nuestra aplicación conserva solo los campos necesarios para presentar la elección y comprobarla. También recorre las páginas del listado: quedarse con la primera podría hacer desaparecer precisamente a la persona que buscas.
Para decidir qué acciones puede realizar la cuenta utilizo la respuesta de Issues /users/me. El listado de miembros nos dice quién está en el proyecto; esta otra consulta aporta las capacidades sobre incidencias. Necesitamos ambas para que el selector no prometa una asignación que después rechazará Autodesk.
En las pruebas, cambiar el nivel de acceso del hub y del proyecto no bastó para que Issues dejase de devolver el indicador de administrador. Por eso conservo el valor que responde cada API y baso la decisión en sus acciones y atributos permitidos. El nombre de un rol, por sí solo, se queda corto para resolverla.
Las consultas son independientes. Si Admin deniega la lectura de miembros, la aplicación muestra ese error y puede seguir mostrando las capacidades que Issues sí haya devuelto. Una denegación tampoco se convierte en «no hay miembros». En ese caso hay que revisar el consentimiento, la integración y el acceso de esa cuenta a la API correspondiente.
Con la cuenta administradora, Issues confirmó creación de incidencias y asignación a miembros de cualquier empresa. La captura corresponde a una consulta de lectura.
Dos personas pueden llamarse igual
Al buscar un responsable, el nombre sirve para reconocer a la persona, pero no para identificarla de forma inequívoca. En un proyecto puede haber dos personas llamadas igual, o un nombre incompleto que resulte poco útil. Elegir automáticamente la primera coincidencia podría mandar la incidencia a quien no corresponde.
El selector muestra nombre, correo, empresa e identificador Autodesk. La búsqueda permite reducir la lista, pero la elección final conserva una identidad concreta. La API también puede resolver un nombre exacto; si encuentra varias coincidencias, devuelve un aviso de ambigüedad en lugar de escoger una.
Hay otro detalle que importa al conectar las APIs: el identificador del miembro en Admin y su identificador Autodesk son campos distintos. Para preparar una asignación a una persona utilizamos la identidad Autodesk que requiere Issues. Los miembros pendientes de activación o sin esa identidad disponible no se ofrecen como responsables comprobables.
La referencia de miembros del proyecto permite consultar esos campos. En el código, la respuesta se prepara en MemberService y el selector se presenta desde ProjectMembers. El navegador recibe los datos para elegir; los tokens siguen custodiados por FastAPI.
Qué ocurre si solo puedes asignar dentro de tu empresa
Issues puede permitir la asignación a miembros de cualquier empresa o limitarla a la propia. En el segundo caso necesitamos conocer la empresa que representa al usuario conectado y la del posible responsable dentro del proyecto. No basta con que ambos tengan un correo parecido o compartan un dominio.
Al comprobar la selección, el servidor busca al usuario conectado por su identificador Autodesk y compara empresas identificadas. Si son distintas, no confirma la asignación. Si falta la empresa de cualquiera de los dos, tampoco supone que coinciden: devuelve que falta información para comprobarlo.
La cuenta de la prueba no tenía empresa asignada. Con la regla de «misma empresa», la aplicación devolvió company_not_confirmed: faltaba el dato necesario para comparar. He preferido dejar la asignación pendiente antes que interpretar una empresa vacía como coincidencia. El fragmento del final de esta sección pertenece a la rama same_company de MemberService.check_assignee, en apps/api/app/members/service.py. Compara los identificadores de empresa después de resolver al responsable y consultar las capacidades.
Una cuenta miembro puede conservar capacidad para crear incidencias; ser miembro no equivale a carecer de todas las operaciones. En la prueba, Admin e Issues acabaron reflejando que la cuenta no era administradora y las capacidades de asignación quedaron limitadas a su empresa. Para saber qué puede hacer una persona hay que consultar ese contexto concreto.
La cuenta miembro puede consultar el proyecto y sus miembros. La comprobación se detiene porque no tiene empresa asignada y no se puede confirmar la coincidencia.
# Fragmento de MemberService.check_assignee, dentro de la rama same_company.
current = [
m for m in members
if m.autodesk_id == profile.user_id and m.status == "active"
]
if len(current) != 1 or not current[0].company_id or not target.company_id:
reason = "company_not_confirmed"
elif current[0].company_id != target.company_id:
reason = "assignment_other_company"
Comprobar un responsable todavía no asigna la incidencia
El botón Comprobar responsable sin asignar vuelve a consultar el proyecto accesible, la lista de miembros y las capacidades de Issues. Se comprueba el estado activo de la persona, su identidad y el ámbito de asignación. Un resultado compatible sirve para preparar la operación; no crea una incidencia ni guarda una asignación en Autodesk.
La comprobación se hace de nuevo porque los permisos y la pertenencia al proyecto pueden cambiar después de cargar un desplegable. Si cambias de proyecto o de persona, la interfaz retira el resultado anterior. El servidor tampoco acepta una selección simplemente porque el navegador diga que ya la había comprobado.
Además, esta entrega prepara el contexto de una incidencia nueva. Para modificar una existente habrá que consultar también qué campos, estados y acciones permite esa incidencia en ese momento. La capacidad general de crear o asignar no da permiso para editar cualquier elemento del proyecto.
El recorrido se ha comprobado con Autodesk: lectura de miembros y capacidades, un responsable compatible con la cuenta administradora y el bloqueo por empresa no informada con la cuenta miembro. Los casos de homónimos y empresas distintas se han probado con datos sintéticos. En ninguno de estos pasos se ha creado ni modificado una incidencia real.
Llévate el código de la serie
Suscríbete a la newsletter de Código BIM y te enviaré el repositorio con las instrucciones para elegir la versión de cada artículo. Un mismo recurso para seguir toda la serie, desde el login con Autodesk hasta el futuro servidor MCP.
El correo incluye el acceso a todas las versiones de la serie. Podrás darte de baja de la newsletter cuando quieras.
Siguiente paso: trabajar con las incidencias del proyecto
El resultado útil de esta entrega es poder elegir una persona y saber por qué la asignación está permitida o bloqueada. Crear una incidencia y asignarla tienen condiciones distintas; ya tenemos un lugar para comprobar cada una antes de incorporar la escritura.
En la siguiente entrega consultaremos las incidencias y sus tipos, y prepararemos la primera creación con revisión previa. La escritura tendrá su propio paso de confirmación. Ese mismo criterio seguirá cuando más adelante una hoja Excel o un agente de IA propongan varias operaciones.
Respuestas