Bug #17205

Render object name instead of owner uuid

Added by Peter Amstutz 11 months ago. Updated 9 months ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
Story points:
Release relationship:


On the collections page, details panel, and probably other places, the "owner" link is rendered as just the UUID. It should get the User or Group object and render the "name" or "full_name" field in addition to the uuid. The "copy" button should still copy the uuid.


Task #17236: Review 17205-render-owner-nameResolvedLucas Di Pentima

Associated revisions

Revision f696af6e
Added by Daniel Kutyła 9 months ago

Merge branch '17205-render-owner-name'
closes #17205

Arvados-DCO-1.1-Signed-off-by: Daniel Kutyła <>


#1 Updated by Peter Amstutz 11 months ago

  • Description updated (diff)

#2 Updated by Peter Amstutz 10 months ago

  • Target version set to 2021-01-20 Sprint

#3 Updated by Peter Amstutz 10 months ago

  • Assigned To set to Lucas Di Pentima

#4 Updated by Peter Amstutz 10 months ago

  • Assigned To changed from Lucas Di Pentima to Daniel Kutyła

#5 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#6 Updated by Daniel Kutyła 10 months ago

  • Status changed from New to In Progress

#7 Updated by Peter Amstutz 9 months ago

  • Target version changed from 2021-01-20 Sprint to 2021-02-03 Sprint

#9 Updated by Lucas Di Pentima 9 months ago

Some comments:

  • At file src/views/collection-panel/collection-panel.tsx:L292 there's what I think is a debugging string.
  • Owner columns on data explorer don't show the object's parent name. Although this isn't useful for the project panel view, it is for the favorites views.
  • UI opinions on my part:
    • Instead of showing the UUID and the name in parenthesis, could we show the name when available and the uuid as a tooltip? That way we will get shorter strings on the interface.
    • The project's owner name on the details panel is in lowercase, I think it should be displayed as is, specially when a project's owner is a person.
  • About the solution approach:
    • If I understand it correctly, what it has been added is a uuid->name map to the app's store, right? If that's the case, I think it's a lot better to use what the app already has in the store: the resources object cache, that saves all the information retrieved from the backend, including names. This will avoid making resource store maintenance more of a burden, because in the current solution we're not updating the new uuid->name map when the names change, for example. Instead, the app already updates the resources store whenever a change is made from the user, or (ideally) an event is received from websocket.
    • As a proof of what I mean on the bulletpoint above, try the following:
      • Create a test project
      • Inside it create a collection and open the details panel on the right
      • Go back to the test project and change its name
      • Go back to the collection, check the details panel: the owner's name won't be updated.
    • Sometimes the local resources store won't have the object with the uuid that needs translation to a name. In that case, we already have a set of render helper functions on src/views-components/data-explorer/renderers.tsx, so I think the best would be to either add one renderNameOrUuid() or improve some existing one.
    • Sometimes objects won't be visible to the user (ie: requesting a certain UUID will get a 404), so we might think a good enhancement would be to make the renderer function request those resources that aren't the local store. This will probably make the app do many unnecessary requests. I think a proper resources caching solution is needed for this, and I don't think it should be a part of this ticket, we can leave the current feature render the name whenever it's available, and that I think will be OK most of the time, as the user navigates through the app, the resources store will get filled on demand. Let's discuss this with the rest of the team?

#11 Updated by Peter Amstutz 9 months ago

  • Target version changed from 2021-02-03 Sprint to 2021-02-17 sprint

#12 Updated by Lucas Di Pentima 9 months ago

Some comments:

  • At file src/views/collection-panel/collection-panel.tsx Line 292 there's still a debugging string: "AAAAAAAAAAAAAAAPortable data hash"
  • At file src/views-components/details-panel/project-details.tsx Line 64 there's a lowercase setting set to true. This is inconsistent with the process & collections details panel. I think it should be removed.
  • If uuid and name must be displayed at the same time, I think the best option is to construct the string like "Object name (obj-uuid)" instead of the other way around, because names are meant for humans and IMO it's easier on the eyes if names are the first thing that the user reads.
  • At file src/views-components/data-explorer/renderers.tsx Line 446 you do an any casting to access a fullName member. I think we could do a couple of things to improve this:
    • Take advantage of the strongly typed nature of TypeScript and instead of casting to any, check what type resource is and act accordingly.
    • The User type has a getUserFullName() function, and I think it's preferable to access the backend's .fullName member, because as you can see in the API doc page (https://doc.arvados.org/v2.1/api/methods/users.html), it isn't part of the official API spec and will surely disappear in the short/medium term.

#14 Updated by Lucas Di Pentima 9 months ago

LGTM, thanks!

#15 Updated by Daniel Kutyła 9 months ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF