CRUD for automations in the API and UI

[Flix6x]

Description

Milestone 3 of #2288 (stacked on #2293, which is stacked on #2290): automations can now be created, edited and deleted through the API and the UI.

• API (all documented in OpenAPI, all requiring account admin or consultant rights — the same principals that may delete the asset, matching the Automation ACL):
  • POST /assets/<id>/automations — create an automation; parameters are validated by the schema matching the automation type (forecast parameters or a schedule trigger message). Response includes any validation warnings.
  • PATCH /assets/<id>/automations/<automation_id> — update name, cron string and/or activation status.
  • DELETE /assets/<id>/automations/<automation_id> — delete (already-queued jobs are unaffected).
  • Nonexistent/mismatched automation ids yield the documented 404 without leaking id existence across accounts.
• UI: the automations page gets a New automation modal (name, type, cron string, JSON parameters, active) and per-row (De)activate / Delete actions — rendered only for users with management rights.
• Refactor: create/update/delete logic including audit-log records moved into flexmeasures/data/services/automations.py, shared by the CLI commands and the new endpoints (audit messages now say "via CLI" or "via API" consistently).

How to test

As an account admin, open /assets/<id>/automations and use the New automation button, or:

curl -X POST .../api/v3_0/assets/<id>/automations -H "Authorization: <token>" -H "Content-Type: application/json" \
  -d '{"name": "Nightly schedules", "cronstr": "0 0 * * *", "type": "schedules", "parameters": {"duration": "PT12H"}}'

Tests: pytest flexmeasures/api/v3_0/tests/test_automations_api.py flexmeasures/cli/tests/test_automations.py (permission matrix: plain member 403, account admin OK, other account 403).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Rbix8k1JfeUWNXEmHEZVpX

related issues

closes #2372

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #33933929 | 📁 Comparing 05e00ac against latest (60cfda8)

  🔍 Preview build  

21 files changed · + 3 added · ± 18 modified

+ Added

• _autosummary/flexmeasures.data.models.automations.html
• _autosummary/flexmeasures.data.schemas.automations.html
• _autosummary/flexmeasures.data.services.automations.html

± Modified

• changelog.html
• genindex.html
• http-routingtable.html
• py-modindex.html
• _autosummary/flexmeasures.api.v3_0.assets.html
• _autosummary/flexmeasures.cli.utils.html
• _autosummary/flexmeasures.data.models.data_sources.html
• _autosummary/flexmeasures.data.models.html
• _autosummary/flexmeasures.data.schemas.html
• _autosummary/flexmeasures.data.services.html
• and 8 more...

[Flix6x]

@BelhsanHmida — Felix reviewed the automations work and asked for one thing to land here: an automation administered through the UI (and hence the API) may only involve sensors that its creator can access. Could you review these commits, and then take the PR over again?

What we contributed:

• create_automation now works out which sensors an automation would read from and write to, and requires read access to the former and create-children on the latter — the same permission the API requires for recording data on a sensor. A refused request gets a 403 naming the sensor and the action, through the existing api_message mechanism.
• This is behind a check_permissions flag that the API passes; the CLI creates automations without a user and stays unrestricted.
• Forecasts: the sensor to forecast plus its regressors are inputs, the sensor to save to (the same sensor by default) is the output.
• Schedules: schedulers hand their results to make_schedule as (sensor, data) pairs, so the outputs are not only the flex-model's device sensors — a schedule is also recorded on a device's state-of-charge, consumption and production sensors, and on the flex-context's aggregate-consumption and aggregate-production. We derive the outputs from all of those fields at any depth, since the flex-model and flex-context are deserialized by the scheduler itself and their sensor references are still raw at this point. Everything else the parameters refer to (price sensors, inflexible-device sensors — these can live on the flex-context too) counts as an input.
• Tests cover both a forecast on another account's sensor and a schedule aggregated onto another account's sensor; both were verified to fail without the check. Docs, changelog and API change log updated.

Two things to be aware of:

1. This branch is ~108 commits behind its base, so it does not yet have the input_sensors / output_sensors properties we added to DataGenerator in Automations - first roundtrip for forecasts #2290. We kept the sensor resolution inside create_automation rather than duplicating those properties, so syncing the stack should be a small edit rather than a conflict — but the two should be collapsed into one implementation then.
2. Deriving output sensors statically is an approximation of what a scheduler actually returns at run time. If a scheduler starts writing somewhere else, this check will not know about it, so it is worth revisiting whenever a new output field is added.

🤖 Generated with Claude Code