c# - studio - ¿Cómo cambiar el estado del flujo de trabajo del elemento de trabajo TFS recién creado a través de la API?
visual studio installer (1)
Ok, amigos, como suele suceder, la respuesta está en el manual. Dejame explicar.
El artículo al que hice referencia en mi pregunta establece claramente:
Debe ser miembro de las cuentas de servicio de Project Collection
Pero no menciona que no puede agregar fácilmente el usuario o grupo a las Project Collection Service Accounts
. Si intentas hacer esto a través del acceso web, fallarás; el botón Agregar simplemente se desactiva. Además, la captura de pantalla es engañosa y muestra una cuenta como miembro del Project Collection Administrators group
de Project Collection Administrators group
.
De forma predeterminada, el Project Collection Service Accounts group
contiene un solo grupo llamado Team Foundation Service Accounts
. Y este es el grupo al que debe agregarle la cuenta. Esto se puede hacer con la ayuda de la aplicación de consola llamada TFSSecurity.exe:
TFSSecurity.exe /g+ "Team Foundation Service Accounts" "Domain/my-service-account" /server:http://mytfsserver:8080/tfs
Esto se explica en detalle en este artículo , que describe exactamente mi caso con la resolución correcta. El TFSSecurity.exe se puede encontrar en la siguiente ubicación:% ProgramFiles (x86)% / Microsoft Visual Studio / Common7 / IDE (por ejemplo, C: / Archivos de programa (x86) / Microsoft Visual Studio 12.0 / Common7 / IDE)
Estoy creando una aplicación de migración de elementos de trabajo desde "algo" a TFS 2013, y quiero que los elementos de trabajo TFS estén en los estados de flujo de trabajo correspondientes como en el sistema de origen. Por ejemplo, si el elemento de trabajo fuente está en estado "Cerrado", quiero que esté en estado "Hecho" en TFS.
He seguido los consejos de este artículo , que sugiere establecer la propiedad WorkItemStore
objeto WorkItemStore
en true
para poder establecer el campo CreatedDate
. Supongo que lo mismo se aplica a cambiar el estado del flujo de trabajo, ya que también requiere eludir las reglas.
Entonces, intenté lo siguiente:
// obtain collection and authenticate towards it
var collection = new TfsTeamProjectCollection(new Uri(_tfsUrl), cred);
collection.Authenticate();
// get the work item store object
var store = new WorkItemStore(collection, WorkItemStoreFlags.BypassRules);
// creating the work item
var workItem = new WorkItem(store.Projects[_tfsProjectName].WorkItemTypes["Product Backlog Item"]);
// setting some standard fields
workItem.Title = "some name";
workItem.Description = "some description";
// validating the work item
if (workItem.Validate().Count > 0)
{
// throw validation rules violated
}
// saving the work item
workItem.Save();
Como puede ver, esta muestra no infringe ninguna regla de validación, y workItem.Validate().Count
devuelve 0
. Pero la llamada a workItem.Save()
arroja la siguiente excepción:
Información adicional: TF26212: Team Foundation Server no pudo guardar sus cambios. Puede haber problemas con la definición del tipo de elemento de trabajo. Inténtelo de nuevo o póngase en contacto con el administrador de Team Foundation Server.
Comprobé dos BypassRules
que BypassRules
está establecido en true
justo antes de la llamada al método Save()
. Además, el workItem.IsValid
también es true
.
El hecho interesante es que si cambio la forma en que WorkItemStore
objeto WorkItemStore
, desde
var store = new WorkItemStore(collection, WorkItemStoreFlags.BypassRules);
a
var store = collection.GetService<WorkItemStore>();
puede guardar sin ningún problema! Pero en este caso no sé cómo configurar BypassRules
en true
. Esta propiedad es de solo lectura cuando se WorkItemStore
objeto WorkItemStore
, y obtengo errores de validación si intento establecer el paso del flujo de trabajo a algo que no sea "Nuevo".
Entonces, mi pregunta básica es: ¿cómo crear elementos de trabajo en TFS a través de API y poder cambiar el campo de State
en este elemento recién creado?