Use default app from app provider and early returns in fileActions

[kulmann]

Description

Switch to early returns when evaluating the default action for a file. Also use the app provider without app param so that the app provider can decide on its own which app to use.

Related Issue

• Fixes use default app for external apps when not specifying one #5962

Motivation and Context

Improve default action handling for files.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Open tasks:

• changelog item
• take app provider default apps into account when fix open by default app and expose default app cs3org/reva#2230 is in oCIS

[kulmann]

At the moment the POST to e.g. https://ocis.owncloud.test/app/open?file_id=MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OjFkZTU3Yzg1LWY0NDItNDhjZS1iZWE4LTQzMjZkZmNjOGNjYw== (= without app name) fails with a http 500 with message error searching for app provider - do you know details @wkloucek before I start to dig deeper?

[wkloucek]

At the moment the POST to e.g. https://ocis.owncloud.test/app/open?file_id=MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OjFkZTU3Yzg1LWY0NDItNDhjZS1iZWE4LTQzMjZkZmNjOGNjYw== (= without app name) fails with a http 500 with message error searching for app provider - do you know details @wkloucek before I start to dig deeper?

Thanks for raising this. I had a look at the code and there is a bug regarding the default app handling.

Besides that we also have a conceptual issue regarding default apps. The backend has cases where there is no default app, but how do clients like Web know? Currently they just get an error.

[kulmann]

Besides that we also have a conceptual issue regarding default apps. The backend has cases where there is no default app, but how do clients like Web know? Currently they just get an error.

Hmm... actually, now thinking about this, I don't want to call the open endpoint without app name anymore. We currently have three kinds of file handlers in this order:
1: apps which are directly added to the web config (e.g. mediaviewer)
2: apps from the app provider
3: system actions (e.g. download or open in new tab, which we do for PDF files)

If there is no default in (2) we should continue in the list and pick a system action as default. There is one in any case (download).

[kulmann]

This also means that we need the info about the default app from the app provider @wkloucek

[wkloucek]

This also means that we need the info about the default app from the app provider @wkloucek

cs3org/reva#2230 implements that and also fixes your error

[wkloucek]

@kulmann owncloud/ocis#2726 will bring cs3org/reva#2230 into oCIS to unblock this PR.

[ownclouders]

Results for oC10SharingPublicExpireAndRoles https://drone.owncloud.com/owncloud/web/20251/37/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

[kulmann]

Not blocked anymore thanks to @wkloucek ❤️

[pascalwengerter]

First test with the wopi example revealed an TypeError: action.handler is not a function when clicking on an .odt file. Investigating further

[pascalwengerter]

First test with the wopi example revealed an TypeError: action.handler is not a function when clicking on an .odt file. Investigating further

Also, opening external apps via context menu fails with Error fetching app information and statuscode 500

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

11.5% Coverage
0.0% Duplication

[kulmann]

First test with the wopi example revealed an TypeError: action.handler is not a function when clicking on an .odt file. Investigating further

Also, opening external apps via context menu fails with Error fetching app information and statuscode 500

Thanks, fixed it!

[pascalwengerter]

Works like a charm now 🧮