Open nhoening opened 4 months ago
More info on syntax of sensors_to_show
: https://flexmeasures.readthedocs.io/en/latest/views/asset-data.html#the-asset-page-as-data-dashboard
We want to send the more elaborate one.
sensors_to_show = db.Column(MutableDict.as_mutable(db.JSON), nullable=False, default={})
Inspiration for copying data: https://github.com/FlexMeasures/flexmeasures/blob/main/flexmeasures/data/migrations/versions/b797328ac32d_add_user_fs_uniquifier_for_faster_auth_.py#L38
I suggest we leave the sensors_to_show
value in attributes, so as to make our lives easier and also experience less trouble in upgrades and migrations. We can delete it at later date,
Editing how the dashboard should look like (via
sensors_to_show
) is not fun: It requires looking up sensor IDs and editing JSON in a horizontal text box.The second problem is editing JSON. I have ideas for both here.
Picking sensors
In #1059, we already did some UI work on selecting sensors within the asset form, so this can be built on that experience. However, we decided to move away from doing this within the main edit form, as it becomes too heavy when sensor selection is involved.
This is not a pleasure to do, but also we also complicated the structure in #1119. We need to load, show, edit and send to the API a list of lists (each sublist is a plot that contains one or more sensors). Each entry should be saved as a dictionary (modern form), but also accept the earlier, simpler forms when loading.
I looked at support for editing JSON based on a schema, but I believe editing of this complex information (certainly with loading sensors) requires us to move to writing our own form.
From the user's perspective, the idea is that there is a modal dialogue on the asset page (when clicking "Edit Graphs"):
Main functionality:
sensors_to_show
information will be available and rendered on page load.sensors_to_show
JSON representation is constructed and send to the asset PATCH endpoint.Here are TODOs, each can be a PR (please link them here when they are being worked on):
all_accessible
parameter and search filter (for the name and account name) like the asset API has. Also add aunit
parameter.sensors_to_show
from attributes to its own JSON field on theGenericAsset
data model. The data migration needs support for existing attributes to be moved over - that has to be Python code, check some earlier migrations that had custom code. Likewise in the reverse direction. Sensors_to_show should also get its own (temporary) form field in the asset editing, so this PR can stand on its own. This is also what issue #1124 is about.The small sensor lookup dialogue will be re-used when we edit the flex-context and flex-model in a similar way, so it would be good to place it in a more central place, if that is possible.