Bug: Cards showing "Unassigned" for work items that are assigned

[mvonballmo]

Observed

Some cards show Unassigned when they are actually assigned. When opened, the work items are actually assigned.

Expected

Cards show the actual assignee in all cases.

Analysis

I have not been able to determine any pattern to when a card shows unassigned instead of the actual assignee.

• There are direct team members where the assignee is sometimes shown correctly and sometimes not
• There are cards that show indirect team members (e.g. included via a group) correctly
• There are cards that show assignees who are not even team members

So far, it just seems random. Since I can't see the implementation, I can't see how the assignees are chosen, so I can't really narrow the problem down any farther.

[edtro]

Dear @mvonballmo

Sorry to hear that you are running into issues. I am trying my best to be of help.

But I have to say that I have never witnessed such behaviour, while I am using this extension myself extensively. And next to this... be aware that there is no auto-refresh implemented, so if someone else modified the item, then you are looking at old data.

What is implemented: really simple... the contents of the field 'System.AssignedTo' should be displayed.

It is easy to track within the devtools of the browser: load your board completely, open up the network tab, clear everything, start a recording session and hit the 'refresh' button from the QBB extension (within the filterbar or custom toolbar at the top left). You will see all of the calls to the REST API. Just review the '_apis/wit/workItems?ids='. You will notice the 'System.AssignedTo' field is included.

You are able to copy past the request and review it in a browser/rest client.

Kr Edward

[mvonballmo]

@edtro Thanks so much for your quick and detailed reply.

This is truly a game-changer extension and I'd like to thank you for having built it.

I've had a look at the results of the web APIs and can see something interesting is going on with our specific example. Azure is not returning full records for all of the assignees.

This is an example from the data request for work items:

This is what it looks like in the boards:

Now that I kind of knew what to look for, I was able to search the code in the browser and found my way to "AppBoard.ts", which creates cards, calculating the assignee with the following logic:

So it ends up choosing unassigned, even though there is a display name.

I suppose we could adjust the logic in QBB to do a fuzzy match on all loaded assignees, to "fix up" those assignees which have appeared without an ID. I.e., we could keep a map of display-name-to-assignees and look up in that when creating a card with a mangled assignee. But that only works if the assignee appears in full somewhere else. Otherwise, you'll still have only the mangled assignee in the data and no other data from which to repair it.

So that's not very promising.

The real question is: why is Azure sometimes sending full data for the assignee and sometimes sending just the display name?

Well, it turns out that, when we imported our data from an on-prem Azure DevOps Server to Azure DevOps Services, some of the work items appear to be assigned correctly, but are actually assigned to a phantom-stub user with the correct display name, but nothing else. This is actually a subtle problem in our data that will prevent people from finding all work items assigned to e.g., @me. Work items assigned to these phantom stubs simply won't appear in query results.

When I looked more closely at the work item indicated in the screenshots above, I saw that the assignee had a generic icon.

I simply selected the same user from the assignee list and Azure detected it as a change.

When I saved the item and returned to the board, QBB automatically updated the assignee instantly (without an explicit refresh).

Happily for you, it turns out that the problem is in our data.

[edtro]

Dear @mvonballmo Thank you for your reply.... this really really really made my day :-) Kr Edward