Is there a way to hide epic stories (i.e. stories with children) from Rally's kanban board app (presumably by customizing the kanban "catalog app" code to be a custom app)?
I found the part of the kanban javascript app code where it sets up a query depending on whether stories "allocated to a release" are hidden (and I'd added another checkbox into the settings to control the showing / hiding of epic stories), but haven't had any success modifying the query to exclude stories that have children. (Whether or not the query can be modified, or whether the cards need to be filtered after fetching the query results, I'm not sure).
Unfortunately for now this is unsupported by our WSAPI. Being able to filter by collection count is one of the more requested features however- (Children.Count = 0) or something similar would be awesome.
There is one app in the catalog that does prevent epics from showing up on a board- Estimation Board. It is entirely manual though. Data is queried first with Children included in the fetch and any items with Children are filtered out of the results on the client side before being passed to the CardBoard component. There are also performance issues to consider when pulling back this additional volume of data.
You cannot filter data based upon the qualities of items in collections it contains. For example you could not return Stories with no children or defects. You could filter change the query to return the children of the stories if you wanted. This would enable you to filter the stories in memory on the browser side.
There are a few issues with this plan that kept me from filtering them when we wrote the Kanban App. If the the first page of stories returned contained entirely epics for one of the columns queries you would end up with a column with no data in it even if further down rank you had leaf stories that you would of been shown.
The second issue is that due to the Rally's WSAPI ability to fetch fields semi-recursively each child object can be rather large. Some of our customers have a single epic with many many children I didn't want to chance the lack of responsiveness for those customers.
If you are comfortable with this issues on your personal version of our Kanban board you can just listen to the onDataRetrieved event and filter out your unwanted stories.
Internally we are very aware of the annoyances that this causes and we are working to find a good general solution to this issue.
If we release one I will dig this post back up and make sure the new solution is explained.
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.
We are using Microsoft Azure Devops
I am trying to get all the levels to show up underneath each other.
A picture might be easier.
In the below the Epic 'Mobile' has the top feature "As a driver, I want....'
Then under those ther have product backlog items.
How can I get the backlog items to show up directly under the Feature, instead of being duplicated further down?
Here is the query I am using:
That is normal behavior for a query with direct links. You may try to use a tree query with the parameters below:
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.
Is there a way to do this, or is it even possible to view all users (members of a JIRA board) on the actual application? My workaround for this right now is to query for all issues grab the creators and assignees throw them into a list if they're not already in it. I'd like a more efficient way of doing this, but also this workaround isn't going to work for what I need. Our project has multiple boards, there's one board I'm concerned with and it consists of 10 or so members, the project itself has about 50 members. I know I could query and filter results based on a list, but I'm working on making this applicable across all teams. So is there a way to get a list of users on a board instead of project?
JIRA Software provides a REST API resource to retrieve all issues of a board: GET /rest/agile/1.0/board/{boardId}/issue
Once you have that list you still have to run over all the issues and retrieve the details of each issue, e.g. by using GET /rest/api/2/issue/{issueIdOrKey}. That way you can collect the users that you need.
This still requires some scripting, but should be easy to make this generic so you can support any board.
I am attempting to get some information about all User Stories in the current sprint. I can get the path to the current sprint easily, and given a list of the IDs for the work items I can get what I need from them, but I am unsure of how to get those IDs from just the iteration path.
I have seen an example of this using C# and queries, but I am using javascript and the REST API, and I would prefer not to user queries if possible.
The best way to achieve this is using queries which designed to help you find work items that you want to review, triage, update, or list in a report.
The Work Item Query Language is also supported with REST API. There is a Parameter [System.IterationPath] which meets your requirement.
More detail info please refer:
Programmatically query for work items
• REST APIs: Work item queries and query folders and Work item
query language
The only generic solution I could find was to get all work items ids by iterating all pages from Read Reporting Revisions
Then get bulks of work items from List Work Items
Unfortunately TFS/AzureDevops do not offer a shorter path without using queries.