Bug #22154
closed
group contents API returns "kind: arvados#object" for User objects in "include: owner_uuid" instead of "arvados#user"
Updated by Peter Amstutz 3 months ago
- Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint
Updated by Tom Clegg 3 months ago
- 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
Updated by Tom Clegg 2 months 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)
Updated by Peter Amstutz 2 months ago
- Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint
Updated by Tom Clegg 2 months ago
Rebased to main.
22154-included-kind @ 2edc88d49056df1c2bf06602ead51b9aa9480560 -- developer-run-tests: #4503
Updated by Brett Smith 2 months 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.
Updated by Brett Smith 2 months ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|f7d4b53226017e236002f7e2887335084dfe92bb.