Is it possible to customize a work item programmatically (through code) instead of using the UI (Process)? I want to add a button to create two specific work items, provided some conditions are fulfilled.
I tried to achieve the above requirement using UI. However, it doesn't seem to be possible.
For processes using the Inheritance model. API’s for everything you need to create and manage a process through code. This includes work item types, pages, groups, fields, states, rules, etc. Check Work Item Tracking Process APIs at the following site:
https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-5.0
For Hosted XML processes. API’s for checking to see if the process exists, importing, and exporting a Hosted XML process. Check Work Item Tracking Process Template APIs.
More details, you could refer to the following blog:
https://devblogs.microsoft.com/devops/announcing-new-rest-apis-for-process-customization/
Related
We are working on implementing an architecture review which affects a specific subset of work items. I created the following query:
The result includes the downstream work items, which is what I want. However, it also includes the work items marked as with the Architect Decision, which I don't want. My ultimate goal is to see on a dashboard how many work items are blocked by architect decisions which are pending.
AzDO does not support that. If you want to see a plain list, you should use a flat query. As workaround, you may write your own job through REST API (as example):
Find epics, features, stories, and bugs without the Blocked by Architect Decision tag and with open work items contain the Architect Decision. Add to these work items the Blocked by Architect Decision tag.
Find epics, features, stories, and bugs with the Blocked by Architect Decision tag and without open work items contain the Architect Decision. Remove from these work items the Blocked by Architect Decision tag.
Then you can search your blocked work items with a flat query and the Blocked by Architect Decision tag.
The Rest Api methods:
Query By Wiql.
Update a work item tag.
Additionally, you`ll receive a notification when your work items are unblocked.
I've looked around the site to see if there are any people who have changed the CKAN API interface so that instead of uploading documents and databases, they can directly type onto the site, but I haven't found any use cases.
Currently, we have a page where people upload data sets through excel forms that they've filled out, but we want to make it a bit more user friendly by changing the API so that they can fill out a form on the page rather than downloading the template, filling it out and then uploading it.
Does CKAN have the ability to support this? If so, are there any examples or use cases of websites that have use forms rather than uploads?
This is certainly possible.
I'm not aware of any existing extensions that provide that functionality, but you can check the official list of CKAN extensions if there's anything that fulfills your needs.
If there is no existing extension that suits you then you could write your own, see the extension guide for details on how to do that.
Adding an API function to CKAN's API is possible, but probably not what you want in this case: the web UI usually does not interact with CKAN via the API but via Flask/Pylons controllers. Hence, you would add your add controller which first serves your form and then processes the submitted inputs.
You can take a look at the ckanext-pages extension, which does exactly that (for editing static pages instead of datasets, but your code would be similar).
I am building a VSTS dashboard widget where I would like to iterate over all Features in a particular Epic, and then for each Feature gather data about all the WorkItems to create a status report.
I know I can use getWorkItem() and getWorkItems(), but that is if I already know the WorkItem IDs. I want to loop through all the features and then all the WorkItems and see if they are completed, without knowing their particular ids.
The VSTS work item tracking system is very extensible, therefore there aren't any "fixed" methods that will return you specific work item types. Even though features in VSTS rely on one or more levels of work items being present, their name, the fields and other aspects of these work items are highly configurable.
To query the available work item levels (called Categories in VSTS), you can use the Categories/List API. This will allow you to find hierarchy as it's configured in VSTS and which work item types are available at each level.
You can use the ProcessConfiguration/Get API to list the relationship between the different backlog levels. Which is a parent of which and what type of backlog it represents. Is it a Task (lowest level), Requirement (Story, PBI level, planning level), or a Portfolio (Epic, Feature etc) level backlog.
With this information, you can either use the Backlig/GetBacklogWorkItems API to fetch all the work items on a specific backlog or you can construct a WIQL (Work Item Query Language) query to retrieve all work items that match that specific query. You can either export the WIQL from Visual Studio or use an extension.
Depending on what you need with each work item you can either query directly for the required fields, or just query the work item ID's and fetch the work item details individually using the workitem/getWorkItems(id) API.
There is pretty extensive documentation available on each of these API's and on the required VSTS services you can use from your extension. going deep to explain each of the services goes too far for this answer. I suggest you start experimenting from here and ask new questions as they arise. You now have far more information to work with and it will be easier to ask targetted questions from there.
I would like to move the backlog items and any related linked items to another tenant, any ideas?
There's nothing built in that does this.
You'll either have to write your own solution or look into one of the various migration or integration tools that are available on the market. None of them provide full fidelity migration, however.
As Daniel said that there isn’t built-in tool.
You can build an application with REST API to create the new workitems per to the workitems in another VSTS. Regarding Work Item creating REST API, there is bypass rules that can remain System.CreatedDate and System.CreatedBy value: Make an update bypassing rules.
On the other hand, there is 3rd tool: OpsHub Visual Studio Online Migration Utility
I'm currently using the Jira SOAP interface within a C# (I suppose the language used here isn't terribly important).
Basically, I'm creating an API and a Winform that wraps some of the functionality of the soap service so that our Devs can programmaticly add bugs when something goes wrong in our application.
As part of this, I need to know the custom field IDs that are in use in Jira, rather than hardcoding them (as they are still prone to the occasional change) I used the GetCustomFields() method in the jira-rpc api then filtered it, so that all the developer needs to know is the name of the field, then the ID is filled in for them automagically.
This all works fine, but with one quite important proviso: that you login to the SOAP/RPC service as a user with administrative privaliges.
The Jira documentation indicates that the soap/rpc service follows the usual workflows and security schemes, however I can't find anything anywhere that would appear to remove this restriction on enumerating custom fields (and quite why in any instance you would want someone to HAVE to be an administrator to gain this access, especially as the custom field id's tend to be in Jira's HTML source is beyond me)
Does anyone know if I've missed a setting somewhere? Or if there is some sort of work-around for this, short of hardcoding the custom field id's?
Or is this a case of having to delve in to Jira's RPC plugin and modifying the source for it in order to give me the functionality I require?
Cheers
Edit for the sake of google/posterity
Wow, all this time on, and it looks like Atlassian still haven't changed this behavior.
Worked around this by creating a custom dictionary that logs in as an administrative user, grabs the custom fields and then logs out. Not ideal, but it should work 'til atlassian change things
You're not missing anything - there's no way to get custom fields via standard SOAP API.
In JIRA Client, we learn about custom fields in two ways:
We download issues via RSS view of the issue navigator, or via XML representation of a specific issue. If a custom field is set for an issue, the XML will have its id, class and value (values).
From time to time we inspect the content of IssueNavigator search page - looking for searchers for the custom fields. Screen-scraping the HTML gives us not only ids of the custom fields but also possible values for enum fields.
This is hackery, of course, and it may go wrong, so a good API would have been a lot better.
In your case, I can suggest two solutions:
Create your own SOAP (or REST) remote API plugin that will give you just that info that you miss from the standard API. Since you're seemingly in control of your JIRA, you can install anything there.
Screen-scrape the "New Bug" page for the project and type of issue you need to submit. You'll get all the info - fields, options, default values, which field is required.