Bug #22154: group contents API returns "kind: arvados#object" for User objects in "include: owner_uuid" instead of "arvados#user" - Arvados

Target version changed from Development 2024-10-23 sprint to Development 2024-10-09 sprint
Assigned To set to Tom Clegg
Status changed from New to In Progress

22154-included-kind @ 93f1338aa6a87918ecb293b881d6ef3d7ce6a802 -- developer-run-tests: #4492

22154-included-kind @ 93f1338aa6a87918ecb293b881d6ef3d7ce6a802 -- developer-run-tests: #4494

Actions

Copy link

Updated by Tom Clegg about 1 month ago

The fix was just to add the tpzed→User entry to the infix→type map.

Added a test, and added tpzed and the other missing resource types to that map.

22154-included-kind @ 598a6606d54fe3d8ccc27ae9f7328dce0400d42f -- developer-run-tests: #4495 (see #22184)

retry developer-run-tests: #4498 (workbench2 failed this time)

Actions

Copy link

Updated by Peter Amstutz about 1 month ago

Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint

Actions

Copy link

Updated by Tom Clegg about 1 month ago

Rebased to main.

22154-included-kind @ 2edc88d49056df1c2bf06602ead51b9aa9480560 -- developer-run-tests: #4503

Actions

Copy link

Updated by Brett Smith about 1 month ago

Tom Clegg wrote in #note-5:

22154-included-kind @ 2edc88d49056df1c2bf06602ead51b9aa9480560 -- developer-run-tests: #4503

LGTM, thanks.

As a meta point of discussion, this is a good example of that problem I was talking about a few sprint retrospectives ago, where we pay the costs of a monorepo but don't reap the benefits. It's frustrating that we have several variations of this map throughout our codebase and no effective way to keep them in sync.

Actions

Copy link