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:

• Existing sensors_to_show information will be available and rendered on page load.
• JavaScript/HTML will allow to edit plots, add new "plots" and to remove them. For each plot entry, sensors can be added or removed and the (optional) plot title can be edited.
• On submit, the sensors_to_show JSON representation is constructed and send to the asset PATCH endpoint.
• Toast messages about failure / success are shown (see Toast messages in the account editing).

Here are TODOs, each can be a PR (please link them here when they are being worked on):

• Prepare sensor API for sensor lookup: Add all_accessible parameter and search filter (for the name and account name) like the asset API has. Also add a unit parameter.
• Move sensors_to_show from attributes to its own JSON field on the GenericAsset 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 Upgrade sensors_to_show to its own data model attribute #1124 is about.
• Edit modal for editing asset page graphs (see description and sketch above). Put the modal JavaScript in its own file, it will be a lot. For representation of the data and managing the entries: Bootstrap Groups/Tabs might give a good way to support the styling, and we might also look into the JS support (at the bottom of that page) to read the resulting structure when the user clicks "Save".

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.