-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable navigation by driveAlias in the Web UI #6648
Comments
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. ;-) |
We're taking about 700 project spaces, 35k home spaces and 200K share spaces ... |
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? |
@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 The For the projects, I don't know the layout. |
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:
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. |
@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 ( ... |
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"). |
@kulmann we expect this URL: Where: |
@labkode looking at the example in your initial post,
|
No need a priori, in case is needed, we'll expose a new space.
Drive aliases for EOS will be dynamic (not only 4 slashes). |
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. |
Work in progress. |
Given the following space:
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?
The text was updated successfully, but these errors were encountered: