FlexMeasures / flexmeasures / 41031247495

88%

push

github

Point users at flex-config fields whose sensor was deleted (#2767)

* fix: prune sensor references that carry a default or bounds when their sensor is deleted

A flex-config entry is a sensor reference if it has the sensor key and no key beyond those of SensorReferenceSchema. The pruning code listed only the sensor key and the four source filters, so an entry with a default, lower, upper or snap was kept when its sensor was deleted. Take the keys from the schema, so a key added there is also recognised here.

Refs #2558

Signed-off-by: charanteja25 <charanteja.teja25@gmail.com>

* docs: add changelog entry for the pruning fix

Signed-off-by: charanteja25 <charanteja.teja25@gmail.com>

* docs: move the changelog entry to the Bugfixes list

Signed-off-by: charanteja25 <charanteja.teja25@gmail.com>

* Keep a deleted sensor's references, with their sensor unset

Deleting a sensor now unsets the sensor of each flex-model and flex-context reference to it,
keeping its default, bounds and source filters for when a new sensor is picked for the field.
A reference with nothing besides its sensor is still removed,
and so is an entry in a list of references, as it has nothing to read without a sensor.
The keys a reference may carry come from sensor_reference_keys, which landed on main in #2656.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Refuse a sensor reference without a sensor in the API

Only sensor deletion leaves a reference with "sensor": null behind, in a stored flex-config.
The API refuses one with a message saying so, which also blocks saving that flex-config until a sensor is picked.
The permission loader skips a null sensor, as there is no sensor to check, rather than failing the request with a 500.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Schedule on a deleted sensor's default, or let an ancestor's value apply

A stored ... (continued)

93 of 96 new or added lines in 5 files covered. (96.88%)

22909 of 26269 relevant lines covered (87.21%)

0.87 hits per line