[feature/url-shortcuts] Open and create .url shortcut files
Description
Adds the ability to open shortcuts stored in .url files as well as to create them.
The MDM option action.open-shortcut-mode provides control over what kind of shortcuts (URLs, items) should be allowed to be opened. Defaults to all.
Screenshots (if appropriate):
Action in empty folder and on + button |
Creating a shortcut | Shortcut in file list |
|---|---|---|
| Create file shortcut | Create URL shortcut | Opening a URL shortcut |
|---|---|---|
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
@hosy Thanks for the feedback. The improved implementation now allows opening shortcut files directly from the file list and brings up an alert asking the user whether the URL should be opened:
I still kept the viewer for shortcut files around for those cases where a user views files in the same folder and eventually reaches a shortcut file when swiping through.
I did a first look into the feature (before QA - CR), with a couple of comments on my side
-
Shortcuts to url show the following question:
Should it be opened in the default browser?Well, this question is not really a question since there is no other choice than opening in the default browser (cancel is not a real option to open). So, i'd change that for an statement likeIt will be opened in the default browserto clarify what's going to happen. More complex options like letting user select another browser to open are not worthy IMO (future improvement¿?). But, questions to users should have at least two real choices. Also, removing the question is not a bad option... the easier the better. Just as a suggestion. -
As improvement: if the target URL does not exist (for example, a link to a file or folder that has been removed from account), the message is
Operation couldn't be completed. It would be cool a more accurate message likefile does not exist. Private links show:item is not known to the serveras another example
Will do deeper testing after CR but it really looks good at this point.
@jesmrec Thanks for the feedback. I've trimmed down the alert asking for opening the link and removed the browser reference entirely. Also, the error message when the target of a shortcut can't be found is now on point and informative (or at least I hope so 😉).
I also added a action.open-shortcut-mode MDM option that allows admins to control which type of shortcut content they want to allow (all, URLs only, items only, none).
QA checks:
- [x] Option in
+ - [x] URL or name empty
- [x] URL of web
- [x] URL of file in oC same account and space
- [x] URL of file in oC same account and different space
- [X] URL of file in oC different account [NA]
- [x] Incorrect URL (points nowhere)
- [x] URL pointing to removed file
(1)
In oC10 server:
Create shortcut- Add as URL a web like
https://owncloud.com/ - Create shortcut
- Click on the shortcut on list of file
Current: not opened, also the thumbnail in file list is not correct
NOTE: same behaviour when files are shortcuted.
iPhoneXR iOS17
f1b6e0e6
(2)
As a question: shortcuts over files are only allowed over items in the same account, right? not posible to create a shortcut that points to a file in other account attached to the device (moving to there).
@jesmrec Regarding (1):
The current implementation supporting .url files depends on the MIME type text/uri-list, which OC10 appears not to use for .url-files. Instead it returns application/octet-stream:
<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
<d:response>
<d:href>/remote.php/dav/files/admin/Files.url</d:href>
<d:propstat>
<d:prop>
<d:resourcetype/>
<d:getlastmodified>Fri, 03 May 2024 15:48:47 GMT</d:getlastmodified>
<d:getcontentlength>51</d:getcontentlength>
<d:getcontenttype>application/octet-stream</d:getcontenttype>
<d:getetag>"ba2042d735ee8e0bd77c95655aedb8e6"</d:getetag>
<oc:id>00009374oc60lgadtioc</oc:id>
<oc:size>51</oc:size>
<oc:permissions>RDNVW</oc:permissions>
<oc:favorite>0</oc:favorite>
<oc:share-types/>
<oc:owner-id>admin</oc:owner-id>
<oc:owner-display-name>admin</oc:owner-display-name>
<oc:checksums>
<oc:checksum>SHA1:9405c1b721fdd574d50d639dc14983f8906f45fd MD5:cdc846c7f7b2980ca79b452fb3015f9b ADLER32:f32e1229</oc:checksum>
</oc:checksums>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
</d:multistatus>
Once OC10 returns text/uri-list for .url-files, handling in the iOS app should work as expected.
Regarding (2): There's currently no support for cross-server shortcuts.
That's approved on my side.
Before merging, the branch should point to a different base branch like milestone/12.3