I have created a Pre Operation Update Plugin that is Synchronous from the following tutorial.
http://crmbusiness.wordpress.com/2014/04/07/crm-2013-step-by-step-update-plugin-tutorial-using-the-crm-2013-development-toolkit/
It works fine when manually saving the entity. However it does not get triggered when a workflow updates the entity.
I do not have any check for Context Depth. Can a workflow call/trigger/fire a synchronous update plugin?
Thank You
Ian
Related
I want to enable Comment Triggers for my GitHub pipelines. I want to use C# ADO sdk to do the same. However, I notice that the Triggers field is set as {get;} only. Does that mean I cannot update Triggers?
Interestingly, I tried a workaround where I directly called the Rest API via Python to update the JSON object and did a PUT request. I was able to update the triggers info successfully.
Wondering how to achieve the same using the C# SDK.
#yan's suggestion worked. I removed the trigger from the Triggers list, updated it and added it back using Triggers.Add().
Also verified that UpdateDefinitionAsync(buildDef) successfully picked up the changes I made to the buildDef.Triggers list.
I'm currently using AppCenter to Test my Xamarin app. The complete suite is being run at night. But I'm currently looking for a way to make this part of my CI builds to introduce an extra quality gate before features get merged.
However, we would need to slim down the amount of tests that need to be run otherwise this would become unmanageable. For this we can specify categories on our App Center test build step. When queued manually I'm able to specify the categories, however when we make this CI Build part of a branch policy and use a manual trigger for our build validation we are unable to specify the categories as we don't get the popup when queuing.
Any suggestions on how to adres this issue differently?
Seems you want to set build variables in pull requests when you queue the build under policies.
Unfortunately, this could not be achieved by now. It will not pop up the dialog when you queue the build. There has been a related uservoice, you could vote up and follow it, TFS PM will kindly review your suggestion.
Allow Setting Build Variables in Pull Requests
https://developercommunity.visualstudio.com/idea/365725/allow-setting-build-variables-in-pull-requests.html
The only workaround for now is editing the build definitions and add the variable under variables directly, then queue again. You could clone the original build definition first.
I have a requirement to update work item status to a ready for test state after the first successful release using TFS release management. It seems like there should be a straightforward built in task to do this but I can't see it. My current thinking is
Use TFS REST API to query the workitems and update them all using powershell
Wrap this up in a powershell task and include in the release definition
This will do the job I reckon. It's yet more powershell in our releases but they are built on a stack of powershell anyway so at least it's well known.
But is there a better (quicker) way to do this? If the answer is a straight 'no' then great - I will accept that answer gladly.
We are on TFS 2015 R4.
Many thanks for any/all help
Sorry, there is no out-of-the-box feature for this by Microsoft.
But we still could use some three-party extensions or tasks to handle this situation.
The WorkItem Updater task can update the following work item fields during a build or release:
Update the state for workitems linked to a build.
Update the assignee for workitems linked to a build.
Add the build as Development Link to the workitems.
The limitation is also very obviously, it could only update work items which be linked to a build. Which seems not be a problem, it's also a good behavior track work items during build pipeline.
Otherwise, you have to use the ways mentioned above to update normal work items after/during a Release.
I have installed TFS2012 on my server, now I need to achieve change tracking.I have explained the details below.
The whole idea of change tracking is, if I change the PBI/Requirement the all linked work items/bugs/impediments status should be changed or TFS should notify me in some way.
TFS will not automatically update one Work Item when a linked item changes. There is no functionality for that out-of-the-box. What you can do is configure an alert.
Or you can test whether the TFS Aggregator that exists for TSF 2010 (open source project) will work for 2012 (not officially supported). It can update child or parent work items when a workitem in the hierarchy changes.
What you want is not possible in TFS out of the box, but you can implement this with relative ease using a custom ISubscriber or a SOAP webservice. See the following answer on question regarding this.
I have a nintex workflow set to fire when an item is modified. If the workflow modifies an item, will it trigger the same workflow again?
Once upon a time, yes; however, this was a bug. If you are running on the latest version, no.
At least, this is true of Nintex Workflow 2007 on our MOSS 2007 SP2 farm using the Set Field activity.
With SP 2010, Nintex does not offer the ability to disable event firing (like visual studio does). Therefore, starting a wf when an item is maintained is not a good option if the wf updates the item. It will trigger a loop.