Arvados

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/ecf96ade39e828e7456a80adee8399d5653fa1d2
Test run: developer-tests-workbench2: #264

Custom component to display owner name if present

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?

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/676a8457983ed1660493f747cc4bb506c8ddbe9c
Test run: developer-tests-workbench2: #269

Custom component to display owner name if present

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.

New version first commit: https://dev.arvados.org/projects/arvados-workbench-2/repository/revisions/c6ccae902b16d7ff421e87f1b9c3578ef8a4334e
Test run: developer-tests-workbench2: #281

Fixed typings

LGTM, thanks!