Enable navigation by driveAlias in the Web UI

[labkode]

Given the following space:

{
   "value":[
      {
         "driveAlias":"/eos/user/h/hugo",
         "driveType":"personal",
         "id":"aaaa-bbbb-cccc-dddd",
         "webdavUrl":"https://cernbox.cern.ch/dav/spaces/eos/user/h/hugo"
   ]
}

Navigation works by id:

https://cernbox.cern.ch/files/spaces/aaaa-bbbb-cccc-dddd/relative/path/to/file.txt

We expect navigation to work with driveAlias:
https://cernbox.cern.ch/files/spaces/eos/user/h/hugo/relative/path/to/file.txt

Is this implemented?
If yes, how can we enable it?

[kulmann]

This is not implemented, yet. We're currently working on the sharing jail implementation (see #6593 and #6448 for details). Expected to be done approx. 4th of April. Having the drive alias in the URL is planned after that. Together with showing custom drives with their own nav items and routes in the web ui that will at least take another week.

Could you please share your static spaces config with us within the next few days? We'll probably hardcode titles and icons for you for the start. For that we need a reference. Happy to receive that via mail, share, chat, ... if it contains confidential data. ;-)

[labkode]

We're taking about 700 project spaces, 35k home spaces and 200K share spaces ...
My understanding is that the call to /drives/me only returns the spaces the user has access to, so we'll be only returning a subset (1 personal space, multiple share spaces and multiple project spaces).
Our implementation will be dynamic, meaning that we won't have the spaces registry loaded from a static file.

@micbar @butonic ?

[kulmann]

Awesome to hear that it's dynamic. Is it still possible for you to provide a list of required nav items with a) icon, b) title, c) drive type to be mapped to a url? Or are the drive types dynamic as well? If the drive types are dynamic then that's far beyond the scope that we discussed. :-/

Do you already have an ETA for having the space listing backend side?

[micbar]

@labkode I was assuming that we could also use a static approach. Let me change your snippet

{
   "value":[
      {
         "driveAlias":"eos/user/",
         "driveType":"personal",
         "id":"aaaa-bbbb-cccc-dddd",
         "webdavUrl":"https://cernbox.cern.ch/dav/spaces/eos/user/"
    }
   ]
}

If we would use eos/user as the alias, h/hugo would already be part of the relative path. That would mean for all personal spaces we can use a static alias. Would that work?

The id property would be irrelevant in your case because you are using the legacy path based webDav Urls.

For the projects, I don't know the layout.

[kulmann]

I'd like to get some implications of your issue description written down here for transparency / clarity.

Visiting a URL which resolves a space requires the following implementation details to have it fully generic in web:
1: look up drive alias from URL (can have any number of segments, so this might already be multiple requests). this requires backend side filtering drives by driveAlias by the way. not implemented, yet. If you would agree to have the resourceId in the url query params (which we want to have) that's always only 1 request and doesn't require additional backend work.
2: have a generic view which loads resources from the space resolved in (1). at the moment

• resource views are not generic at the moment. they are named and have a hardcoded mapping to routes. they have a 1:1 mapping of routes to resource loader tasks.
• the right sidebar shows panels based on the active route. this means that non-hardcdoded routes would have no right sidebar panels at all. would need a lot of refactoring of the right sidebar logic
• the file actions in resource views (any item that's listed in the right-click contextmenu, in the batch actions and in the right-sidebar actions panel) are partly wired to hardcoded route names / resource views (e.g. "accept share" only available in shared with me route). would again need a lot of refactoring of the file actions logic. Otherwise you would have little to no file actions available in a generic view.
• there's probably more, these are the most obvious implications of making spaces fully generic/dynamic in the web ui.

What we could offer as a short term workaround is duplicating one of our views and catch one drive type into it. If you don't want to have the resourceId in the url and can avoid drive alias clashes server side someone would still need to implement drives filtering by driveAlias.

[labkode]

@micbar if we use the snippet you propose for homes and also for projects we'll have the problem that we do not have a unique ID to identify each user home or project space. Moreover, operations on spaces are done by ID, so we won't be able to profit from space functions like getting a space by ID or updating it. The static registry approach is just an implementation detail, it can be dynamic to avoid dumping the thousands of different spaces we have. We do not want to be on a special track anymore and we need spaces to work out of the box and from what I see in the code, each personal and project space as implemented in OCIS decomposed FS is unique and have a unique ID, so we can't deviate from that. My previous proposal does not deviate from the current implementation and the only controversy I see is regarding @kulmann comments as the Web UI is not ready to navigate by driveAliases.

@kulmann if the web UI gets a the list of spaces the logged in user has access to on login (drives/me) you have all the driveAliases available and you don't need any server side request to understand if the path points to a space or not, you just prefix-match the list you have with the url the user is visiting. Regarding point 2, if you enable resource actions depending on drive type you would solve that issue right? a driveType of type personal will enable certain actions and a driveType of type share will enable you others?

...

[kulmann]

Afaik we have all requirements fulfilled to switch over to drive aliases in the URLs. But only for already existing routes/views. At the moment we can't make it fully dynamic (in the sense of "announce new drive type via backend" -> "have a view that renders the content").
At the moment we're still finishing up the last bits of #7053 which is a prerequisite in order to render drive types personal via URL param.

[labkode]

@kulmann we expect this URL:
https://cernbox.cern.ch/files/spaces/eos/user/h/hugo/relative/path/to/file.txt

Where: /eos/user/<dynamic path> is for personal space
Where /eos/project/<dynamic path> is for project space

[kulmann]

@labkode looking at the example in your initial post, /eos/user/h/hugo would be one space, which you navigate into when clicking on Personal in the left sidebar nav of the web ui. Correct? If yes then I have followup questions:

1. How do you expect users to discover user spaces of other users? If /eos/user/h/hugo is one space we don't have a root level above it where users could navigate to. The space is a webdav root, you can't navigate to any level above.
2. Is there any chance we can get a fixed number of url param segments for the drive aliases? We already have the dynamic path with a variable number of segments / path elements. Having two different variables in the URL (namely 1: drive alias, 2: dynamic file path) will require us to do complicated refactoring of the routing in web. If we could guarantee a certain number of path segments for the drive alias (for ownCloud this would be 2 path segments for the drive alias, always), it would simplify things... if it's also 2 segments for your that would be perfect. If it's always 4, we can at least make it configurable via config.json.

[labkode]

• How do you expect users to discover user spaces of other users? If /eos/user/h/hugo is one space we don't have a root level above it where users could navigate to. The space is a webdav root, you can't navigate to any level above.

No need a priori, in case is needed, we'll expose a new space.

• Is there any chance we can get a fixed number of url param segments for the drive aliases? We already have the dynamic path with a variable number of segments / path elements. Having two different variables in the URL (namely 1: drive alias, 2: dynamic file path) will require us to do complicated refactoring of the routing in web. If we could guarantee a certain number of path segments for the drive alias (for ownCloud this would be 2 path segments for the drive alias, always), it would simplify things... if it's also 2 segments for your that would be perfect. If it's always 4, we can at least make it configurable via config.json.

Drive aliases for EOS will be dynamic (not only 4 slashes).

[kulmann]

Idea came up in a call today (thank you @labkode !) that we could register routes for all drives of the user instead of creating dynamic routes. With that we wouldn't have the drive alias as a dynamic number of route segments anymore. This should solve the limitation of the vue router to only have one dynamic variable in a route (i.e. with a dynamic number of path segments). Needs investigation if that works out as intended.

With the refactoring in #7072 we'll finally have the user loaded before finalizing application boot processes, which is a prerequisite for that. PR needs to be merged as soon as possible so that we can start working on this ticket here.

[labkode]

Work in progress.