Expose Nextcloud Flow operations as graph nodes

[rubenvdlinde]

Nextcloud ships its own workflow engine (workflowengine), and its operations should be usable as nodes on a hermiq graph instead of being a parallel, disconnected automation system.

What core exposes

OCP\WorkflowEngine\IManager is the registration point:

• registerEntity(IEntity) — what a rule reacts to (files, etc.)
• registerOperation(IOperation) — what a rule does
• registerCheck(ICheck) — the conditions
• getRuleMatcher(): IRuleMatcher

IOperation is a small contract — getDisplayName(), getDescription(), getIcon(), isAvailableForScope(int), validateOperation(name, checks, operation), onEvent(eventName, Event, IRuleMatcher). There are also IComplexOperation and ISpecificOperation variants, and IEntityCheck / IFileCheck on the check side.

Every app that registers an operation (tagging, file conversion, script execution, webhook notifications, …) therefore already advertises a display name, description, and icon — enough to populate a node palette without hard-coding a list.

Proposal

A flow-operation node type that:

1. Lists registered IOperation implementations as palette entries, using their own display name, description and icon.
2. Stores the chosen operation class plus its operation string in node config.
3. Invokes it during the graph walk with the run state as context.

Open questions

• IOperation::onEvent() is event-shaped, not call-shaped — it expects an Event and an IRuleMatcher. Driving one from a graph hop needs either a synthetic event + matcher, or a narrower adapter for the operations that can be invoked directly. This is the main design question and should be settled before any code.
• Core Flow operations are largely file-scoped (IFileCheck, file entities), while a hermiq graph walks an OpenRegister object. The mapping between the two is not automatic, and some operations may simply not be applicable.
• Scope: isAvailableForScope() distinguishes admin vs per-user rules; a graph node has to respect that rather than run everything as admin.

Raised from the graph builder work (#30).

[rubenvdlinde]

Closing: investigated, and the answer is that this cannot be built in the direction this issue asks for.

Core invokes an operation as (`apps/workflowengine/lib/AppInfo/Application.php:81`):

$entity->prepareRuleMatcher($ruleMatcher, $eventName, $event);
$operation->onEvent($eventName, $event, $ruleMatcher);

onEvent() returns void, receives an Event and an IRuleMatcher rather than data, inverts control (the operation asks which rules matched instead of the engine deciding what runs), and is bound to an entity's events. Wrapping one as a flow step would mean synthesising an Event and an IRuleMatcher it never asked for and discarding output that does not exist.

What was built instead — openregister#2074:

• IFlowNode mirrors IOperation's metadata methods verbatim and uses core's own SCOPE_* constants, adding the two IOperation lacks (validateConfig(), execute(items, config, context)).
• RegisterFlowNodesEvent copies core's RegisterOperationsEvent pattern, so contributing a flow node is the same listener an app would write for Nextcloud Flow.
• RunFlowOperation bridges the direction that DOES work: a Nextcloud Flow rule can start an OpenRegister flow, which then does the branching, joining and data-passing core cannot express.

So the two systems compose rather than one wrapping the other. Superseded by openregister#2074 and hermiq#35.