Core: Permalinks for folders and files that work across internal users when sharing

[PVince81]

The main use case is being able to easily copy/paste/share links to any shared folder/subfolder/files inside of ownCloud between users, independently from their location.

Current problems with internal folder links

Paths inside links are not consistent across users.

In OC 6

1. User1 shares a folder "test folder" with User2
2. User1 wants to send a link to a subfolder or file, for example: "test folder/subdir/coolfile.odt"
3. User1 copies the browser URL "index.php/files?dir=test%20folder/subdir", then prepends "/Shared" since User2 will have it appear there, the link becomes "index.php/files?dir=Shared/test%20 folder/subdir"
4. User1 sends an email with the link
5. User2 opens the link, which shows the correct folder

Problem: for owner the path inside the link is "/test folder/subdir" but for any other user it's "/Shared/test folder/subdir".

In OC 7

Since OC 7 is is now possible for User2 to store "test folder" anywhere in their ownCloud, so the link "files?dir=Shared/test%20folder/subdir" will not work any more.

Problem: every user can potentially require a completely different path inside the links, and the target path is not predictable. It is not possible to paste a single link in a group email. You'd need to send an individual link to every one.

Extended use case

If User1 moved "subdir" to another location inside that share, the link will not be valid any more for neither User1 or User2.

Introducing permalinks

Concept

Currently, files and folders all have an internal file id which doesn't change most of the time (to be discussed).

The idea is to introduce a new format for link, with the form: "index.php/files?id=12345" where 12345 is the file id of the file or folder.

The workflow would be as follows:

1. User1 shares a folder "test folder" with User2
2. User1 wants a link pointing to "test folder/subdir" to send to User2
3. User1 enters "test folder/subdir" and clicks an anchor icon, which copies the link "index.php/files?id=12345" that points to "subdir"
4. User1 pastes the link in an email dialog with User2
5. User2 opens the link
6. System checks whether User2 has access to the file with id 12345 through any shares
7. System resolves the file id to the path related to User2
8. System redirects the browser to the matching path, for example "index.php/files?dir=allshareswithuser2/test%20folder/subdir".

If User1 moves "subdir" to another location inside of the "test folder" share, the folder will still be accessible with the link "index.php/files?id=12345".

For a file "coolfile.odt", the link would resolve to "index.php/files?dir=test%folder/subdir&scrollto=coolfile.odt" (for now, until we have direct links to files)

Possible extensions

The activity app, for example, could also make use of such permalinks to make sure

Potential problems

Link format not user readable

The link itself would not contain the file name/subdir any more but just the id, which is not user friendly as one cannot easily distinguish links. On the other hand: this is already how it's done for public links. Possible solution: add a dummy parameter in the link with the full path, but the parameter is ignored by the system.

Preserving the file id

We need to make sure that all file operations will preserve the file id.

• As far as I know most basic operations should preserve the file id, which includes renaming, moving.
• Not sure about upload+overwrite, moving between storages.
• Moving between shared folders will most likely NOT preserve the file id, but that might be ok as the sharing information will change as well.
• Deleting, then restoring files will NOT preserve the file id
• ... more research required

I think this would be a nice improvement to solve the age-old question "how can I easily get a link to any folder inside ownCloud and share that link with other internal users ? (without having to fiddle with the URL...)"

@owncloud/designers @MTRichards @karlitschek @craigpg

@icewind1991 @schiesbn for file id questions

CC @LukasReschke

[PVince81]

For the design part, the question is where can the user get access to the permalink.
There are multiple possibilities:

1. Make the anchor tag of the file/folder point to the file id instead of the file name, this makes it copiable with right click + copy
2. Add a new "Link to this" action in the file row (might be too flashy)
3. Add an anchor link in the controls bar "permalink".
4. Simply add the current folder id in the URL: "index.php/files?dir=currentdir&id=1234". When resolving the link it will first try with the id. If it doesn't exist, it will fall back to using "dir".

[jancborchardt]

2 Add a new "Link to this" action in the file row (might be too flashy)

Not another action please. It will only confuse people about what it actually does.

3 Add an anchor link in the controls bar "permalink".

Nope, same as above.

Honestly copying the link/URL is fine in this case and is the thing which should be optimized.

[PVince81]

Ok, then option 4. is probably the best.
Make the URL always include the file id to make it copiable.

[LukasReschke]

Yes. That would make most sense!

Very cool proposal! - I see a lot of very good use-cases for that.

[PVince81]

Note: would volunteer to implement this myself.

[jbtbnl]

What about the following use-case:

1. User shares folder "/latest" with some people
2. User develops a new version of the software in "/dev"
3. User renames "/latest" to "/v1" and "/dev" to "/latest"

Now the user might assume that the link will still work, because the dummy variable shows the path to the latest version of the software. The link indeed still works, but now the people the link was originally shared with cannot reach the latest software.

A kind of a solution would be to only include the folder name (without the full path) in the link.

[PVince81]

True, but there are use cases where even the target name might change.
We could also have only the file id in the URL, but then the links would be indistinguishable. (but I guess that's also how Google docs works, their pathes are only hashes, similar to OC's public links)

[PVince81]

Another problem that it solves is that activities are pointing to specific folders, so when scrolling back in time one won't be able to directly access to files that might have been moved. If the activity app could provide such permalinks, renamed/moved files would still be accessible.

[jbtbnl]

There is definitely a use case for both, but which one should be the default? I'd say the permalink could be the default, with an option for absolute links.

Not sure if @jancborchardt will be happy with two linking options in the UI though :smile:
But removing (new) absolute linking would be a regression for users that are already accustomed to it.

[jancborchardt]

I would say the absolute linking with just a clear name is ok. If stuff is renamed, then it’s renamed.

[PVince81]

Found a few situations where the file id isn't stable: https://github.com/owncloud/core/issues/13310

[PVince81]

@MTRichards

[MTRichards]

This seems like a good polishing item. @karlitschek curious your thoughts?

[PVince81]

Could be useful for the activity app to point to files even when they have been moved/renamed.

[PVince81]

Could be make to work with the trashbin as well in some cases: https://github.com/owncloud/core/issues/11732

[PVince81]

Note to self: file ids can be resolved to the current user's path using \OC\Files\Filesystem::getPath($fileId);. But then it would be nicer to have this on the public API, raised here: https://github.com/owncloud/core/issues/17385

[PVince81]

@karlitschek suggested at some point to reuse public link shares / tokens and then when you open the public link, if you're logged in, show the folder in your actual view (if you have access). Might be worth exploring this approach too.

[karlitschek]

Yes. The only downside is that the sharer who 'tests' the link sees something different then the person who receives the link. Maybe no a critical shortcoming

[PVince81]

Another idea even would be to have a radio button "public link" or "internal link" when sharing, and reuse the token mechanism. But might bloat the UI a bit more.

[MorrisJobke]

Another idea even would be to have a radio button "public link" or "internal link" when sharing, and reuse the token mechanism. But might bloat the UI a bit more.

Why two different links? And why another token even if we already have the fileid? What about showing something on the sharing page like:

• this is your share <button>show it in my owncloud</button> and
• (for other people that have this in their owncloud) you already have this in your owncloud <button>show it in my owncloud</button> and
• (for people that don't have it) <button>add this to your owncloud</button> (this is already implemented)

[MorrisJobke]

This makes it not so confusing, because you still see the public share page but will be able to browse easily to the internal view

[PVince81]

Yeah, that also sounds like an idea.
And for internal sharing we could add "&internal=1" in the URL to make it directly jump to the internal view, if available ?

[MorrisJobke]

And for internal sharing we could add "&internal=1" in the URL to make it directly jump to the internal view, if available ?

Why? We should make each link simply copyable and then you will get a the internal page (if this file is your own or shared with you) or an page with "This looks like a file that isn't accessible for you - ask the owner if it can be shared with you"

[MorrisJobke]

The purpose of an URL is that if you send it around will get the same view if you are allowed to do so - and sharing grants the permission to view/edit it

[PVince81]

Yes, I'm just trying to explore two opposite approaches to permalinks and weighing the good and the bad.
Either the link present in the file list or the token based approach.

[icewind1991]

I still think just adding the fileid of the folder to the path is enough and use the fileid to determine the folder to show.

Any user that opens the link and has access to the folder will be shown the correct location without the need to add any special permalink logic or ui

[icewind1991]

http://localhost/owncloud/index.php/apps/files/?dir=%2Ffoo%2Fbar&id=12312

[shellstrom]

I understand this is mainly focusing on linking between OC-accounts and not publicly generated share links, but I got referred here and my original issue closed.

I'm interested to see more granularity with file sharing, where both folders and files are taken into account.
As a comment, a non-human-readable link is (my guess) not a huge issue, as there are more high profile services, such as Google Docs that you mentioned, that do the same thing.
Unless the links are also very short, I'm not sure that a human-readable format provides that much advantage, as it still poses a problem with sharing during recitation.

Either alternative 1 or 4 in the original suggestions from PVince81 seem like good candidates. If a URL ends up like in Icewind1991's example, I'd be fine with that. But this depends on whether we all assume users are supposed to recite them, for instance over a phone call or whatnot, because then they will probably not work at all.

Apart from that, am I to expect that my original question of being able to copy/paste a direct link to a file within a shared folder, without having to generate an additional file sharing link, will be taken into account here?

[PVince81]

Thanks for all the comments.

I think I'll go with the following:

• introduce a new URL format containing the file id, for example "http://localhost/owncloud/index.php/f/123". This is like the "s" one for public shares but for files. "123" is the file id.
• opening this URL will redirect the user to the files app
  
  
  
  • if the link points at a folder, the folder contents will be shown
  
  
  • if the link points at a file, the file list will scroll and highlight the file in question
  
  
• the file's link will be available in the sidebar under an anchor-like icon, at the top-right (might need some tweaks to avoid confusion with the regular share link)
  
  
  
  • clicking that icon will provide a small dropdown/popup containing the short link as above (optional)
  
  
  • right-clicking it / copying link ("a" element) will also provide the same link
  
  

Additional thoughts:

• instead of the file id, we could base64 encode the fileid to make the link look more "fancy"
• maybe trigger the default action of a file after scrolling down to it. Discussed this with @nickvergessen and we decided against it because we cannot always guess the intention of the user/sharer (do they want to download/edit or view the file?). So best is to highlight it and let the user choose.

[MorrisJobke]

the file's link will be available in the sidebar under an anchor-like icon, at the top-right (might need some tweaks to avoid confusion with the regular share link)

This feels really unintuitive - having two different URLs for the same stuff. I want to copy simply my address bar content and send it to someone (that is also how the sharing on mobile platforms from inside the browser work - they simply send the URL of the tab). cc @jancborchardt

[LukasReschke]

Agreeing with @MorrisJobke. I think it may be useful to just have the folder ID in the URL as well? Or maybe even only the folder ID?

If somebody has an old link stored somewhere we would use the old logic, if somebody has a new link the new one :)

[PVince81]

Some reasons for why I like the separate URL (which is just a redirect):

• other websites like Youtube also have a specific link for sharing, you don't just copy the URL (which often contains referers)
• the new URL looks much nicer and shorter than the old one "http://localhost/owncloud/index.php/files/?dir=%2Fsubdir&fileid=22" vs "http://localhost/owncloud/index.php/f/22"

The other part I like about the "http://localhost/owncloud/f/$fileId" is also that it opens up new possibilities:

• when user has no access, display a page with a form to request access (could even obsolete public links)

I agree that it's not intuitive for people who are used to copy links.
Maybe we could have both ?

(note: I have the short link already implemented locally)

[PVince81]

Ah, and there's another problem with copying the URL from the browser: you cannot point directly at a file, only folders.

[guruz]

Why not do it like Amazon? all URLs are valid:

• http://www.amazon.de/Qt-4-Einf%C3%BChrung-die-Applikationsentwicklung/dp/3937514120/ref=sr_1_1?ie=UTF8&qid=1462348739&sr=8-1&
• http://www.amazon.de/Qt-4-Einf%C3%BChrung-die-Applikationsentwicklung/dp/3937514120/
• http://www.amazon.de/dp/3937514120/

(Bad example maybe with the umlaut, but at least you get an idea what the link is for.. especially when there are multiple in an e-mail or so)

[PVince81]

For now I intend to support both, the code addition is minimal.
Just did it locally, will push later today :smile:

[MorrisJobke]

For now I intend to support both, the code addition is minimal.

Okay. This means, that it is not a redirect, but simply shows the content. 👍

[PVince81]

PR here (still WIP): https://github.com/owncloud/core/pull/24434

I see additional tricky challenges with "fileid" in the regular URL:

• non "All files" views like "Shared with me" handling
• browser back button with history API: JS code needs to decide whether to use the fileid (might be obsolete ?) or "dir" argument
• auto-adding "fileid" in the URL from the server without causing redirect loop: might rely on JS code to add it instead

[PVince81]

Okay. This means, that it is not a redirect, but simply shows the content

At the moment it is a redirect to the correct folder (in case the folder changed name or so).
Making it display the correct folder is much more complex: the JS code would need an API to resolve fileid to folder, and then do its PROPFIND and possibly also replace the URL with the correct one (which has almost the same result as a redirect)

[PVince81]

Hmm looks like keeping this extra "fileid" argument up to date in the URL requires deeper changes in the JS code:
There's a delay between "load this folder" and before we can know the file id. So we cannot change the URL directly and have to wait until loading is done. (in the past the URL was changed first in case loading fails the user can just reload the page). This is especially relevant because the fileid isn't always known. Here are some cases:
- initial page load on folder with unknown fileid: fileid becomes known after PROPFIND
- clicking on a folder to nav into it: fileid is known at click time (data-id)
- clicking on a breadcrumb: fileid not known until after PROPFIND

Trying to find a way around this and limit regression risks.

[PVince81]

Okay, I found a way: https://github.com/owncloud/core/pull/24434#issuecomment-216808301

Please try it out!

[PVince81]

Possible extensions:

• [ ] have activity app use the shortened links in web UI and also emails => https://github.com/owncloud/activity/pull/521
• [x] make internal link share emails also send shortened links

[PVince81]

@MTRichards @cmonteroluque @jospoortvliet @carlaschroder this feature was merged for 9.1 !

[jospoortvliet]

Congrats, this is very cool!

[MTRichards]

Awesome!

[PVince81]

A nice addition would be to make it possible to request access to a file one doesn't have access to: https://github.com/owncloud/core/issues/25317

This could happen if someone shared the permalink by email to lots of people.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.