feat: onlyoffice Integration (cont...)

[arcastro]

Description

This is a continuation of the pull request here:

• Onlyoffice #1420

In this pull request, I have:

• Rebased @drosoCode's contributions against the latest master branch
• Addressed the pending comments on that pull request:
  • OnlyOffice's secret key is no longer exposed to the client. Instead all signing occurs server-side.
  • The document key is now generated as a sha256 hash.
  • "Magic" numbers are assigned meaningful names.
• Additionally, I made a few other improvements:
  • Fixed a bug in the generation and caching of the document key in order to properly support co-editing.
  • Set OnlyOffice dark/light theme according to filebrowser settings.
  • Added mobile support for the OnlyOffice editor.

Links

• Onlyoffice #1420
• Using OnlyOffice #1255
• Using OnlyOffice #1272
• Ability to view OFFICE documents. #2923

[arcastro]

Rebased again to resolve new merge conflicts against latest master.

@Equim-chan , @hacdias , @o1egl , any chance you could take a look?

Appreciate the help ❤️

---

P.S. I'm hoping to send an additional pull-request after this one to allow creation of office documents from the new-file menu, but this pull-requests is already a bit large and I don't want to delay it any further, so choosing to wait until this one is merged.

Here's a gif (need to press play), or full screen recording:

[arcastro]

Thank you @o1egl for proceeding the workflow.
Saw the lint errors here.

Updated the pull-request and fixed all the lint/build errors.

[ogmkp]

Hi, it would be great if we could have this feature, filebrowser is so great, it would be even better!

[ElHado]

Hi, yes, I would love that feature, too. It looks like a lot of work has already gone into it, it would be a shame if it wasn't taken over.

[ogmkp]

Is there any good news?

[arcastro]

Is there any good news?

Looks like the workflow proceeded again ~2 days ago.

There were more linter errors here unfortunately 😅

I've rebased and addressed the lint errors and updated the branch/pull request again.

Note: When I run make lint-backend locally, I still see two remaining errors, but they seem to be present even on the master branch, so decided to leave these two unaddressed for now. If it's addressed in master branch, can rebase again.

---

If anyone is itching to try this in the meantime, I published a docker image at:

• ghcr.io/arcastro/filebrowser-onlyoffice

Though I recommend waiting until it's merged.

[ogmkp]

Tested with a build on my side, it works. I'll use it and report any problems I find.
Is it possible to add or customize all the extensions Onlyoffice can handle? I have .ods for example.
When I press "New file", I don't get the little box with the document types like on the gif.

[arcastro]

Is it possible to add or customize all the extensions Onlyoffice can handle? I have .ods for example.

It's determined by mimetype here.
I've updated this pull-request to include the mimetype for *.ods and other opendocument types by prefix.
Also updated the docker image: ghcr.io/arcastro/filebrowser-onlyoffice

When I press "New file", I don't get the little box with the document types like on the gif.

Did you configure the only-office integration in

• Settings -> Global Settings -> Only Office Integration?

If those settings aren't configured, then the new-file dialogue will remain as-is.

Note: I want to clarify that the changes to the new-file dialogue are not included as part of this pull request. This pull request is already large and I didn't want to delay it further with additional changes. I mostly wanted to keep it scoped to what had already been done in #1420 and unblocking those changes.

However once this pull request is merged, I do plan to open an additional pull request for changes to the new-file dialogue so that those can be reviewed separately. The code for the new-file dialogue is in the new-file branch here, but again, is not part of this pull request. I did include it in the docker image though, so you should be able to try it and see it hopefully.

[M3gaFr3ak]

I think I found a bug: Sometimes, when changing the file in the filesystem (in my case, changing the onlyoffice file in onlyoffice offline and editing via sftp or webdav), the online view stays stuck with some outdated phantom file; I guess some filename-handle is stuck and it's editing some older version still stuck in the onlyoffice backend?
Downloading the file yields the correct (just changed) contents, so the error seems to be on the onlyoffice side (OO or your implementation).

To replicate: Create file, change in file system and view in filebrowser multiple times, after 2 times (for me), it gets stuck with old contents.

[arcastro]

Sometimes, when changing the file in the filesystem (in my case, changing the onlyoffice file in onlyoffice offline and editing via sftp or webdav), the online view stays stuck with some outdated phantom file; I guess some filename-handle is stuck and it's editing some older version still stuck in the onlyoffice backend?

once a document is opened, the OnlyOffice Document Server keeps a cached version and serves the document from cache until all editing sessions for that document are closed. If the document changes in the file-system from some other process, then the existing onlyoffice editing sessions will not pick up of those changes since they're all being served from the document-server cache (until all editing sessions for that document are closed).

Some details are documented here (can search for "cache" keyword)

• https://api.onlyoffice.com/editors/coedit

To replicate: Create file, change in file system and view in filebrowser multiple times, after 2 times (for me), it gets stuck with old contents.

@M3gaFr3ak these steps make me think I might have misunderstood the issue. Could you maybe post a video?

[M3gaFr3ak]

@M3gaFr3ak these steps make me think I might have misunderstood the issue. Could you maybe post a video?

I tested it again and recorded it. I'm using a webdav share to write to the directory here and I'm using ctrl-s to save and F5 to refresh.
So, I created a new file (as seen in filebrowser). I write "1", save, refresh filebrowser, open in filebrowser, "1" is visible. Close editor in filebrowser, change to 2 in word, save, refresh filebrowser, it shows "changed". Open in filebrowser, still "1". Download from filebrowser and open in word: "2".

test.webm

[arcastro]

@M3gaFr3ak , Thanks for the video, that clarifies it.

There's a period of around seven seconds between:

• closing the first editor at the 0:17 second mark in the video
• and reopening it at the 0:24 second mark

Does the problem persist if you wait a little longer between those two events?
If after closing the editor on filebrowser, you try waiting ten or so seconds before editing externally, does it resolve?

This may be due to the save delay described here.

Essentially, when all editors close, the only office document server waits some time before triggering the callback handler to inform filebrowser to perform a final save for the file and clear the cached document key. If the file is re-opened before filebrowser receives this callback from onlyoffice, then the same document key is re-used and the document is reloaded from the same cache.

From the documentation:

The delay is necessary to allow to return to the file editing session without the file saving, e.g. when reloading the browser page with the file opened for editing

You could maybe try lowering that delay to something shorter in the onlyoffice document server settings (same documentation), but the race condition will probably still be present. I'm not sure if anything can be done to address it while still allowing co-editing. Curious to know if the OwnCloud/OnlyOffice integration also has this problem, but I don't have an owncloud instance to test it.

[M3gaFr3ak]

Does the problem persist if you wait a little longer between those two events? If after closing the editor on filebrowser, you try waiting ten or so seconds before editing externally, does it resolve?

I just opened the filebrowser OO with the modified files (modified 2hrs ago) and it still doesn't show the changes. I then restarted the OO docker container to maybe flush anything remaining and then opened the file in filebrowser OO again. Still no changes! Then I renamed the file and opened it, showing the changes finally. I'll try around with waiting for long times between showing online and editing offline.

[M3gaFr3ak]

Addendum: Renaming the file to an older name, opening it in filebrowser OO yields the "old content" (the stuff it showed when it had the old name the last time).

Addendum number 2: Restarting the only office container also doesnt solve the problem. Opening the file in filebrowser OO after an onlyoffice container restart still yields the old file contents. Only after deleting the container and re-creating it (meaning it purges the data), opening the file yields the new contents. (alternative is changing data from inside filebrowser OO, obviously).

[arcastro]

@M3gaFr3ak , Thank you for the additional details.

I suspect I'll need to update the callback handler here to also handle status code 4 and clear the cached document key. I'm not able to try it today, but I'll take a look tomorrow.

[arcastro]

I suspect I'll need to update the callback handler here to also handle status code 4 and clear the cached document key

@M3gaFr3ak, I think this might have been it. (fixed here)

I updated the pull request and docker image. Could you test again with the new image and let me know if you still see the same caching issues?

Still ghcr.io/arcastro/filebrowser-onlyoffice

[enginlove]

Rebased again to resolve new merge conflicts against latest master.

@Equim-chan , @hacdias , @o1egl , any chance you could take a look?

Appreciate the help ❤️

P.S. I'm hoping to send an additional pull-request after this one to allow creation of office documents from the new-file menu, but this pull-requests is already a bit large and I don't want to delay it any further, so choosing to wait until this one is merged.

Here's a gif (need to press play), or full screen recording:

new file and new folder with Chinese character gets 404 not found error

[M3gaFr3ak]

I think this might have been it. (fixed here)

I can confirm that fixed it, thank you :)

[grouch0jr]

@arcastro, thanks for adding this feature. I pulled your docker image and find it very useful.

I've run into a problem when creating new files in a directory containing spaces in the path. If I try to create a new file (only office or 'empty') in a directory that contains any spaces, I get a '404 not found', and the file is created in a new directory where all the spaces are replaced with % signs.

[RomanSonnik]

Any updates?

[o1egl]

Please note that the filebrowser has been updated to use Vue 3, which has caused some merge conflicts. Kindly resolve these conflicts as required.

[arcastro]

Ty @o1egl , I'll send a new revision soon.

[arcastro]

@o1egl , I've rebased and updated the pull request.