let extensions register more flexible file open actions

[wkloucek]

As an extension developer I want an extension to be able to:

• Register a name per file extension: "open in x", where x is the name, eg: "open in Collabora" and "open in CodiMD" [full-ci] Internalize app provider #5805
• Register a custom action name: "y in x", where y is the action name, eg: "open in x" or "edit in x" or "view in x" => needs
• Register a file action dependent on the permissions on a file, usecase: if I received a share with viewer permissions I see only actions "view in x". Whereas when I received a share with editor permissions I also see the "edit in x" action => needs concepting
• Load the list of available file extensions from a non static external endpoint (eg. the extensions api) => needs concepting

[wkloucek]

@kulmann The answer to all requests is currently not supported I suppose? ;-) Are there already plans to support it?

[kulmann]

• Number 1) and 2) are easy, we can allow that file handlers define their own name for the action entirely.
• For 3) we'd have to extend the first one even more and react differently depending on the permissions on the file. The resource (and with that the permissions) is available anyway, so we just have to come up with a reasonable mapping structure.
• Number 4) needs changes in the way we load extensions. As of now only static code is possible in extension loading, but for making your request possible we need access to the store of the runtime. Needs concepting first (we have ideas about this but need to write them down).

[wkloucek]

A discussion with CERN today raised the question to not use the file extension but the mimetype from the propfind of a file when looking for the open in app action. This allows oCIS / REVA adminstrators to add custom mimetypes without changing the Web frontend. Should be easily doable, what do you think about this @kulmann?

Example:
mimetype application/vnd.oasis.opendocument.text is able to be opened in Collabora and OnlyOffice (Web gets this information from an API endpoint). Then it will get the mimetype for a particular file from the propfind information and can look up, what the user can be offered to open that file with. Currently an Web extension does this by providing the file extensions (eg. .odt) that it can open.

CC @labkode @ishank011

[kulmann]

Currently we're not using mime types in web, but they are available with the DAV property {DAV:}getcontenttype, so at least retrieving it would be easy.

[labkode]

cc @elizavetaRa

[kulmann]

FTR: we have mime type now on resources:

web/packages/web-app-files/src/helpers/resources.js

Line 37 in 29341a1

mimeType: resource.fileInfo[DavProperty.MimeType],

[wkloucek]

can this be closed after #5805 is merged or are there open points?

[pascalwengerter]

can this be closed after #5805 is merged or are there open points?

I've refactored the acceptance criteria in this ticket and so far we've only checked the first box ;) the other ones needs further concepting and backend changes (not sure if oCIS/Reva/... though)

[wkloucek]

@kulmann does this ticket still have some right to exist? The last comment was already in 2021...

[kulmann]

We didn't go the way to customize the action name (e.g. differentiate between Open or Edit), but I feel that this doesn't bring too much value or might even confuse some users. However, viewers, editors and actions (with custom labels) can be developed as apps and installed easily into ocis, see https://owncloud.dev/services/web/#web-apps
We even build a first iteration of an App Store for web now, where available apps can be discovered easily (at the moment only download + manual installation). I think we can close here.