"No Data" error message for very simple Query.

[bewalterBL]

We are working on premises on a Azure DevOps Server 2020 (Version Dev18.M170.6) with the xml process template. I installed the version 0.20326.3 of Query Based Boards yesterday. Unfortunately I always get the "No Data - Please review the query. Please note that only 'flat' and 'one-hop' queries are implemented." error message, even for very simple queries.

An example Query I used: Wiql: select [System.Id], [System.Title] from WorkItems where [System.TeamProject] = @project and [System.WorkItemType] = 'Feature' and [System.State] <> 'Done' and [System.State] <> 'Removed'

Is this a known issue or can you give me any hint how I can investigate what the root cause might be?

Aspects that might have influence: We defined quite some custom fields and also some custom states. I am currently working over a VPN connection. But also colleagues working directly on their machines have that issue.

[edtro]

Hi,

Sorry to hear that you have some issues.

First of all... make sure that you have saved your query definition.

Can you please check within your browser > development tools (F12) > console. Are there any error messages?

There can be a couple of reasons that this message appears...

1. that actually there is no data to display (please review the query resultset)
2. that you have a created a configuration and the json has issues (see: https://github.com/edtro/EdTro.AzureDevOps.Extensions.querybasedboards/blob/master/public/config.md). This occurs when you e.g. use a fieldname that does not exist. So when you use 'system.states' instead of 'system.state'... it cannot resolve this field, that will result in this 'no data' screen. (this is something that is on my to-do list for this feature that has been released as 'in-preview')

So can you provide me some extra information please?

Normally the extra fields/states within the process definition xml should not be a problem, because I am using the standard SDK/API that is provided by Microsoft.

Kr Edward

[bewalterBL]

Hi Edward,

Thank you so much for this quick response. That is what I call great commitment.

The query I am trying is rather easy, I saved it and it shows results. Also I did not use any configuration yet.

But actually I found something in the development console that might be related to the extension:

index.qbb.bundle.js:1 TFS.WebApi.Exception: TF51535: Cannot find field Microsoft.VSTS.Scheduling.StoryPoints. at Object. (https://devops.brainlab.net/_apis/public/gallery/publisher/realdolmen/extension/EdTro-AzureDevOps-Extensions-QueryBasedBoards-Public/0.20326.3/assetbyname/js/commons-53fa57c8.qbb.bundle.js:1:8764) at https://devops.brainlab.net/_apis/public/gallery/publisher/realdolmen/extension/EdTro-AzureDevOps-Extensions-QueryBasedBoards-Public/0.20326.3/assetbyname/js/commons-53fa57c8.qbb.bundle.js:1:7308 at Object.next (https://devops.brainlab.net/_apis/public/gallery/publisher/realdolmen/extension/EdTro-AzureDevOps-Extensions-QueryBasedBoards-Public/0.20326.3/assetbyname/js/commons-53fa57c8.qbb.bundle.js:1:7413) at a (https://devops.brainlab.net/_apis/public/gallery/publisher/realdolmen/extension/EdTro-AzureDevOps-Extensions-QueryBasedBoards-Public/0.20326.3/assetbyname/js/commons-53fa57c8.qbb.bundle.js:1:6156)

Does this already help, or do you require the full log? Best Bernhard

[bewalterBL]

I checked our process templates. We are using the Scrum Process Template as basis. There is no field Microsoft.VSTS.Scheduling.StoryPoints but instead the field Microsoft.VSTS.Scheduling.Effort

Might this cause the issue?

[edtro]

Hi,

Yes this might be the problem.

This scenario is tested on an online environment... and with the PBI's I didn't have this problem. Also I have an on premise environment, that uses the scrum process template with a lot of changes... but this is still AzDO 2019. Also no problems.

I have an idea for a solution. I am committed to actual resolving this problem.

You could try to do the following (see ref: https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/get%20work%20item?view=azure-devops-rest-6.1)...

Use the REST api directly from the browser:

• Like this: https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/{id}?fields={fields}

• In your case if would be something like: https://yourserver/yourproject/_apis/wit/workitems/{id}?fields={fields}

• Use for the {id} an actual id of a PBI like example 12345

• for {fields} first use: 'system.state,Microsoft.VSTS.Scheduling.Effort' like: https://yourserver/yourproject/_apis/wit/workitems/12345?fields=system.state,Microsoft.VSTS.Scheduling.Effort

• then use 'system.state,Microsoft.VSTS.Scheduling.StoryPoints' like: https://yourserver/yourproject/_apis/wit/workitems/12345?fields=system.state,Microsoft.VSTS.Scheduling.StoryPoints

With the last command, I am just getting the system.state field like I am expecting.

Can you please check this?

Kr Edward

[edtro]

Never mind: I have already checked on an AzDO 2020. This is the root cause of the problem. Now I am able to resolve it :-)

[bewalterBL]

So nothing left for me to check, right? Thank you very much for digging into it right away.

[edtro]

Maybe it is best that you should check this, just to make certain. Kr Edward

[bewalterBL]

Yes it is like you expected

The call with StoryPoints returns an exception:

{"$id":"1","innerException":null,"message":"TF51535: Cannot find field Microsoft.VSTS.Scheduling.StoryPoints.","typeName":"Microsoft.TeamFoundation.WorkItemTracking.Server.Metadata.WorkItemTrackingFieldDefinitionNotFoundException, Microsoft.TeamFoundation.WorkItemTracking.Server","typeKey":"WorkItemTrackingFieldDefinitionNotFoundException","errorCode":0,"eventId":3200}

While the first call with "Effort" returns:

{"id":10982,"rev":56,"fields":{"System.State":"New"},"_links":{"self":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_apis/wit/workItems/10982"},"workItemUpdates":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_apis/wit/workItems/10982/updates"},"workItemRevisions":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_apis/wit/workItems/10982/revisions"},"workItemComments":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_apis/wit/workItems/10982/comments"},"html":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_workitems/edit/10982"},"workItemType":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_apis/wit/workItemTypes/Feature"},"fields":{"href":"https://devops.brainlab.net/rnd/2597fda7-10c8-4685-9db6-74496b408cc1/_apis/wit/fields"}},"url":"https://devops.brainlab.net/rnd/_apis/wit/workItems/10982"}

[edtro]

Ok, thanks... now I am really certain :-)

[edtro]

I think that I have found a solution, but I still need some testing to do.

[edtro]

@bewalterBL Hi, I have just released the extension, containing my fix. I am using an extra API call to determin if the fields are present within the projectcollection.

So I am calling this: GET https://dev.azure.com/{organization}/_apis/wit/fields (Ref: https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/fields/list?view=azure-devops-rest-6.1)

Hopefully this will solve your problem.

Kr Edward

[bewalterBL]

Great, thank you so much. It is working!

[edtro]

Ok, that is great! Thanks for reporting this issue and giving me the detailled information that I needed to resolve this problem. Highly appreciated!