Creación de un flujo de trabajo de lanzamiento personalizado

Cuando configure un flujo de trabajo de lanzamiento personalizado que incluya dos niveles y el segundo nivel no sea necesario (es decir, el segundo nivel sea opcional), Onshape pasará automáticamente de Pendiente a Lanzado si no hay ningún aprobador especificado en el paquete de lanzamiento. No se requiere ninguna configuración para esto, los únicos requisitos son que tenga un flujo de trabajo de dos niveles, que el segundo nivel sea opcional y que no hayan aprobadores especificados en el campo Aprobador del candidato de lanzamiento.

Para descargar los archivos de flujo de trabajo predeterminados de Onshape, haga lo siguiente:

1. Diríjase a la Configuración de Enteprise y seleccione Administración de lanzamientos.
2. Confirme que esté activada la casilla Habilitar flujos de trabajo administrados y, a continuación, haga clic en Ver en documento.

   

   El archivo de flujo de trabajo se abre en un documento público en otra pestaña.

3. Haga clic en Descargar e ingrese un nombre nuevo para el archivo.
   

   Puede cerrar esa pestaña una vez que se haya descargado.

1. En su empresa, vaya a la página Documentos, seleccione Crear > Documento y, a continuación, seleccione Aceptar. (En este ejemplo, el nombre del documento es Flujos de trabajo personalizados de la compañía)
2. En el nuevo documento, haga clic en el icono más de la parte inferior y seleccione Importar:

3. Seleccione el archivo de flujo de trabajo que acaba de descargar y haga clic en Abrir.
4. Aparecerá otra pestaña en el documento, con el nombre del archivo importado. Seleccione esa pestaña para abrirla:

Puede utilizar acciones de flujo de trabajo de FeatureScript para actualizar de forma programática las propiedades de los elementos de lanzamiento como parte de una transición de flujo de trabajo. Al apuntar el flujo de trabajo personalizado a un Feature Studio en la misma área de trabajo que la definición del flujo de trabajo, se puede ejecutar una función en ese Feature Studio como una acción que determina las actualizaciones de propiedades que se aplicarán a cada elemento de lanzamiento.

Para utilizar esta opción en un flujo de trabajo personalizado, use la acción de flujo de trabajo updateItemPropertiesFromFeatureScript como una acción de transición o una acción de entrada o salida en un estado. La acción toma los siguientes parámetros:

• ID de FeatureStudio: Feature Studio debe residir en la misma área de trabajo que la definición de flujo de trabajo de lanzamiento personalizada

• Nombre de una función exportado por ese Feature Studio: esta función debe tomar un solo argumento que tenga el tipo: map. El tipo Map que se pasa a la función cuando se ejecuta contiene los siguientes datos:

{

// El paquete de lanzamiento completo y detallado, que incluye todos los elementos y propiedades

// (como lo devolvería la API de REST getReleasePackage)

"releasePackage": BTReleasePackageInfo,

// El usuario que realiza la transición

"currentUser": BTUserSummaryInfo,

// El usuario que creó el candidato de lanzamiento en primera instancia

"releaseCreator": BTUserSummaryInfo,

// La transición que se está ejecutando, tal como aparece en la definición del flujo de trabajo

"transition": BTTransitionDef,

// La fecha/hora UTC actual, como una cadena de fecha ISO

"currentDate": string

}

La función debe devolver un mapa del formulario:

{[key: string]: {[key: string]: any}}

El mapa principal se identifica mediante el ID de elemento de lanzamiento, y el mapa interno va desde el ID de propiedad de metadatos a un nuevo valor deseado. Por ejemplo, si la función devuelve el siguiente mapa, sucede lo siguiente:

{

"item1": {

"57f3fb8efa3416c06701d616": "Nuevo valor",

"customIntProperty": 42

},

"item2": {

"57f3fb8efa3416c06701d617": "Algún otro valor"

}

}

Luego, en el elemento Lanzamiento con ID “item1” (Elemento 1), la propiedad “Title 1” (Título 1) se establecerá en la cadena “New Value” (Nuevo valor), y una propiedad personalizada hipotética (CustomIntProperty, anterior) se establecerá en el número 42. En el elemento con ID “item2” (Elemento 2), la propiedad “Title 2” (Título 2) se establecerá en la cadena “Some other value” (Algún otro valor).

La información completa del paquete de lanzamiento se proporciona como entrada a la función, de modo que se pueden aplicar filtros y cálculos adicionales según se desee. Por ejemplo, aplicar una propiedad solo a elementos que son dibujos, o solo a elementos que tienen una categoría determinada, o calcular un valor de propiedad a partir de otro valor de propiedad.

Es importante tener en cuenta que el FeatureScript en sí no aplica ningún cambio en el paquete de lanzamiento; cualquier modificación realizada en los datos de entrada no sobrevivirá a la ejecución de FeatureScript. En cambio, es el valor que devuelve la función lo que indica al sistema qué cambios debe realizar.

Tipos de valor de propiedad

El tipo de valor en el mapa devuelto debe coincidir con el tipo de valor de la propiedad de metadatos correspondiente (ya que se enviaría a la API de “actualizar metadatos”); un valor no válido provocará que falle la actualización de una propiedad.

Una propiedad de metadatos de tipo usuario acepta una matriz de objetos del formulario:

{"id": [userId]}

Una propiedad de flujo de trabajo de tipo usuario contiene una matriz de objetos en los que el ID de usuario se encuentra en el campo “entryId”. Por lo tanto, para agregar un usuario de una propiedad de flujo de trabajo a una propiedad de metadatos, el valor debe transformarse en el formato correcto.

Una propiedad de metadatos de tipo usuario solo acepta ID de usuario, no ID de equipo ni de rol. Para aplicar una propiedad de flujo de trabajo de tipo Usuario a una propiedad de metadatos de tipo Usuario, use solo las entradas de la propiedad del flujo de trabajo que sean usuarios, aquellas con un “EntryType” (tipo de entrada) de 0 (cero).

Si alguna actualización de propiedad falla debido a un ID de propiedad o un valor incorrectos en el objeto devuelto, la acción del flujo de trabajo fallará y los errores se registrarán para que los desarrolladores del flujo de trabajo los utilicen para depurar (consulte Depuración del flujo de trabajo a continuación).

La acción también falla si se produce un error durante la ejecución de FeatureScript o si el objeto devuelto está mal formado, por ejemplo, si el objeto devuelto no es un mapa de ID de elemento para actualizaciones de propiedades.

Si la acción falla, es probable que se deba a un error en el FeatureScript del flujo de trabajo, en lugar de un error del sistema. En este caso, recibirá un mensaje de error con la respuesta HTTP que le indicará a usted (o a sus usuarios) que se pongan en contacto con el administrador del flujo de trabajo. El desarrollador del flujo de trabajo puede usar el registro de auditoría del flujo de trabajo para identificar y depurar el error (consulte Registro de auditoría de flujo de trabajo a continuación). Si es necesario, el desarrollador del flujo de trabajo puede crear una incidencia de soporte con Onshape.

Administrar permisos globales de flujos de trabajo

Se trata de un nuevo permiso global en Empresa de Onshape que permite publicar y depurar flujos de trabajo de lanzamiento personalizados. Los usuarios con este permiso pueden publicar flujos de trabajo y siempre tendrán la opción de crear un candidato de lanzamiento en modo de depuración (consulte Depuración del flujo de trabajo a continuación).

No se permiten flujos de trabajo cíclicos.

Solo los usuarios que tengan el permiso global Administrar flujos de trabajo pueden publicar flujos de trabajo. Para obtener más información sobre los Permisos globales, consulte Configuración de Enterprise: Permisos globales.

Edite el flujo de trabajo personalizado, tal y como se indica a continuación:

1. Realice modificaciones en el archivo JSON del flujo de trabajo. A medida que edita, el diagrama de la derecha refleja los cambios realizados.
2. El diagrama es dinámico y se puede arrastrar, por lo que si la estructura no refleja el flujo de trabajo previsto, utilice el cursor para ajustarlo.
3. Cuando esté satisfecho con las modificaciones y desee que su flujo de trabajo esté disponible para usar en su empresa, haga clic en Publicar para abrir el cuadro de diálogo Publicar flujo de trabajo personalizado:

   

   El cuadro de diálogo le avisa de cualquier error que deba corregirse antes de la publicación y se abre en la parte superior del cuadro de diálogo:

   

   1. Haga clic en Cancelar para cerrar el diálogo.

   2. Corrija los errores.

   3. Vuelva a hacer clic en Publicar para abrir el cuadro de diálogo.

4. Proporcione un nombre, una descripción y un tipo de flujo de trabajo.

5. En el menú desplegable Reemplazar flujo de trabajo, realice una de las acciones siguientes:

   1. Si se trata de un flujo de trabajo nuevo, seleccione Ninguno.

   2. Para reemplazar un flujo de trabajo existente, seleccione el que desee reemplazar. Los campos de reemplazo seleccionados Nombre y Descripción se completan automáticamente. Puede conservar los valores existentes o ingresar otros nuevos:

      

6. Haga clic en Publicar.

Cuando se anula la publicación de un flujo de trabajo, ocurre lo siguiente:

• El flujo de trabajo ya no está disponible para su uso en la Administración de lanzamientos a fin de crear nuevos paquetes de lanzamiento.

• Cualquier configuración que utilice el flujo de trabajo eliminado se restablecerá al flujo de trabajo predeterminado de Onshape

• Los candidatos de lanzamiento/obsolescencia que actualmente se encuentran en el flujo de trabajo eliminado siguen funcionando con normalidad. Los paquetes de lanzamiento existentes y los paquetes de lanzamiento enviados mediante el flujo de trabajo no publicado no se ven afectados. Puede seguir abriendo, viendo y volviendo obsoletos los paquetes de lanzamiento existentes mediante el flujo de trabajo personalizado y los lanzamientos pendientes de transición.

Solo los usuarios que tienen los permisos Administrar flujos de trabajo (en Configuración de Enterprise > Permisos globales) pueden anular la publicación de un flujo de trabajo.

A fin de anular la publicación de un flujo de trabajo, haga lo siguiente:

1. Haga clic en su nombre o en el icono de usuario de la cuenta () en la esquina superior derecha de la barra de herramientas Documentos y seleccione Configuración de Enterprise > Administración de lanzamientos.

2. Seleccione el flujo de trabajo de lanzamiento cuya publicación desea anular en el menú desplegable del flujo de trabajo.

3. Haz clic en el vínculo Ver en el documento, que se encuentra a la derecha del menú desplegable del flujo de trabajo. El documento del flujo de trabajo se abre en la pestaña actual del navegador.

4. Haga clic en el botón Anular publicaciónubicado en la parte superior del documento.

   

5. Se abre el cuadro de diálogo Anular publicación del flujo de trabajo. Haga clic en el botón Anular publicación.

Anular la publicación de un flujo de trabajo predeterminado hace que se restablezca el flujo de trabajo predeterminado al valor predeterminado de Onshape.

Un usuario con el permiso global Administrar flujos de trabajo puede probar un flujo de trabajo en desarrollo mediante el modo de depuración.

El flujo de trabajo debe publicarse primero para que esté disponible en el cuadro de diálogo Seleccionar flujo de trabajo de lanzamiento cuando se lanza una pieza/ensamblaje. (Una vez que esté satisfecho con el nuevo flujo de trabajo, puede volver a la configuración de Enterprise y activar el flujo de trabajo).

Un típico flujo de trabajo publicado apunta a una versión del documento en la que reside la definición del flujo de trabajo (el archivo JSON). Los lanzamientos que utilizan ese flujo de trabajo publicado siguen el flujo de trabajo tal como se define en esa versión. En cambio, el modo de depuración usa el flujo de trabajo tal como existe en el área de trabajo del documento asociada con la versión publicada. Tenga en cuenta que los flujos de trabajo solo se iniciarán en modo de depuración si hay exactamente un área de trabajo por encima de la versión publicada, lo que permite eliminar la ambigüedad.

El modo de depuración permite una iteración rápida durante el desarrollo del flujo de trabajo. Si descubre que el flujo de trabajo no funciona como se esperaba, puede realizar un cambio en el JSON del flujo de trabajo o en el Feature Studio que consume la nueva acción en el área de trabajo. El inicio inmediato de un nuevo lanzamiento le permite a usted (el desarrollador del flujo de trabajo) ver los efectos sin necesidad de publicar primero una nueva versión del flujo de trabajo.

Para depurar un flujo de trabajo, realice lo siguiente:

1. Marque la casilla Modo de depuración (como se ve en la imagen de arriba).

2. Haga clic en Aceptar.

   

3. En este cuadro de diálogo, puede seleccionar el botón del menú de desbordamiento () en la esquina superior derecha > Ver registro de auditoría para ver un registro de auditoría de los objetos del flujo de trabajo y sus eventos importantes, por ejemplo, la creación y transición.

4. También puede seleccionar Ver flujo de trabajo para ver el flujo de trabajo como un diagrama, con el último estado resaltado, como en el diagrama siguiente:

   

Los cambios aplicados en el área de trabajo de un flujo de trabajo en modo de depuración no afectarán a ningún lanzamiento que ya esté en curso. Los lanzamientos de depuración están bloqueado en la microversión del área de trabajo en el momento de la creación. Para ver los resultados de los cambios, debe crear un nuevo lanzamiento. Este procedimiento evita que los cambios en la definición del flujo de trabajo destruya un lanzamiento en curso y evite que se descarte.

Una vez que haya publicado un flujo de trabajo personalizado, puede habilitar varios flujos de trabajo activos en su cuenta Enterprise si lo desea. Cuando los usuarios dispongan de varios flujos de trabajo activos, pueden seleccionar qué flujo de trabajo seguir al crear un candidato de lanzamiento.

Es responsabilidad del administrador educar a los usuarios sobre qué flujos de trabajo deben utilizarse y en qué condiciones.

Para habilitar varios flujos de trabajo:

1. Siga las instrucciones anteriores para crear más de un flujo de trabajo personalizado y publicarlos en Onshape.
2. En la página Administración de lanzamientos de la Configuración de Enterprise, seleccione qué flujos de trabajo personalizados desea activar en la sección Flujos de trabajo administrados; para ello, active la casilla Activo, situada junto a cada flujo de trabajo:

   

3. Haga clic en el Icono de vista previa del flujo de trabajo () para ampliar el menú desplegable de una ilustración que representa el flujo de trabajo. Debajo de la ilustración, hay una descripción del proceso de flujo de trabajo actual:

   

4. Asegúrese de hacer clic en Guardar la configuración de lanzamientos para guardar los cambios que ha realizado en la configuración de la Administración de lanzamientos de la empresa.

Cuando los usuarios crean un candidato de lanzamiento, se les presenta la oportunidad de seleccionar un flujo de trabajo en ese momento (desde el menú desplegable):

A continuación, se presenta la sintaxis para personalizar el flujo de trabajo de lanzamiento u obsolescencia. Tenga en cuenta que la mayúscula es importante.

Tenga en cuenta las siguientes reglas.

Propiedades

Formato

• name: string
• propertyId: string
• valueType: string|ENUM
• defaultValue?: any
• usersOnly?: boolean
• teamsOnly?: booleano
• enumValues?: list

Restricciones

• Los identificadores de propiedad deben ser únicos (y no coincidir con el identificador de propiedad Nombre, Descripción o Comentario codificados de Onshape).
• ValueType debe ser el nombre de un BTMetaDataValueType (excluyendo BLOB y OBJECT)
• Si valueType es ENUM, se debe especificar EnumValues y la propiedad debe contener uno o varios EnumValues. Cada uno de los EnumValues debe tener un elemento de valor obligatorio. El elemento de la etiqueta es opcional.
• Si se proporciona defaultValue, debe coincidir con el campo de valor de uno de los EnumValues.
• usersOnly y teamsOnly son mutuamente excluyentes y solo son válidos para propiedades de USUARIO.
• defaultValue, si está presente, debe coincidir con el tipo correcto indicado por valueType.
  • STRING: cadena
  • BOOL: booleano
  • INT: entero
  • DOBLE: decimal
  • USUARIO: string[]
  • FECHA: cadena de fecha ISO
  • BLOB y OBJECT no son compatibles actualmente
• Los valores de propiedad de tipo USUARIO son una lista de identificadores de usuario, equipo o rol.

Estados

Formato

• name: string
• displayName: string
• approverSourceProperty?: string
• notifierSourceProperty?: string
• entryActions?: Action[]
• exitActions?: Action[]
• editableProperties?: string[]
  • Los valores pueden incluir:

    • approvers

    • observadores

• requiredProperties? : string[]
• requireditemProperties?: string[]

Restricciones

• Los nombres deben ser únicos
• approverSourceProperty y notifierSourceProperty, si están presentes, deben ser los identificadores de propiedad del flujo de trabajo y deben apuntar a las propiedades de tipo de USUARIO.
• Como máximo, un estado puede usar una propiedad dada como sus aprobadores.
• Cualquier número de estados puede utilizar una propiedad dada como sus notificadores.
• editableProperties y requiredProperties deben ser identificadores de propiedad en el mismo flujo de trabajo.
• requireditemProperties deben ser identificadores de propiedades de metadatos válidos para su compañía (propiedades integradas de Onshape o propiedades personalizadas; se excluyen las propiedades calculadas).

Para obtener más información sobre los ID, consulte Descripción y administración de roles de proyectos y planes de permisos.

Transiciones

Formato

• name: string
• displayName: string
• tipo: cadena
• sourceState: cadena
• targetState: cadena
• uiHint?: string (default:"primary")
• actions?: Action[]
• requiredProperties? : string[]

Restricciones

• Los nombres deben ser únicos.
• El tipo debe ser “APPROVE,” “REJECT,” or “SUBMIT”.
• sourceState y targetState deben ser dos estados diferentes dentro del flujo de trabajo.
• Puede haber, como máximo, una transición de tipo APPROVE desde cualquier estado de origen.
• Para una transición de tipo APPROVE, sourceState debe tener una propiedad approverSourceProperty.
• uiHint, si está presente, debe ser “primary”, “success” o “danger” (estos son los colores de los cuadros y otras entidades en el cuadro de diálogo de lanzamiento y están codificados por Onshape).

Tipos de transición

Enviar

• Realiza varias «inicializaciones» en el lanzamiento a medida que se va desconfigurando y entrando en el flujo de trabajo, como iniciar la generación de vistas en miniatura para las piezas configuradas en el lanzamiento, conectar identificadores de documento o de versión vinculados, etc.
• Solo el creador de lanzamiento tiene la capacidad de ejecutar transiciones SUBMIT.
• Las transiciones fuera del estado inicial deben ser Envíos.
• Un envío que no sea una transición inicial no tiene habilidades especiales

Aprobar

• Marca que el usuario ha hecho una aprobación (el token cambia a color verde en el cuadro de diálogo de lanzamiento).
• Si las políticas de la compañía se establecen en Requerir a todos los aprobadores, la transición no se realizará hasta que todos los aprobadores la hayan aprobado.
• Genera referencias de contenido de ensamblaje y de dibujo para elementos.
• Sólo se permite una transición de este tipo fuera de un estado.
• Solo un aprobador del estado actual (o un administrador) tiene la capacidad de aprobarlo.

Rechazar

• Marca que el usuario ha hecho un rechazo (el token cambia a color rojo en el cuadro de diálogo de lanzamiento).
• Sólo un aprobador del estado actual (o un administrador) tiene la capacidad de rechazar.

Acciones

Formato

• name: string
• params?: {[key: string]: any}

Restricciones

• El nombre debe coincidir con uno de nuestros nombres de acción predefinidos (ver abajo, en Acciones permitidas)
• Algunas acciones pueden ser permitidas solo en estados o en transiciones, algunas pueden tener restricciones de pedido.

Acciones permitidas

• sendEmailNotifications: envíe notificaciones por correo electrónico para una transición (incluidas las notificaciones push a dispositivos móviles).
  • Permitido en solo transiciones
  • Parámetros: ninguno
• sendUserNotifications: envíe notificaciones de usuario para una transición.
  • Permitido en solo transiciones
  • Parámetros: ninguno
• markItemsPending: cambie el estado de metadatos de todos los elementos de lanzamiento a Pendiente.
  • Permitido en estados o transiciones
  • Parámetros: ninguno
  • No se permite en flujos de trabajo de obsolescencia.
  • En flujos de trabajo de lanzamiento, no es posible después de markItemsReleased o markItemsRejected.
• markItemsRejected: cambie el estado de los metadatos de todos los elementos del lanzamiento a Rechazado.
  • Permitido en estados o transiciones
  • Parámetros: ninguno
  • No se permite en flujos de trabajo de obsolescencia.
  • En los flujos de trabajo de lanzamiento, no es posible después de markItemsReleased o antes de markItemsPending.
• releaseItems: cambie el estado de los metadatos de todos los elementos del lanzamiento a Lanzado y cree revisiones para ellos (se marcan automáticamente como obsoletas otras revisiones si así se especifica en la política de la compañía).

  Permitido en estados o transiciones

  Parámetros: ninguno

  No se permite en flujos de trabajo de obsolescencia.

• obsoleteItems: cambie el estado de los metadatos de todos los elementos del paquete a «Obsoleto» y haga obsoletas sus revisiones respectivas.
  • Permitido en estados o transiciones
  • Parámetros: ninguno
  • No se permite en los flujos de trabajo de lanzamiento
• updateItemPropertiesFromFeatureScript Utilice esta opción para usar una operación FeatureScript como acción de transición o como acción de entrada o salida de un estado.
  • Permitido en estados o transiciones
  • Parámetros:& (argumento único con este tipo)

A la hora de definir un flujo de trabajo personalizado, puede incluir una sección de opciones diseñada para invalidar la configuración de lanzamiento específica de la compañía definida en la página Configuración de Enterprise > Administración de lanzamientos. Estas opciones de invalidación se explican a continuación:

«options»: {

"revisionSchemeId": string,

"requireApprover": boolean,

"requireAllApprovers": boolean,

"disallowCreatorAsApprover": boolean,

"requireNote": boolean,

"autoObsolete": boolean,

"errorOnFeatureListErrors": boolean,

"errorOnFeatureListErrors": boolean,

"errorOnAssemblyErrors": boolean,

"errorOnAssemblyRefsOutOfDate": boolean,

"errorOnDrawingOutOfDate": boolean,

"errorOnPartNumberPending": boolean,

"errorOnPendingTask": boolean,

"nameOverride": (invalida la etiqueta Nombre del lanzamiento o el nombre de Obsolescencia en el cuadro de diálogo Lanzamiento)

"descriptionOverride": (anula la etiqueta Notas de lanzamiento o las notas de Obsolescencia en el cuadro de diálogo Lanzamiento)

}

Esta sección y todos los campos son opcionales. Puede elegir cualquier subconjunto con el que desee invalidar la configuración de la compañía. Los campos que no estén incluidos en el código se ajustarán por defecto a la especificación de la configuración de Enterprise.

El ID del plan de revisiones se puede recuperar del cuadro de texto de solo lectura de la página Configuración de Enterprise > Administración de lanzamientos:

Todos los objetos del flujo de trabajo crean un registro de auditoría de eventos significativos durante su vida útil, por ejemplo, la creación y la transición. Este registro se puede recuperar mediante

GET /api/workflow/obj/<object id>/auditlog

Puede consultar el resultado de esa llamada a través de un vínculo en el lanzamiento para inspeccionar y depurar problemas.

La respuesta del registro de auditoría contiene información básica sobre el flujo de trabajo del objeto (incluso su versión de flujo de trabajo publicada y si es un flujo de trabajo que está en modo de depuración) y todos los eventos que se registran para él.

Cada entrada de registro contiene lo siguiente:

• Una marca de tiempo

• Un tipo (representado por un valor entero que es un ordinal BTWorkflowAuditEntryType)

• El estado/transición/acción del flujo de trabajo en el momento del evento.

También hay otros campos para información adicional específica del tipo de evento, según corresponda.

Estos son los tipos de eventos de auditoría:

• Objeto creado: primer evento registrado para un objeto cuando se crea.

• Objeto descartado: cuando se ejecuta la acción especial Descartar en el objeto.

• Objeto eliminado: cuando se quita el objeto, por lo general, debido a que es muy antiguo para que lo capture el servidor de limpieza (el registro de auditoría de un objeto eliminado no se elimina).

• Propiedades actualizadas: cuando se modifican las propiedades del flujo de trabajo en el objeto. Esto está dirigido a propiedades a nivel de paquete en un paquete de lanzamiento (por ejemplo), no para propiedades de metadatos en elementos individuales.

  • Esto incluye los ID de propiedad (de la definición del flujo de trabajo) que se cambiaron, incluso sus valores antiguos y nuevos.

• Comentario agregado: incluye el ID del comentario recién agregado.

• Aprobado por el usuario: cuando un usuario realiza la acción de aprobación para el estado actual. Esto puede ir acompañado o no de una transición, según la configuración de lanzamiento de la compañía.

  • Esto incluye los ID de usuario/equipo/rol en la lista de aprobadores para los que se realizó la acción, es decir, en nombre de quién se aprobó el usuario.

• Rechazado por el usuario: cuando un usuario realiza la acción de rechazo para el estado actual.

  • Esto incluye los ID de usuario/equipo/rol en la lista de aprobadores para los que se realizó la acción; es decir, en nombre de quién se rechazó el usuario.

• Transición iniciada

• Transición completa

• Transición fallida: incluye un mensaje de error o un código de soporte, si corresponde.

• Acción iniciada

• Acción completa

• Acción fallida: incluye un mensaje de error o un código de soporte, si corresponde.

• FeatureScript ejecutado: esto incluye cualquier resultado de la consola a partir de la ejecución de FeatureScript.

  • Esto incluye los avisos devueltos por la ejecución de FeatureScript (incluida una excepción, si se produjo una).

  • Incluye el valor que devuelve la operación FeatureScript.

• Error en las actualizaciones de metadatos de elementos: cuando una solicitud de actualización de metadatos de elementos de paquete de lanzamiento falla durante una transición.

  • Esto incluye los ID de propiedad de metadatos fallidos, las hrefs de metadatos de los elementos fallidos y un mensaje de error.

  • Por lo general, se produce un error de transición, excepto cuando ocurre durante la acción de FeatureScript. Las acciones integradas deben tener éxito, pero la configuración de propiedades adicionales desde FeatureScript puede fallar y permitir que la transición continúe.