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 27 days ago
- Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint
Updated by Tom Clegg 24 days 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 20 days 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 19 days ago
- Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint
Updated by Tom Clegg 18 days ago
Rebased to main.
22154-included-kind @ 2edc88d49056df1c2bf06602ead51b9aa9480560 -- developer-run-tests: #4503
Updated by Brett Smith 18 days 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 13 days ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|f7d4b53226017e236002f7e2887335084dfe92bb.