Apologies if this is very naive question. New to VSTS...
We are thinking to use VSTS for our daily project works. Currently, we are on old TFS hosted in-house. We have window application which is data entry tool and when any error generated Staff can raise support request via clicking one button which includes all traceback and any other necessary information for us to debug or they can raise new support work. We are thinking to integrate VSTS for our support work as well by calling API endpoint to create a task in VSTS.
I am thinking to use one service account in code that calls API to create a work item in VSTS however, I need to update System.CreatedBy field to the actual user rather than service account who raises this work item. I have seen numbers of other posts which says its read-only field.
The process is, I create a work item and then update CreatedBy field by calling following endpoint.
https://XXXXXX.visualstudio.com/DefaultCollection/_apis/wit/workitems/11?bypassRules=true&api-version=1.0
passing following JSON
[
{
"op": "replace",
"path": "/fields/System.CreatedBy",
"value": "Test, Mr <Test#example.com>"
},
]
This doesn't update the field.
Is there any way I can update this field? Thanks for your time.
Well, just read this https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/update?view=azure-devops-rest-6.0#update-a-link
NOTE: System.CreatedBy and System.CreatedDate can only be modified using bypass rules on work item creation, i.e. the first revision of a work item.
Related
I've added some custom fields for Test Plan in Azure DevOps. But when I try to create a new Test Plan through the Rest API call, it is only creating a Test Plan with default fields populated, while custom fields remain blank.
I've tried using both the field name (like Team Name) along with field reference name (like custom.TeamName) but to no avail. Even Get is also not exposing custom fields. Is some extra configuration required for custom fields, or it is a code related issue?
Details: I've created one Inherited process under the organization, and then under Process->Test Plan I've created new fields in the Test Plan, as shown in the screen shot:
I've tried below code to create Test Plan as Work Item and successfully created it with extra fields. But as I couldn't create a test suite independently, it is not behaving properly.
I've created a JsonPatchDocument and added all the fields (adding just one here) like below code:
JsonPatchDocument patchDocument= new JsonPatchDocument();
patchDocument.Add(
{
Operation=Operation.Add,
Path="/fields/System.TeamName",
Value="Xander"
}
);
VssConnection connection=new VssConnection(uri,credential);
WorkItemTrackingHttpClient workItemTrackingHttpClient= connection.GetClient<WorkItemTrackingHTTPClient>();
WorkItem res=workItemTrackingHTTPClient.CreateWorkItemAsync(patchDocument,project,"Test Plan").Result;
It is creating the Test Plan, but not Test Suite. So it is acting weirdly. Kindly check this.
Insert value into Azure DevOps Custom Fields through Rest Api
I could reproduce this issue with the REST API Test Plans - Create.
I think this should be related to the REST API, that because even if I use the REST API Test Plans - Get to get the custom field, but the request body does not include the custom field.
Since we could not get the custom field, we could not use the POST or PATCH for the custom filed.
You could add this request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
In Azure Devops "Classic" pipelines, there's a section in the pipeline Options menu where you can turn on a feature to automatically create a work item on pipeline failure. However, in the new YAML pipelines, this feature is not present in the options menu. Is this option still available in some way, or is it not supported for YAML pipelines?
Although this option is not currently available via the GUI for YAML pipelines, it is nevertheless still functional under the hood - there's just not an easy way to turn it on. You can, however, do so by utilizing the Azure DevOps REST API.
First you'll want to know the name of your Azure DevOps organization, project, and the pipeline's Definition ID, which is a query string parameter on the URL when you're viewing a given pipeline, e.g. https://dev.azure.com/{organization}/{project}/_build?definitionId={definition id}. Then, you'll want to send a GET request to the Pipelines API for that ID, using this URL format: https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definition id}?api-version=5.1. For authentication, you should be able to use Basic auth, leaving the username blank and using an appropriately scoped Personal Access Token as the password.
If your request is successful, you should get a response containing a large JSON object which describes the pipeline in question. There's a lot there that isn't relevant, but what we're looking for is near the top: there's an options array which includes the following element:
...
{
"enabled": false,
"definition": {
"id": "a9db38f9-9fdc-478c-b0f9-464221e58316"
},
"inputs": {
"workItemType": "Task",
"assignToRequestor": "true",
"additionalFields": "{}"
}
},
...
That ID of "a9db38f9-9fdc-478c-b0f9-464221e58316" appears to be static across all pipelines, and uniquely identifies the option to create a work item on failure. If we edit the JSON to change "enabled": false" to true (and set any other desired options in the inputs fields), we can now take the entirety of the JSON response from our GET request, and use it as the body of a second API call to the same URL, this time a PUT request. If all was correct, you should see your updated changes reflected in the response from the PUT.
It's a bit clunky because there's still no way to verify that the option is turned on through the web UI, but until Microsoft updates the UI to include this feature, it's the best option available. One more handy tip is that if you already had a classic mode pipeline where you'd added Additional Fields or other customizations to the UI, you can do an API GET on that pipeline to extract the exact JSON for those settings and use them to inform your PUT to your YAML pipeline.
I am unable to get a list of builds when using the devops api (I am requesting it without any additional filters)
https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.1
It returns the following
{ "value": [ ], "count": 0 }
It seems that the API is working other wise as if the following URL is working and returning a full details about the build
https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}?api-version=5.1
I am using token authentication and all the other tests seem to work as I would expect. All the {variables} are replaced with my queries, but have left them in as that is somewhat sensitiv(e.
Am I missing something? Is the API broken?
AzureDevops API builds list API returns empty json results
As test, the rest api Builds - List works fine:
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.1
I test it with postman by using the PAT (only have the build read scope of access):
So, the REST API is fine.
Besides, since you could also get the result with a specify a build Id, please confirm if there are any errors in your url and if there are too many pipelines in your project, which has not returned the correct value in time. You could test it with a new test project.
Besides, what Eric said is also a possibility, please make sure the token authentication have permission to read all pipeline, you could create a PAT with build read scope of access.
Hope this helps.
All of my workflows for a site have the ability to log data in the Workflow History list on my site. This is controlled at run-time with a parameter in list based on the workflow Name. I would like to be able to run a workflow on this setup table that will delete all records in the History list. My understanding is I can do this via REST call in SharePoint Designer workflow.
I have attempted many times to configure the REST Post command in Designer and I am never able to get this to work. I've searched over and over for a solution and not able to find such a solution.
I first tried deleting all that had the Workflow Association ID equal to the Workflow Name, but could not get that to work. Then I thought I would try selection each value using REST and then deleting that value using REST by the ID I received from the GET.
This is my delete (POST).
[%Workflow Context:Current Site URL%]/_api/lists/GetByTitle('Workflow History')/GetItemObject('[%Variable: HistoryID%]')
I also tried the DeleteListItem
[%Workflow Context:Current Site URL%]/_api/lists/GetByTitle('Workflow History')/DeleteListItem('[%Variable: HistoryID%]')
I want the user to be able to run this on any workflow from the setupWorkflow list I have. The workflow should delete all history for the current workflow.
We can get the list items in Workflow History list base on the WorkflowInstance, in designer workflow, we can get the Instance ID from the Workflow Context.
/_api/web/lists/getbytitle('Workflow%20History')/items?$filter=WorkflowInstance eq 'b87b131e-ce22-43f5-85be-ec81d1045bc7'
Then delete list item using REST API below.
/_api/web/lists/getbytitle('Workflow%20History')/GetItemById(ID)
The following articles for your reference.
Using HTTP Call/ Rest API from SharePoint Designer workflow to create list
workflow to delete list item on subsite( Sharepoint designer call http web service )
I have already created triggers and actions for IFTTT channel. Now I want to create a recipe using these triggers and actions, but I want to do it not through Maker, but using an API call. What would be the format of the API call (behind Maker UI) to create a recipe, I am seems to unable to see any documentation or examples?
Click the URL in your maker settings to see IFTTT's description, which reads as follows, and shows your individual API key which must be used in your code:
To trigger an Event Make a POST or GET web request to:
https://maker.ifttt.com/trigger/{event}/with/key/tIpcUAlqRkf8Mls9XepGN
With an optional JSON body of:
{ "value1" : "", "value2" : "", "value3" : "" }
The data is completely optional, and you can also
pass value1, value2, and value3 as query parameters or form variables.
This content will be passed on to the Action in your Recipe. You can
also try it with curl from a command line.
curl -X POST https://maker.ifttt.com/trigger/{event}/with/key/tIpcUAlqRkf8Mls9XepGN
Yes. There is a documentation for create / triggers and actions.
You need to create the API from your server like that:
http://api.test.com:8080/ifttt/v1/triggers/{{triggers}}
More information:
Login: https://developers.ifttt.com/channels/t4/triggers
Click triggers in left menu
Create trigger name
Then as the endpoint you need to give your api url.
There is no public API. With old-type call there is internal API you can see REST calls like create/api/state whilst building a recipe, yet it might be protected from use by third party and I did not check the traffic of new applet maker platform. Note, if you are a partner you can embed your recipes into your apps. Upper tier customers are allowed to request new features (such as API or templates).
I was looking for the same, but after wasting hours, NO LUCK. So, I have decided to create one. This might be too late, but here's one repo of IFTTT boilerplate (https://github.com/Dipen-Dedania/ifttt-boilerplate) using NodeJS and express to create your own recipe (custom triggers and actions)