edtro / EdTro.AzureDevOps.Extensions.querybasedboards

Query Based Boards enables a user to visualize the result of work item queries as a board and track the dependencies.
MIT License
23 stars 2 forks source link

Bug: queries not shown in settings after project is renamed #47

Open JamborJan opened 3 years ago

JamborJan commented 3 years ago

Quick tipp

If you are stumbeling over the same issue, see the workaround solution here: https://github.com/edtro/EdTro.AzureDevOps.Extensions.querybasedboards/issues/47#issuecomment-812130248

Original request

I've created a couple of shared queris in a project and none of them is showing up in the project settings to allow configuration. I guess there is something screwed up but I don't know exactly where to start. I've a couple of projects where I've done similar setups and it's working quite well.

Special in the affected project: it has been renamed.

Other inputs or hints: in the development console of the brwoser I get a 404 when I want to open the settings:

GET https://server/collection/_apis/ExtensionManagement/InstalledExtensions/realdolmen/EdTro-AzureDevOps-Extensions-QueryBasedBoards-Public/Data/Scopes/Default/Current/Collections/querybasedboards-import/Documents 404 (Not Found)

When I run a query and click the "show as board" button there is a super quick error message I'm not able to capture. In the developer console I see a bunch of errors:

ms.vss-web.platform-…jTC5yBclkr.min.js:1 POST https://server/collection/_apis/ExtensionManagement/InstalledEx…copes/Default/Current/Collections/querybasedboards-configuration/Documents 400 (Bad Request)

Could not create configuration for query: ee5fca6e-219e-4811-a071-4bedefa767da

GET https://server/collection/_apis/GraphProfile/MemberAvatars/win.Uy0xLTUtMjEtMzMwMDg0MjA5Mi04MTkxODE4MjUtMjEzMzgyNzUzOC0zMzg1MQ 401 (Unauthorized)

(I guess the last one is not relevant, only to be complete)

What I also can say: I can add the global config but it is not repected in the queries.

Please let me know how I can help to investigate further.

EDIT Just found out a very important thing I guess: I had a collection backup restored as test environment before we renamed the affected project. And before we renamed the project the queries have worked propperly. So I assume that this is linked to renaming projects.

edtro commented 3 years ago

Hi @JamborJan, It looks like that indeed the renaming of the project is causing the problem.

I have already checked my code... so I know this is case.

I will try to explain:

I already noticed that when I delete a teamproject and create a new one, that my configurations would pop up within the new teamproject. But because the queryids are not the same, this was no problem.

But in your case, which is a very plausible usecase... the queryid is the same, so the document already exists... but the projectname does not match.

So this is something I have to look into.

I will have to think about this.

Kr Edward

JamborJan commented 3 years ago

Short question: is there a way I can manually fix this for the one project affected in my case? E.g. can I manually update the document to have the right project name?

edtro commented 3 years ago

Hi @JamborJan Well it is possible, but it won't be easy. At this moment I do not have a lot of spare time. So I am only able to give you a couple of pointers.

I have documented a way to import configurations, see: https://github.com/edtro/EdTro.AzureDevOps.Extensions.querybasedboards/blob/master/public/imports.md

I have put some effort into it to document a couple of Microsoft REST api methods... the GET and the POST. But you will need the update (the PATCH I think is should be). But you should use an other collection as with the import. You have to update the documents directly.

Keep in mind, that while using this.... you could break a lot of things. (I have some safety build in, that no unwanted data, types or even scripts can be loaded within the boards)

Kr Edward

JamborJan commented 3 years ago

Dear @edtro, I appreaciate your help even though you have no time. So please don't take this not as request for immediate action. Only feedback.

I was able to get started with the import documentation you gave. Unfortunately the error you described occurs not only the first time but always. So I'm stuck at this point right now. I'll dig deeper if possible.

The first time you will get the following exception:

{
  "$id": "1",
  "innerException": null,
  "message": "%error=\"1660002\";%:The collection does not exist\r\n%error=\"1660002\";%:The collection does not exist",
  "typeName": "Microsoft.VisualStudio.Services.ExtensionManagement.WebApi.DocumentCollectionDoesNotExistException, Microsoft.VisualStudio.Services.ExtensionManagement.WebApi",
  "typeKey": "DocumentCollectionDoesNotExistException",
  "errorCode": 0,
  "eventId": 3000
} 

Also the mentioned API Version ?api-version=3.2-preview1 is not valid in any of my environments (on prem = Azure DevOps 2020; cloud = Azure Devops Service). Not sure if this is linked together.

edtro commented 3 years ago

Did you try using 'querybasedboards-configuration' instead of the 'querybasedboards-import' collection? Kr Edward

JamborJan commented 3 years ago

Oh, yes you wrote I have to change that. with that change it's possible to get the object data and by appending the object id to the url I can also receive the data from exact one object.

I can once again confirm that in that data the old project name is written.

I must find a way now to update that. The first try to do it with a PATCH request like it's done for example for work item updates via API was not successfull (invalid reques). I'll have to try-n-error a bit more here I guess.

edtro commented 3 years ago

Yes, I think you have to put the documentid within the url (at the end). I didn't had to try this myself as of yet. Kr Edward

JamborJan commented 3 years ago

I guess I found a efficent solution to that: rather than updateting the document, I'm deleting it and create it fresh from scratch via UI. At least in a test scenario that work quite well. I'll check that in detail later. But when this is tourning out to be a solution I guess this issue is not as hot anymore.

For anybody else reading this: here are the on-prem and service version of the API Request I'm using,

Service: get all documents

GET https://extmgmt.{{uri}}/{{organization}}/_apis/extensionmanagement/InstalledExtensions/{{publisherName}}/{{extensionName}}/Data/Scopes/Default/Current/Collections/querybasedboards-configuration/Documents/

Service: get a specific document

GET https://extmgmt.{{uri}}/{{organization}}/_apis/extensionmanagement/InstalledExtensions/{{publisherName}}/{{extensionName}}/Data/Scopes/Default/Current/Collections/querybasedboards-configuration/Documents/{{QueryID}}

Service: delete a specific document

DELETE https://extmgmt.{{uri}}/{{organization}}/_apis/extensionmanagement/InstalledExtensions/{{publisherName}}/{{extensionName}}/Data/Scopes/Default/Current/Collections/querybasedboards-configuration/Documents/{{QueryID}}?api-version=6.0-preview.1

For on-prem the same with another base URL (for Azure Devops Server 2019, not fully tested yet):

GET https://{{uri}}/{{collection}}/_apis/extensionmanagement/InstalledExtensions/{{publisherName}}/{{extensionName}}/Data/Scopes/Default/Current/Collections/querybasedboards-configuration/Documents/{{QueryID}}

GET https://{{uri}}/{{collection}}/_apis/extensionmanagement/InstalledExtensions/{{publisherName}}/{{extensionName}}/Data/Scopes/Default/Current/Collections/querybasedboards-configuration/Documents/{{QueryID}}

DELETE https://{{uri}}/{{collection}}/_apis/extensionmanagement/InstalledExtensions/{{publisherName}}/{{extensionName}}/Data/Scopes/Default/Current/Collections/querybasedboards-configuration/Documents/{{QueryID}}?api-version=5.0-preview

Again thanks a lot for your help, very much appreciated.

edtro commented 3 years ago

Hi @JamborJan Great to hear, that you have managed to find a workaround. This is great input! Thanks, highly appreciated.

Kr Edward

JamborJan commented 3 years ago

I wanted to confirm, that everything worked as expected also in my production environments. I deleted the configuration documents linked to the query IDs and the wrong old project name as described above and created the new ones manually in the settings hub again.

edtro commented 3 years ago

Great!

I will be investigating this, so this will not happen again. But it will not be easy, because it means that I will have to use the projectId instead of the projectName, but the configs should work correctly with the old data.

Kr Edward