feat(FileAction): add file action support

[skjnldsv]

RFC: nextcloud/server#21835

interface FileActionData {
	id: string
	displayName: (files: Node[], view) => string
	iconSvgInline: (files: Node[], view) => string
	enabled?: (files: Node[], view) => boolean
	exec: (file: Node, view) => Promise<boolean>,
	execBatch?: (files: Node[], view) => Promise<boolean[]>
	order?: number,
	default?: boolean,
	inline?: (file: Node, view) => boolean,
	renderInline?: (file: Node, view) => HTMLElement,
}

[skjnldsv]

The default is the last thing I'm not sure of.
This is very different than what we do right now

Same for the registering, the legacy way is registering per mimetype
And registering as default is done as a secondary step

[skjnldsv]

After a bit of thoughts, and seeing that there are very few number of actions I don't think we would really gain by splitting per mime.
Let's just have one big list and let apps register their own actions conditions

Instead of

['image/jpeg', 'image/png', ...].forEach(mime => registerAction(action, mime))

It's easier and cleaner to just do once per app

registerAction(action)

When opening the actions menu, then it would make it easy to just do something like this (which we would have to do anyway even if we group per mimes)

<template>
	<Actions>
		<ActionButton v-for="action in enabled" ... />
	</Actions>
</template>
<script>
const actions = getActions()
const enabled = actions.filter(action => action.enabled(this.file, this.currentView))
</script>

I'm guessing most enabled checks will just do string/int comparison with the file.mime and the file.permissions.
Performances should not be an issue then

@juliushaertl any opinion?

[juliusknorr]

I think the enabled option makes sense. This way developers have one place for implementing their logic.

I'd be a bit hesitant about the boolean value for default. From the API usage perspective the difference to the current way should not matter, but both the old and new approach lack way to properly handle multiple actions registering as a default. The current approach is that the last registered wins. I'm not sure about a better approach here tough. We could also allow passing a callback here so that apps can make this dependent on file attributes (like the disabled download), but this could also be skipped I guess if we consider viewer as the preferred default opener. One use case for this would be nextcloud/viewer#1440 where we would want to open pdf files with files_pdfviewer by default, except when secure view of collabora should be used.

[skjnldsv]

I'd be a bit hesitant about the boolean value for default. From the API usage perspective the difference to the current way should not matter, but both the old and new approach lack way to properly handle multiple actions registering as a default. The current approach is that the last registered wins. I'm not sure about a better approach here tough. We could also allow passing a callback here so that apps can make this dependent on file attributes (like the disabled download), but this could also be skipped I guess if we consider viewer as the preferred default opener. One use case for this would be nextcloud/viewer#1440 where we would want to open pdf files with files_pdfviewer by default, except when secure view of collabora should be used.

With this enabled boolean, this would be doable then.
If the enabled is false, we go to the next default.
The order would matter there, we could have

registerAction({
	id: 'pdfviewer',
	enabled(node) {
		// node mime and secureview check
		return boolean
	},
	default: true,
	order: 10,
	...
})

registerAction({
	id: 'collabora',
	enabled(node) {
		// node mime check
		return boolean
	},
	default: true,
	order: 11,
	...
})

That way we would return the first enabled default action ?

[juliusknorr]

The only downside this has is that app developers need to align how to handle those scenarios. But as long as we don’t decide to offer preferences for default apps or actions this seems like the most reasonable option.

[skjnldsv]

But as long as we don’t decide to offer preferences for default apps or actions this seems like the most reasonable option.

Could you elaborate? :)

[juliusknorr]

Mostly about nextcloud/viewer#2393 (and related feature requests we frequently get for Collabora) where there could be more than one app that provides a file handler and either the admin or users would prefer having the choice about the default.

I don't think we need to have this as part of the initial API design, just something to keep in mind that this might be a topic in the future. Especially with a growing app ecosystem.

[juliusknorr]

Thinking about this again, I'd also say that the boolean value is good and the preference could still be handled with that. Maybe we just need to clarify that "default" only means that the registering app would like to be the default, but there are no guarantees about that due to the first-wins approach at the moment.

[skjnldsv]

I don't think we need to have this as part of the initial API design, just something to keep in mind that this might be a topic in the future. Especially with a growing app ecosystem.

Could be easily done afterwards if we have multiple defaults.
The first one would be used as default click, while the others are put in the menu 👍

[skjnldsv]

Great!

You should know this API is already being used on the trashbin branch and is working pretty great (with a few adjustments that i'll push later) 👍 🚀

[skjnldsv]

Done everyone!

[artonge]

Looks good 👍