TFS 2019 and commitment issues

My JavaScript TFS extensions broke in TFS Azure DevOps 2019. All my complaints about TFS API surface being underdocumented came to their logical conclusion: no docs means no API commitment, no commitment means the team behind the API gets to make breaking changes with no guilt.

Let me count the ways things broke:

Federating TFS tables across collections

UPDATE: the outlined logic will break if your TFS instance has a mix of pre-AzDevOps collections with recently (2019+) created ones. Details here. The linked gist was updated, too.

As I've mentioned earlier, Team Foundation Server stores its data in multiple databases - one database per team project collection, and also a global database called Tfs_Configuration. How is one supposed to run cross-collection queries, then?

Can't we just do a "Hello, world"?

The Joomla! component tutorial walks you through creating a Model-View-Controller (MVC) component. However, the Absolute basics of a component page also mentions that a component doesn't have to be MVC; it claims that a flat model is supported, but then spends no time explaining how it's supposed to work.

Name means ID, ID means name

Let's take a break from TFS.

This time, it's Joomla!, a popular Web CMS, which has an expansive, if sorely underdocumented, extension interface. Once again, I've discovered a little undocumented something, and would like to share.

Constrained and dignified

Another day, another TFS Azure DevOps discovery.

I was facing a minor usability issue. We have an extension with several custom menu commands for release definitions pipelines. Out of those, two only make sense for server administrators. For anybody else, they'd error out anyway. The menu was getting crowded, so I wanted to see if I could make the admin-only commands hidden for non-admin users.

All TFS clients

The TFS API continues to be sorely underdocumented. This time, let's talk about the .NET one for a change. You're supposed to first construct a VssConnection, then get a client class or several. There's a separate client for source control, a client for work items, one for build/release tasks, etc. Here are all client classes that I could find in TFS 2018u1:

Who am I and what are my rights (in TFS)?

Some time ago, we've discussed OAuth in TFS. Recently, I've been attacking a related problem - we have a valid OAuth-based connection (a VssConnection object), it can invoke some REST endpoints via OAuth, but which ones? Turns out, the allowed scopes are stored within an OAuth token, it just takes a bit of parsing to retrieve. The following line on an ASPX page returns the scopes for a token:

string Scopes = new System.IdentityModel.Tokens.JwtSecurityToken(Token).Payload["scp"];

There's a sample gist for that.