Ability to copy a user-friendly direct link to a file

We want to use Nextcloud as a Document management system, and one of the features that would be helpful is the ability to copy the the direct link of a file or folder to be used in other Documentation like a third party Wiki whose name will not be mentioned. These links would be group folders not personal documents.

Currently, it looks like you can find a webdav direct link by hovering over a file, but no way to copy it and if you use the Details > Copy direct link function it only creates a generic path of something like “/f/1” for a file or if you have sharing enabled “s/ajsdfajsdkj” instead of the actual path to the document. The URL in the browser looks like “files/?dir=/Photos&fileid=11” instead of containing the name of the file which is not really helpful either.

I don’t want users to create a public shares, and have sharing disabled, but just be able to copy a user-friendly URL for publication in another resource. Basically, create paths like any shared storage directory. Any ideas about how to do this or if this is on the roadmap?

1 Like

Those internal links with /f/ are exactly what you are looking for. Only those are permalinks, the links in the URL are subject to change and can differ for every user (since every user has its own view on the data and can rename or move files independently).

The use case here is for group folders, where an individual user is not the owner and to have consistent and permanent file paths and user-friendly names. The path of the file should not be dependent of the user who is accessing it. This is typical of document management systems and file browsers.

I think nextcloud is not the right tool. Use a upload mechanism to a wiki. it is a high risk to use a sharing plattform like nextcloud.

Internal links work for groupfolders.

What I’m saying is that internal links are not usable because they don’t have the name of the file in the path. Just a number. Also, the copy file path to clipboard is missing now that I’ve disabled sharing. So there is no easy way to refer to the URL of a file in documentation.

For example using Seafile the path to the file is: https://seafile.example.com/lib/6652161e-fe26-42a5-9280-5a41d6ebe84a/file/seafile-tutorial.doc

You may be correct the Nextcloud is not the correct tool for the job for a web-based document library, but I wanted to see if something as simple as this would be as good as a bloated ECM just to host documents.

I’m not sure if I understand you correctly. True: internal links don’t include filenames, but this is not a problem since they resolve to the current name and location of the file. Since filenames are subject to change it also does not make much sense to include filenames for purely aesthetic reasons. Users will only get confused if they see one name and find the other.

Nextcloud internal links are conceived as permalinks and as such they work fine.

What I’m getting at is that for this to be of use as a Document Library, when referring to a file in 3rd party apps such as a ticketing system or a wiki, whereby users can paste a link to any file, it is not usable to have a link without a filename. The expectation is that a user can click the link, login to Nextcloud and view or download the file. Its true that filenames change, but that’s not the point. A file name is unique and descriptive of what it is, whether its a document, image, ascii file, binary data or what have you. Having users having to click a link for a file with a random string or file id is not user friendly or intuitive. The Seafile example above is a good representation of how a filename gives added meaning to the URL and to me seems like a basic feature.

This is simply not true that it is “not usable to have a link without a filename”. Your use case is “paste a link to a ticket system or wiki so that users can click this link and view and download this file”. That IS possible with Nextcloud style links. If you want some context (that may or may not be provided by the filename) add it as the link name. That works in every wiki and many ticket systems.

What does not work as you want is purely a matter of taste. Some prefer to get the impression of a current filename (because it’s only a reference like the /f/ links, there’s really no difference) that might provide some context, others like me prefer links which are less likely to cause confusion in the case of name changes. Booth are personal preferences and there are reasons for each preference, but in the end of the day they are mostly a matter of taste. Each link style allows the use case that matters: referencing the correct file.

Look

https://apps.nextcloud.com/apps/sharingpath

I disagree, so please consider this a feature request to allow/enable “User friendly filenames” in the URL for a directory or file.

Also, how can I enable the copy file path feature when I have sharing completely disabled? Since I’ve done this, I can’t actually copy the “Internal” path of the file (i.e. there is no “Internal filename -> copy” option).

I’ve seen this app, and the problem with it is that it puts the logged in user’s name in the URL, again, not what you want with shared or group resources.

Filecloud is another cloud file sharing app that does this by default:

https://filecloud.example.com/ui/core/index.html?filter=Capitals.xlsx#expl-tabl.%2FSHARED%2Fteam_folders%2Ffilecloud-users/

Perhaps you can create a wiki user, share a folder and then use SharingPath for url without user in path. Also you can use Rewrite (.htaccess) for user friedly paths.

Excellent thread here! I love the idea that whatever shows up in the address bar is consistent across users and can be copied, pasted, and re-used with a predictable outcome. Right now my workaround is to always use internal links.

I think the URL path should use an id (e.g. the file’s id in the database), hash, or some other pseudonymous value. Examples:

# id
https://example.com/f/10452

# hash
https://example.com/f/7529e89542ac0e9feb95ddb474bcace4

If someone wants/needs the filename in the path, it could just be added (and perhaps ignored by the router, because all the router really needs is the id or hash to look up the file). Examples:

# friendly reusable URL with filename
https://example.com/f/10452/test-document.odt

# include filename as an anchor reference
https://example.com/f/10452#test-document.odt

# use query string
https://example.com/f/10452?n=test-document.odt

Including the filename (and which method) could be configurable.

Have there been other forum threads, issues, apps, discussions, design documents, or blog posts on this topic? All I could find was Friendly share links and bulk share files · Issue #28948 · nextcloud/server · GitHub and that “sharing path” app mentioned above. Neither of those really solve the problem, in my humble opinion.