Improve smartness of handling public and internal links

[jospoortvliet]

We've discussed improving sharing for a long while - the multiple types of share links are confusing, you can enter a name but people don't see the input box and so on. I know fully fixing this is hard, but there's a relatively quick thing that will help a lot to make public links work better.

The most common mistake is mistaking a public link for an internal link. So what if Nextcloud would act like this:

• if you open a public link and are not logged in, you see what you see now
• if you are the user who created the public link, you see the public link as you see it now (to check how it looks for others - people test the links often)
• if you open the public link and you are logged in into that same Nextcloud and have access to the file, it acts as an internal link
• if you open the public link and you are logged in into that same Nextcloud and do not have access to the file, the file is shared with you and then loads it, acting as an internal link

We could alternatively add a big, obvious button that does some or all of these things, for cases where for example somebody else who is logged in wants to check out what the public link looks like. But I would vote for 'just working'.

this isn't a full fix of the link confusion issue, but it would be a 60% solution... In the future, we could eliminate internal links, and have only 'public' links that have a switch - "external" on or off, a bit like Talk rooms can be configured to let guests in or not.

It would make the checking of a public link by a colleague a bit harder (they would have to log out or use a anonymous window). I dunno if this really is an issue - with Google and Microsoft you can't do this either.

Discussed with @jancborchardt and @nimishavijay

[jancborchardt]

These improvements indeed sound like it could be the (or a) solution to some issues we have with public vs internal links. @karlitschek @AndyScherzinger what do you think? I’d say for discussion in next planning meeting for sure.

[AndyScherzinger]

Sounds reasonable, I would like to challenge the last point: "automatic share creation" and argue against it because it would have 2 consequences:

• automatic creation of shares (growing DB)
• these shared files or folders end up in the users root, files would be synced straight to disc by non-VFS desktop clients, folders would not (since they are covered by selective sync

one could add an action for adding it as a user share but that might then also confuse the sharing user when random users start to pop-up in the sharee list over time.

[jospoortvliet]

Ok, I see your objections, so let me first clarify further what the problem is.

People don't get the different sharing mechanisms. Our competitors have 1 link for which you can set permissions, either per person or publicly.

What i see is that if ppl want to share something, they almost always send a public link. What they MEANT to do is either sent an internal link or share directly with me. With this, we fix that problem: public links work as users expect. And to your specific concerns:

Sounds reasonable, I would like to challenge the last point: "automatic share creation" and argue against it because it would have 2 consequences:

* automatic creation of shares (growing DB)

So, if you use public links but you meant to share explicitly, nothing changes. You wanted to share, we simply make it a bit more intuitive to do it.

* these shared files or folders end up in the users root, files would be synced straight to disc by non-VFS desktop clients, folders would not (since they are covered by selective sync

Just like any other share, and just as it would if you had done it the 'technically correct way'. (just the fact that I have to say 'the technically correct way' shows what a problem we have here)

one could add an action for adding it as a user share but that might then also confuse the sharing user when random users start to pop-up in the sharee list over time.

Well, it's not random, you "shared the file". The whole point of this exercise is that for every new team member, they use the link share as their method of sharing because they don't get the difference between the three methods. We now simply make it work as expected for non-technical users.

But you could have a button top-right that, with no configuration or editing, adds this as a share. We have this but you have to enter various data - making this smarter would be helpful. It adds an extra step so I'm no fan of it, though.

[kousu]

People don't get the different sharing mechanisms. Our competitors have 1 link for which you can set permissions, either per person or publicly.

Thank you. My team is constantly confused by the multiple kinds of links.

99% of the time, people copy-paste from their URL bar, giving links like

• https://nextcloud.example.org/apps/files/?dir=/Org/Events/2023/08-16%20Vamp&openfile=72009

which works 99% of the time but glitches out occasionally and the dir= parameter is redundant.

Internal links like https://nextcloud.example.org/f/72009 are more reliable even though they ultimately just do a redirect to the previous link, but no one in my team can ever find how to get them or understand why they should bother.

External links like

• https://nextcloud.example.org/s/N8YmKS75HRmFH6Q

exist I assume because you can make different ones with different permissions for the same file

By contrast, in Google Drive, every file has a single link which is both the external and internal URL, and just what it opens in when you click on a document,

• https://docs.google.com/document/d/1DHn6tgF6z4QW3rcO5y7f2u183WQmmGG0cRPIDd7wzIg

but instead and the permissions on that link come in 4 modes:

(equivalent to not having any sharing links)

(equivalent to read-only sharing link)

(no equivalent in NextCloud -- and I don't think there needs to be)

(equivalent to checking "Allow Editing" on a sharing link)

Heading toward's Google system will massively simplify adoption of NextCloud in my org, so I am super super super glad to hear that this is on your roadmap!

[kolAflash]

There are currently multiple issues covering the topic of simplifying link handling:

• Internal File link button (or maybe quick action button) directly on Files and Folders #34061
• Improve sharing experience #48402
• Simplifying internal/external links flow #56219

 

Remotely related:

• Open the file or folder shared by the link in user's nextcloud if the user already has access #6462
• Open shared link from browser in app #16305