Feature Request: web protocol handler

[roleohibachi]

The Onedrive/Sharepoint web interfaces provide a "sync" button, which makes a request using protocol "odopen". OneDriveGUI could register a protocol handler for that link with xdg-open, so that it automatically created a configuration.

For example:

create ~/.local/share/applications/onedrivesync.desktop with contents below:

[Desktop Entry]
Name=Onedrive Sync Handler
Exec=</path/to/OneDriveGUI> %u
MimeType=x-scheme-handler/odopen
Type=Application
Categories=Application;

execute xdg-mime default onedrivesync.desktop x-scheme-handler/odopen to register it as a protocol handler.

OneDriveGUI would need to add functionality for parsing these links into its internal data structure, but everything needed appears to be provided in the parameters. For example, the name of the profile is the param "webTitle". Here is a sample URL (with bogus values).

odopen://sync?userId=12345678%2Ddead%2Dbeef%2Dcafe%2D112233445566&userEmail=me%40example%2Ecom&isSiteAdmin=1&siteId=%7B12345678%2Ddead%2Dbeef%2Dcafe%2D112233445566%7D&webId=%7B12345678%2Ddead%2Dbeef%2Dcafe%2D112233445566%7D&webTitle=My%20Library%20Name&webTemplate=69&webLogoUrl=%5Flayouts%2F15%2Fimages%2Fsiteicon%2Epng&webUrl=https%3A%2F%2Fmysite%2Esharepoint%2Ecom%2Fsites%2FMySite&onPrem=0&libraryType=3&listId=78c7e041%2D2f19%2D492d%2Db949%2D824477387ae7&listTitle=Documents&folderId=79445b6c%2De456%2D4b51%2Daac1%2D88378f043d5b&folderName=My%20Folder&folderUrl=https%3A%2F%2Fmysite%2Esharepoint%2Ecom%2Fsites%2FPath%2Dto%2Dsync&scope=OPENFOLDER

[roleohibachi]

Documentation for parsing the URL as an argument in a PyQT GUI application: https://doc.qt.io/qtforpython-5/PySide2/QtWidgets/QApplication.html#detailed-description

Another way, using argparse such that it doesn't consume PyQT arguments: https://stackoverflow.com/a/21166631/9755610

[bpozdena]

@roleohibachi can you please provide more details on the use case?

My understanding is that the SharePoint sync button should force the windows onedrive client to synchronize the files, so that they can be used when you're offline. By default files are only downloaded on demand when user tries to open them in File Explorer.

However, the Linux onedrive client does not even support such on-demand access. It simply always syncronizes everything based on your client config.

[roleohibachi]

I think that the use case is to accomplish most of the "new profile" steps using the information in the link.

The Windows client uses a zero-configuration approach by using a lot of default values. When the user clicks the web sync button, the default is to create a Virtual Filesystem using the default sync path of the user's OneDrive folder. For full synchronization, a user then has to configure the sync endpoint further - either in the GUI, or by a file explorer extension in the right click menu, "Always keep on this device".

By contrast, the Linux client requires manual configuration for every new profile (by design). So it shouldn't just instantly start synchronizing the new profile. And as you say, the Linux client doesn't implement Virtual Filesystems, so that's not expected behavior in this environment.

The way I imagined this when I wrote the feature request, the link handler could populate the initial data needed for a new sync endpoint. Clicking "Sync" would pop up the "new profile" GUI, and fill out all the details (name, drive_id, refresh_token). The user would provide just a local path, and any specific configuration details they prefer.

As a side note, there is a FUSE virtual filesystem that supports OneDrive implemented by rclone mount. If you don't think a pre-populated dialog would be very useful, then maybe that would be a better odopen protocol handler. In the Microsoft client, virtual filesystems and full synchronization modes are easily convertible (as above - by GUI or explorer extension). Converting between a FUSE mountpoint and a fully synchronized directory in the Linux client would not be as neat, since two different clients are in use, and no sane person would want to maintain such complicated deconfliction between them. Maybe worth discussing in the feature request for simple rclone configuration import, but probably outside of the scope of either project.