Establecimiento de permisos de seguimiento de trabajo

Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019 | TFS 2018

Conceda o restrinja el acceso a varias características de seguimiento de trabajo concediéndoles permisos específicos a usuarios o grupos para un objeto, proyecto o colección. O bien, puede especificar reglas personalizadas para un proceso o proyecto que se aplique a usuarios o grupos que pueden restringir o requerir que los usuarios realicen una acción de selección. En general, querrá agregar usuarios al grupo Colaboradores de un proyecto para proporcionar acceso a la mayoría de las características, como se muestra en Permisos y acceso para el seguimiento del trabajo.

Nota

En el caso de los proyectos públicos, el acceso de las partes interesadas proporciona a los usuarios un mayor acceso a las características de seguimiento del trabajo y acceso total a Azure Pipelines. Para más información, consulte Referencia rápida sobre el acceso a las partes interesadas.

Requisitos previos

  • Para establecer permisos de seguimiento de trabajo, debe ser miembro del grupo Administradores de proyectos o tener permisos explícitos para administrar el área de seguimiento de trabajo, como se describe en este artículo.
  • Para establecer permisos de proceso, debe ser miembro del grupo Administradores de colecciones de proyectos o tener permisos explícitos para editar un proceso de recopilación.

Compatibilidad con flujos de trabajo empresariales mediante reglas personalizadas

Las reglas personalizadas no establecen permisos, pero afectan a los permisos efectivos de un usuario en tiempo de ejecución para modificar un elemento de trabajo o establecer el valor de un campo de elemento de trabajo. Azure Boards admite las siguientes personalizaciones de seguimiento de trabajo que admiten flujos de trabajo.

  • Aplique reglas de selección tras la creación de elementos de trabajo, el cambio de estado y el estado especificado.
  • Aplicar reglas de selección cuando un valor de campo está vacío, se establece en un valor específico o se cambió o no a un valor.
  • Restrinja la transición a un estado específico al pasar de un estado especificado.
  • Aplicar reglas de selección basadas en la pertenencia a un usuario o grupo del usuario que modifica un elemento de trabajo.

Entre las acciones comunes establecidas por reglas se incluyen las siguientes:

  • Hacer que un campo sea obligatorio o de solo lectura
  • Borrar o establecer el valor de un campo o copiar un valor de campo en otro campo
  • Ocultar un campo.

Por ejemplo, puede especificar reglas que restrinjan eficazmente a un grupo de usuarios que realicen las siguientes tareas:

  • Crear un elemento de trabajo
  • Transición de un elemento de trabajo a un estado cerrado o completado
  • Cambiar el valor de un campo.

O bien, realice las siguientes automatizaciones:

  • Reasignar un elemento de trabajo en función del cambio de estado
  • Transiciones de estado de los elementos de trabajo primarios en función de los cambios de estado realizados en sus elementos de trabajo secundarios.

Algunas restricciones se aplican a la aplicación de reglas personalizadas a los campos del sistema. Por ejemplo, no puede especificar reglas que establezcan o desactiven el valor de Ruta de acceso del área o ruta de acceso de iteración, ya que son campos del sistema. Para obtener más información sobre las reglas personalizadas, puede definir y restricciones de campo del sistema en reglas personalizadas, consulte Reglas y evaluación de reglas. Para ver escenarios de ejemplo que definen reglas personalizadas, consulte Escenarios de reglas de ejemplo.

Roles de seguimiento de trabajo y niveles de permisos

En la tabla siguiente se resumen los distintos permisos que puede establecer en el nivel de objeto, proyecto o colección. El rol de administrador de equipo proporciona acceso para agregar y modificar recursos del equipo.


Nivel de rol o permiso

Conjunto de áreas funcionales


Rol de administrador de equipo
Para agregar un usuario al rol de administrador de equipo, consulte Agregar un administrador de equipo.


Permisos a nivel de compilación


Permisos de nivel de proyecto


Permisos de nivel de colección de proyectos


Nota

Si aún no ha definido el grupo cuyos permisos desea establecer, primero cree el grupo, normalmente en el nivel de proyecto. Para obtener información sobre cómo, consulte Agregar o quitar usuarios o grupos, administrar grupos de seguridad.

Crear nodos secundarios, modificar elementos de trabajo en un área o ruta de acceso de iteración

Los permisos de ruta de acceso de área permiten conceder o restringir el acceso para editar o modificar elementos de trabajo, casos de prueba o planes de prueba asignados a esas áreas. Puede restringir el acceso a usuarios o grupos. También puede establecer permisos para quién puede agregar o modificar áreas o iteraciones para el proyecto.

Nota

Los miembros del proyecto conceden permisos para crear o editar rutas de acceso de área o rutas de acceso de iteración es independiente de los permisos que controlan la configuración de las rutas de acceso de área del equipo y las rutas de iteración. Para configurar la configuración del equipo, debe agregarse al rol de administrador de equipo o ser miembro del grupo Administradores de proyectos. *

Puede definir ambas áreas e iteraciones para un proyecto a partir de la configuración del proyecto configuración>del proyecto.

  1. Elija (1) Configuración del proyecto, elija (2) Configuración del proyecto en Paneles y, después, elija (3) Áreas o iteraciones para modificar rutas de acceso de área o rutas de iteración .

    Captura de pantalla que muestra la apertura de configuración del>proyecto Configuración del proyecto Configuración>del proyecto.

  2. Elija el menú contextual ... para el nodo que desea administrar y seleccione Seguridad.

    Captura de pantalla del menú contextual de Ruta de acceso del área, elija Seguridad.

  3. Seleccione el grupo o el miembro del proyecto y, a continuación, cambie la configuración de permisos. Para agregar un usuario o grupo, escriba su nombre en el cuadro de búsqueda.

    Por ejemplo, aquí agregamos el grupo de acceso No permitir y no se permite a los miembros de este grupo la capacidad de ver, modificar o editar elementos de trabajo en la ruta de acceso del área Administración de cuentas.

    Captura de pantalla del nodo De ruta de acceso de área Seguridad, grupo seleccionado y configuración de Permisos de denegación.

    Puede especificar dos estados de autorización explícitos para los permisos: Denegar y Permitir. Además, los permisos pueden existir en uno de los tres estados adicionales. Para más información, consulte Introducción a los permisos, el acceso y los grupos de seguridad.

  4. (Opcional) Elija el control deslizante Herencia para deshabilitar la herencia. Al deshabilitar la herencia, se conservan todos los permisos heredados como entradas de Access Control explícitas (ACE).

  5. Cuando haya terminado, simplemente cierre el cuadro de diálogo. Los cambios se guardan automáticamente.

Puede definir ambas áreas e iteraciones para un proyecto a partir de la configuración del proyecto configuración>del proyecto.

  1. Elija (1) Configuración del proyecto, elija (2) Configuración del proyecto en Paneles y, después, elija (3) Áreas.

    Captura de pantalla que muestra la apertura de configuración del>proyecto Configuración del proyecto Configuración>del proyecto para el servidor local.

  2. Elija el menú contextual ... para el nodo que desea administrar y seleccione Seguridad.

    Captura de pantalla del menú contextual de Ruta de acceso del área, elija Seguridad, Azure DevOps Server 2020.

  3. Seleccione el grupo o miembro de equipo y, a continuación, cambie la configuración de permisos. Para agregar un usuario o grupo, escriba su nombre en el cuadro de búsqueda.

    Por ejemplo, aquí se ha agregado el grupo de acceso No permitir y no se permite a los miembros de este grupo la capacidad de ver, modificar o editar elementos de trabajo en la ruta de acceso del área servicio al cliente.

    Captura de pantalla del nodo Ruta de acceso de área Seguridad, grupo seleccionado y configuración de Permisos de denegación, Azure DevOps Server 2020 y versiones anteriores.

    Puede especificar dos estados de autorización explícitos para los permisos: Denegar y Permitir. Además, los permisos pueden existir en uno de los tres estados adicionales. Para más información, consulte Introducción a los permisos, el acceso y los grupos de seguridad.

  4. (Opcional) Cambie Herencia a Desactivado para deshabilitar la herencia. Deshabilitar la herencia conserva todos los permisos heredados como entradas de Access Control explícitas (ACE).

  5. Cuando haya terminado, elija Guardar cambios.

  1. En el portal web del proyecto, elija el icono de engranaje.

    Captura de pantalla que muestra la apertura del portal web, Abrir Administración contexto, nivel de proyecto para TFS 2018.

    Si actualmente trabaja desde un contexto de equipo, mantenga el puntero sobre el icono de engranaje y elija Configuración del proyecto.

    Abra Configuración del proyecto para TFS 2018.

  2. Elija Trabajo y, a continuación, Áreas.

  3. Elija ... menú contextual del nodo que desea administrar y seleccione Seguridad.

    En el menú contextual, seleccione Seguridad para TFS 2018.

Establecimiento de permisos en consultas o carpetas de consulta

Puede especificar quién puede agregar o editar carpetas de consulta o consultas en el nivel de objeto. Para administrar permisos para una carpeta de consulta o consulta, debe ser el creador de la consulta o carpeta, un miembro del grupo Administradores de proyectos o Administradores de colección de proyectos, o conceder acceso explícito a través del cuadro de diálogo Seguridad del objeto.

Cuadro de diálogo Permisos de carpeta de consulta

Cuadro de diálogo Permisos para una carpeta de consulta.

Para más información, consulte Establecimiento de permisos en una consulta compartida o carpeta de consulta. Para más información sobre las consultas, consulte Creación de consultas administradas para enumerar, actualizar o gráficos elementos de trabajo.

Establecimiento de permisos en etiquetas de elementos de trabajo

De forma predeterminada, todos los usuarios del grupo Colaboradores pueden crear y agregar etiquetas a los elementos de trabajo. Para establecer permisos para un grupo o usuario que restrinja esta capacidad, puede establecer la definición crear etiqueta en Denegar en el nivel de proyecto. Para obtener información sobre cómo hacerlo, consulte Cambio del nivel de permiso de un grupo de nivel de proyecto.

Edición o administración de permisos para planes de entrega

Los planes de entrega son un objeto dentro de un proyecto. Los permisos del plan se administran de forma similar a la forma en que se administran los permisos para las consultas compartidas o las carpetas de consulta. El creador de un plan de entrega, así como todos los miembros de los grupos Administradores de colecciones de proyectos y Administradores de proyectos, tienen permisos para editar, administrar y eliminar planes.

Cuadro de diálogo Permisos del plan de entrega

Cuadro de diálogo Permisos para un plan de entrega.

Para más información, consulte Editar o administrar permisos del plan de entrega. Para más información sobre los planes de entrega, consulte Revisión de los planes de equipo.

Mover o eliminar permanentemente elementos de trabajo

De forma predeterminada, los administradores y colaboradores de proyectos pueden cambiar el tipo de elemento de trabajo y eliminar elementos de trabajo si los mueven a la Papelera de reciclaje. Solo los administradores de proyectos pueden eliminar permanentemente elementos de trabajo y probar artefactos. Los administradores del proyecto pueden conceder permisos a otros miembros del equipo según sea necesario.

Por ejemplo, como administrador de proyectos, puede conceder a un usuario, grupo de equipo u otro grupo que haya creado para tener estos permisos. Abra la página Seguridad del proyecto y elija el usuario o grupo que desea conceder permisos. Para obtener información sobre cómo acceder a la seguridad de nivel de proyecto, consulte Cambio de permisos de nivel de proyecto.

Nota

El permiso Mover elementos de trabajo fuera de este proyecto requiere que el proyecto use el modelo de proceso heredado.

En este ejemplo, se conceden a los miembros asignados al rol de administrador de equipo, que pertenecen a los grupos de Team Administración, permisos para mover elementos de trabajo a otro proyecto y eliminar permanentemente elementos de trabajo.

Captura de pantalla que muestra la configuración de permisos de nivel de proyecto para un grupo de seguridad personalizado.

Administración de planes de pruebas y conjuntos de pruebas

Además de los permisos de nivel de proyecto establecidos en la sección anterior, los miembros del equipo necesitan permisos para administrar artefactos de prueba que se establecen para una ruta de acceso de área.

Abra la página Seguridad para las rutas de acceso de área y elija el usuario o grupo que desea conceder permisos.

Captura de pantalla que muestra los permisos de ruta de acceso del área abiertos para el proyecto.

Establezca los permisos para Administrar planes de prueba y Administrar conjuntos de pruebas en Permitir.

Captura de pantalla que establece permisos de ruta de acceso de área para el proyecto.

Para tener acceso completo al conjunto de características de prueba, el nivel de acceso debe establecerse en Básico + Test Plans. Los usuarios con acceso básico y con permisos para eliminar permanentemente elementos de trabajo y administrar artefactos de prueba solo pueden eliminar casos de prueba huérfanos.

Personalización de un proceso heredado

De forma predeterminada, solo los administradores de colecciones de proyectos pueden crear y editar procesos. Sin embargo, estos administradores pueden conceder permisos a otros miembros del equipo estableciendo explícitamente los permisos Crear proceso, Eliminar proceso o Editar proceso en el nivel de colección para un usuario específico.

Para personalizar un proceso, debe conceder permisos de proceso de edición a una cuenta de usuario para el proceso específico.

Nota

Los usuarios agregados al grupo Usuarios con ámbito de proyecto no podrán acceder a la configuración del proceso si la característica Limitar la visibilidad del usuario y la colaboración a proyectos específicos en versión preliminar está habilitada para la organización. Para más información, consulte Administrar su organización, Limitar la visibilidad del usuario para proyectos y mucho más.

  1. Abra ... menú contextual del proceso heredado y elija Seguridad. Para abrir esta página, consulte Personalización de un proyecto mediante un proceso heredado.

    Captura de pantalla que muestra el cuadro de diálogo Abrir proceso, Abrir seguridad.

  2. Agregue el nombre de cuenta de la persona a la que desea conceder permisos, establezca los permisos en Permitir que quiera que tengan y, a continuación, elija Guardar cambios.

    Aquí agregamos la Iglesia de Cristina y le permitimos editar el proceso.

    Permisos para un diálogo de proceso.

Nota

Cada proceso es una unidad protegible y tiene listas de control de acceso individuales (ACL) que rigen la creación, edición y eliminación de procesos heredados. En el nivel de colección, los administradores de colecciones de proyectos pueden elegir qué procesos se pueden heredar de y de quién. Al crear un nuevo proceso heredado, el creador del proceso, así como los administradores de colecciones de proyectos, tienen control total del proceso y también pueden establecer ACL individuales para que otros usuarios y grupos editen y eliminen el proceso.

Opciones adicionales para restringir el acceso a los elementos de trabajo

Consulte Restringir el acceso, Restringir la modificación de elementos de trabajo en función de un usuario o grupo para obtener opciones adicionales para personalizar los tipos de elementos de trabajo para admitir restricciones.