Closed vincenormand closed 3 years ago
Dear @vincenormand, Thank you for your feedback.
Just to explain some things...
The core concept of this extension is: turning the resultset of a wiql query into a board... and doing this without needing any additional setup. If Azure Boards itself would allow editing the wiql query it is based upon, it would put my extension out of business.
While executing the query you have the advantage to query cross teamproject, just to name one of the advantages... but you do not have the context of the teams or boards or whatsoever. Because of this, you cannot expect this extension to be exactly the same as the standard Azure Boards (and I have not the time to put in all of the effort that it would cost, to come even close).
Also please note: that within the SDK for creating extensions you are limitted in what you can do, you cannot implement the same things as the Azure DevOps product team can.
So one of my first disclaimers on the marketplace is:
IMPORTANT: Not all of the features that are available within the standard out of the box boards are implemented within this extension or in the exact same way. However this extension will provide several features that are not available (yet) within the standard.
So Yes... I know that there are differences and there are features missing or different.
There are a couple of other issues posted within this GitHub repo, regarding extra features for colums. Like merging multiple states or basing the columns upon a other field (a picklist?).
I do not know in what way your request is different as these... but these could be considered for implementation.
But if you are expecting a solution like it is implemented within Azure Boards, that it would create hidden fields etc. etc. then I am sorry to say, that this is something I am not considering to implement.
Kr Edward
Hi Edward,
I understand the limitations and everything. But I am not asking it to be the same as the Board from MS, neither talking about a picklist or a hidden field...
Just so you understand better, here is an example of the Board that we have in every Azure DevOps Project :
Our Boards are configured exactly the same in all our Projects. As you can see, the Board columns are not based on the field "State", it is base on the field "BoardColumn".
All I am asking, is if it would be possible to use the "BoardColumn" field instead of the "State". If you do not think it is a good idea, or it is too complex to implement, it is ok. I am just asking.
Either way, this is a great extention ! Keep up the good work !
Dear @vincenormand,
The field 'System.BoardColumn' is not editable, just like the 'System.BoardDone' field.
For each team/board seperate invisible 'WEF_' fields are created, that are edited by the system (there is an API where you can get the information regarding this, but you will need a teamcontext as a start, but I do not know if the SDK has implemented the endpoint for this API). A rollup is done to the 'System.BoardColumn' and 'System.BoardDone' and the value is written to these fields, of wich team/board the system thinks that owns the workitem.
This makes it very hard to use the 'System.BoardColumn' as a basis for the QBB boards. For using the 'System.BoardDone' I had to make a nasty workaround, that seems to work fine for a client (with an onpremise org) for the time being.
So I get the idea, but using a custom picklist for this, would be mutch easier...
So please follow the issue #23
Edward @edtro, I never responded to your question on "Base the columns values on another (custom) picklistfield" #23 and now that some time has passed along with the recent implementation of query-based boards with iterations as columns #39 I thought I would elaborate.
Like @vincenormand we have an environment where all are boards are consistent across projects and we use board columns instead of state. And while you can modify/customize state beyond New, Active, Resolved, and Closed, we have chosen not to because it is extremely complex for a small organization.
What we would like to see is the ability to use board column something like this…
{
"columns":[
{
"name":"New",
"title":"New"
},
{
"name":"Next",
"field":"System.BoardColumn",
"title":"Next",
"workItems": [
{
"type": "User Story",
"stateMapping":"New"
},
{
"type": "Bug",
"stateMapping":"New"
},
{
"type": "Feature",
"stateMapping":"New"
},
{
"type": "Epic",
"stateMapping":"New"
}
]
},
{
"name":"Research/Design",
"field":"System.BoardColumn",
"title":"Research/Design",
"workItems": [
{
"type": "User Story",
"stateMapping":"Active"
},
{
"type": "Bug",
"stateMapping":"Active"
},
{
"type": "Feature",
"stateMapping":"Active"
},
{
"type": "Epic",
"stateMapping":"Active"
}
]
},
{
"name":"Development",
"field":"System.BoardColumn",
"title":"Development",
"workItems": [
{
"type": "User Story",
"stateMapping":"Active"
},
{
"type": "Bug",
"stateMapping":"Active"
},
{
"type": "Feature",
"stateMapping":"Active"
},
{
"type": "Epic",
"stateMapping":"Active"
}
]
},
{
"name":"Testing",
"field":"System.BoardColumn",
"title":"Testing",
"workItems": [
{
"type": "User Story",
"stateMapping":"Resolved"
},
{
"type": "Bug",
"stateMapping":"Resolved"
},
{
"type": "Feature",
"stateMapping":"Resolved"
},
{
"type": "Epic",
"stateMapping":"Resolved"
}
]
},
{
"name":"Implement",
"field":"System.BoardColumn",
"title":"Implement"
"workItems": [
{
"type": "User Story",
"stateMapping":"Resolved"
},
{
"type": "Bug",
"stateMapping":"Resolved"
},
{
"type": "Feature",
"stateMapping":"Resolved"
},
{
"type": "Epic",
"stateMapping":"Resolved"
}
]
},
{
"name":"Closed",
"title":"Closed"
}
]
}
This would mimic this…
As state can be changed (state mapping) when moving a work item from one board column to another you would need to add “workItems” to define what the state change might be for a particular work item similar to how it is set when defining board settings.
Dear @tgolla
You have mentioned this "And while you can modify/customize state beyond New, Active, Resolved, and Closed, we have chosen not to because it is extremely complex for a small organization."
I am checking the work items that will be shown within the board, and I am adding dynamically the states of the workitem(s) as columns.
So If the query has as a result;
Four columns will be shown, but you are not be able to move the Issue to the column 'Resolved', because it is not allowed (when you start dragging an item, the columns will highlight where you are able to move it towards).
So in your case, I do not have to implement anything, it is already there.
Kr Edward
Edward @edtro
I think you might have missed what I was getting at. With the following query and setup configuration, the only columns that display are New and Closed. None of the columns defined with the "field":"System.BoardColumn"
display.
SELECT
[System.Id],
[System.TeamProject],
[System.Title],
[System.IterationPath],
[System.BoardLane],
[System.BoardColumn],
[Microsoft.VSTS.Scheduling.StoryPoints],
[System.Tags],
[System.AssignedTo]
FROM workitems
WHERE
[System.WorkItemType] <> ''
AND [System.TeamProject] <> 'Play Ground'
ORDER BY [System.AssignedTo],
[System.BoardColumn]
{
"columns":[
{
"name":"New",
"title":"New"
},
{
"name":"Next",
"field":"System.BoardColumn",
"title":"Next"
},
{
"name":"Research/Design",
"field":"System.BoardColumn",
"title":"Research/Design"
},
{
"name":"Development",
"field":"System.BoardColumn",
"title":"Development"
},
{
"name":"Testing",
"field":"System.BoardColumn",
"title":"Testing"
},
{
"name":"Implement",
"field":"System.BoardColumn",
"title":"Implement"
},
{
"name":"Closed",
"title":"Closed"
}
],
"swimlanes":{
"field":"System.BoardLane",
"defaultValue": "",
"values":[
{
"value":"Development",
"title":"Development"
},
{
"value":"Bugs",
"title":"Bugs"
},
{
"value":"Technical Debt",
"title":"Technical Debt"
}
]
}
}
Dear @tgolla,
Sorry that I have misunderstood. The fields that you are mentioning (e.g. System.BoardColumn and System.BoardLane) cannot be modified while using the SDK. So these cannot be used, and that is really unfortunate.
The best that you can do is setting up new picklist fields and use these within your configuration. I do not see any other options.
(besides storing all the data within the extension data, but that would mean a complete redesign of my extension and that is something I am not willing to do).
Kr Edward
The board columns are actually based on de System.State field, which is not how it works in Azure DevOps. Board columns are very useful to follow de developpement progress (for example : Analysis, Approval pending, Development, Revision, QA, etc.)
I know every project has to have the same configuration of Board columns for it to work. But would it be possible to have a look at that feature ? It would really help our dev teams follow the development progress of many projects at once.
Thank you !