Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default mimetype actions #1400

Closed
juliusknorr opened this issue Mar 3, 2021 · 13 comments
Closed

Default mimetype actions #1400

juliusknorr opened this issue Mar 3, 2021 · 13 comments
Labels
enhancement New feature or request

Comments

@juliusknorr
Copy link
Member

Currently csv is opened by default on Collabora, however we also register text/csv as a default in the text app. As we do not have a way to customize which app should be used by the user or admin basically the app that registers as the last one at runtime of the javascript code will win and be the default, which is not really a good option imo.

@jancborchardt I know how you think about configuration options for default file actions but there are cases where certain organizations have the need to enforce either one or the other app for a given mimetype. I assume having something like operating systems do where the user can set a new default file opener is a bit to much here, but still think we should tackle this in some way.

I was wondering if we should think about introducing a matrix configuration so that at least the admin can define which mimetypes the app should open by default, similar to how the ONLYOFFICE app does it already:

image

@juliusknorr juliusknorr added the enhancement New feature or request label Mar 3, 2021
@jancborchardt
Copy link
Member

Couldn’t we have some sort of ranking for each of the filetypes? E.g. all of OnlyOffice, Collabora Online and Text might register for all sorts of mimetypes, but there’s a clear best choice for each, between either the full OnlyOffice/Collabora, or simple Text.

  • For all the doc*, xl*, pp*, od*, ot* file types it’s clearly OnlyOffice/Collabora
  • In the case of CSV you mention, it would be OnlyOffice/Collabora cause that gives you the proper table layout. That’s a much nicer and accessible view
  • For txt it’s basically always Text?
  • Essentially we could say that maybe in all cases except .md and .txt, OnlyOffice/Collabora can take precedence if they are registered on that file type, no?

Possible issues:

  • People might want to open CSV in plain text, but we could also skip over this for now as it is about the default, and it should always be possible to copy paste it from outside of Collabora/OnlyOffice
  • For PDF, the files_pdfviewer should always be used – but maybe people want to edit the file in ways which is not possible in that app?

Otherwise yeah, we could add a similar matrix like OnlyOffice has to Collabora. Or maybe better a central list like Gnome and other operating systems do, which makes it more obvious if a filetype is missing an app to open with:
image

@Thatoo
Copy link

Thatoo commented May 26, 2021

We miss this option too. Sometime .docx are opening in collabora whereas we'd rather have them opened in onlyoffice and keep collabora for .odt files only. Same with .ods/.xlsx and .odp/.pptx .
Onlyoffice, as the image shown by @juliushaertl , offers the option to open only .docx, .xlsx and .pptx .
I hope collabora could have an option, as an admin, to choose to open only .odt, .ods, .odp.

@skynick11
Copy link

Sometime .docx are opening in collabora whereas we'd rather have them opened in onlyoffice and keep collabora for .odt files only

Moreover, I have seen situations when .docx (.xlsx, etc.) in the browser are opened in Collabora, but in the mobile client they are opened in Onlyoffice - with the same NC21 server (where both Collabora and Onlyoffice applications are installed). ..

Therefore, I think it would be nice to be able to explicitly specify which file types should be opened by which particular application.

@cetcondor
Copy link

cetcondor commented Jul 8, 2021

Additional information: it seems that the existing rules are anyway not followed everywhere in Nextcloud. In the default Dashboard, under the section Empfohlene Dateien/Recommended Files when there's a CSV file, it's opened with the text editor instead of Collabora, which is used throughout the files app browser.

Tested today on two NC 21.0.3 with all latest app updates on different servers of different organisations.

@pierreozoux
Copy link
Member

I wanted to open a bug, but I see this issue so I'll plug myself here.

Tested today on a 20.0.12 freshly updated instance.

I open a docx with onlyoffice, share it in read/write, and open this link in an other browser.
It is then opened with lool.

I find it surprising for the user, as the collaboration will definitely not work, so this looks like a bug to me, not an enhancement.

@vasyugan
Copy link

vasyugan commented Oct 1, 2021

I find it surprising for the user, as the collaboration will definitely not work, so this looks like a bug to me, not an enhancement.

Currently, the situation is such that you have to uninstall either collabora or OnlyOffice to make sure that collaboration works. For me, this means that I have to uninstall Collabora, because many users have complained to me about its laggy interface, whereas OpenOffice is much more responsive, due to client side rendering. So, for me for now this means I have to uninstall Collabora because I can't find a reliable way of preventing it from usurping the OOXML file association.

@vasyugan
Copy link

vasyugan commented Oct 1, 2021

I would strongly argue for closing it in favour of #8105. We don't want yet another file hander configuration gui shipped by the richdocuments app. Instead, there should be one central, app independent place in the Nextcloud admin gui, plus a user level configuration gui.

@lolozere
Copy link

lolozere commented Oct 7, 2021

The suggestion of @ juliushaertl could resolve this issue too : nextcloud/server#361

@rosa2
Copy link

rosa2 commented Dec 5, 2021

hello
I am having the same problem: we have Collabora for people that uses LibreOffice and OnlyOffice for people that uses Microsoft Office. Since the last update to NextCloud 22.2.0 all documents are open with Collabora.

Please, make a generic place where apps can register the mime types that they can handle and users or administrators with shell can choose.

Does anybody know where an administrator can change this, please? Thanks for the tip and for making NextCloud :)

@pierreozoux
Copy link
Member

pierreozoux commented Dec 15, 2021

We ended up doing a dirty patch:
https://lab.libreho.st/libre.sh/docker/nextcloud/-/merge_requests/12/diffs#diff-content-dc5ea057fcb8783df59ef97caf2fa02971550316

Our use case is quiet simple, our users want to run LibreOfficeOnline and ONLYOFFICE side by side.
We decided that LibreOfficeOnline will only have access to its mime types, and that's it.

We'd like to offer an half baked solution, instead of the fully fledged real, configurable list of mimetype.

Would you accept if we PR to add a conf like a bool richdocument_minimum_mimetype, and if set to true, would only allow the minimum list, and if not set, or set to false, would keep the current behavior?

Would you like this idea? If yes, then we could make a PR for that, we'd prefer than maintaining our dirty patch ;)

(FYI, we then added a little js hack app to improve the new menu, and it looks quiet nice ;)

( cc @lolozere hope you'll be happy ;) )

@rosa2
Copy link

rosa2 commented Jan 18, 2022

Thanks pierreozoux
I saw how you solved it and I copied the solution removing from lib/Capabilities.php the OnlyOffice formats.
Very nice your solution multioffice. Are you thinking on uploading it in https://apps.nextcloud.com ?

Please, make an interface where admins can choose what it is best suit for their NextCloud installation 🙏

@pierreozoux

This comment has been minimized.

@juliusknorr
Copy link
Member Author

Since this requires a proper handling of mime type openers in the server, lets close it here and use nextcloud/viewer#2393 for tracking and follow up discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants