Support plugin-defined automations

[BelhsanHmida]

Description

Plugin authors can now register automation types backed by a DataGenerator. Registered types use their own strict configuration and parameter schemas, queue, display name, and result terminology while using the existing automation API, CLI, dispatcher, job monitoring, and UI.

• Add an AutomationHandler registry with built-in adapters for forecasting and scheduling.
• Let plugins declare handlers through __automation_types__.
• Validate plugin configuration and parameters with the generator's Marshmallow schemas.
• Store generator name, version, configuration, and execution user for reproducible unattended runs.
• Enforce sensor access, output scope, declared outputs, generator version, and creator permissions when jobs execute.
• Queue plugin automations on their registered queue and expose them through API and CLI inspection.
• Show registered and unavailable plugin automation types in the automation UI.
• Document the plugin contract and add a deterministic example plugin for integration tests.
• Added changelog item in documentation/changelog.rst

Look & Feel

The automation page builds its type tabs from the registered handlers. Existing records whose plugin is not installed remain visible and are labelled plugin unavailable.

Custom plugin automations can be created through the API or CLI. For example:

flexmeasures add automation --asset 1 --type mock-ingestion \
  --config '{sensor: 2}' --parameters '{value: 33.5}' \
  --start '2026-09-16T00:00:00+00:00' --crontab '* * * * *'

flexmeasures show automations --asset 1 --as-json

Invalid or unknown configuration and parameter fields return validation errors associated with the relevant payload section.

How to test

• Create, inspect, trigger, and monitor a plugin automation through authenticated API requests.
• Create and inspect a plugin automation through the CLI using YAML configuration and parameters.
• Execute the queued job and verify the expected belief and data-source provenance.
• Reject unknown fields and cross-organisation sensor access.
• Reject queued execution after the authorizing user is disabled.
• Keep stored automations visible when their plugin is unavailable and reject triggering with installation guidance.
• Avoid duplicate dispatcher jobs for the same recurrence.
• Upgrade, downgrade, and upgrade the database migration.
• Render enabled and unavailable plugin automation pages without JavaScript errors.

Relevant test modules:

• flexmeasures/data/tests/test_plugin_automations_fresh_db.py
• flexmeasures/api/v3_0/tests/test_plugin_automations_api_fresh_db.py
• flexmeasures/cli/tests/test_plugin_automations.py
• flexmeasures/ui/tests/js/test_automation_actions.py

Further Improvements

• Build custom plugin automation creation forms dynamically from plugin schemas. This PR exposes custom creation through the API and CLI and limits the existing UI creation form to built-in types.

Related Items

Closes #2530.

---

Sign-off

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on code under GPL or another license that is incompatible with FlexMeasures.

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #34602949 | 📁 Comparing 0f99cc3 against latest (e3cf3ba)

  🔍 Preview build  

12 files changed · + 1 added · ± 11 modified

+ Added

• _autosummary/flexmeasures.data.automations.html

± Modified

• changelog.html
• genindex.html
• py-modindex.html
• _autosummary/flexmeasures.api.v3_0.assets.html
• _autosummary/flexmeasures.data.html
• _autosummary/flexmeasures.data.models.automations.html
• _autosummary/flexmeasures.data.models.html
• _autosummary/flexmeasures.data.services.automations.html
• api/v3_0.html
• features/automations.html
• and 1 more...