View code on Github

v0.8.0: Better scheduling, safer data

AA batteries on wooden background, by Salman Hossain Saif
AA batteries on wooden background, by Salman Hossain Saif

Version v0.8.0 of FlexMeasures (see changelog) improves scheduling & helps to keep data safe. Behind the scenes, a big data model transition is taking form.

Better scheduling

We work with scheduling of batteries in practice, which is a great opportunity to find small and crucial improvements.

For instance, we were able to improve the stability in edge cases. FlexMeasures also now can take into account the limited round trip efficiency of batteries, as well as asymmetric buy/sell prices.

This work was done in Pull Requests 291, 267, 270, 300 and 291.

Safer data

If several accounts (customers) sit in the same FlexMeasures server, it is all the more crucial that only the correctly authorized persons get to see or change data.

v0.8.0 introduces the ability to protect data within users within one account, building on our multi-tenancy model from version 0.6.0. This work was done in Pull Request 210.

When implementing authorization, it's highly important to do that in a developer-friendly way. What we mean with that is developers need to find it straightforward to make the correct decisions of who has permission to create/read/update/delete which data, and which API endpoints require the user to have which permissions.

In v0.8.0, we implement an authorization model, where the first question is answered in one central place (on the data model) and with high granularity (object-level security). We also offer a new API endpoint decorator (@permission_required_for_context), so in-built endpoints, as well as API endpoints in plugins, can be protected easily.

This work was done in Pull Request 234.

Data model transition

Behind the curtains, this version makes a huge step from our deprecated data model to a new, more flexible one. We describe this transition in detail here, even with before & after pictures.

We are left with a few items on our TODO list, but in this version, we made a big effort. We moved a lot of structure over, as well as actual data and some UI (dashboard, assets). We believe that was the hardest part.

We also took care so existing users feel as little blockage as possible. We wrote extra code so the old data model can still function in the new world, and that data is copied over in the background (don't forget to do the database migration, of course, see changelog).