Enable "sticky" features when changing FW type

[EvansCesilThomas]

I remember earlier we had the ability to keep the currently enabled features enabled and the disabled one disabled when switching to another firmware. Now the features get overwritten by the defaults when I switch to another FW.
For example, let us say I want to build a Pixhawk1-bdshot FW. I may not need all the features so I decide to start off from the -1M version and build on top of it by adding /removing features as removing features from the 2MB version will be more time consuming. But there is no button that keeps my current selections active as I switch but this used to exist a few months earlier.
I request to bring this back.
Thanks

[shiv-tyagi]

Hi @EvansCesilThomas, thanks for reporting this issue.

We recently upgraded our application architecture to better organize our APIs. As part of this change, we started including shipping defaults directly within the feature list, instead of first sending the feature list and then making a separate call to fetch the defaults.

Previously, this worked in your case because the second call was never triggered when the toggle was set to use the same default. The goal behind bundling defaults with the feature list was to:

1. Eliminate an extra API call and improve performance.
2. Ensure users always see the correct defaults (when available) upon selecting a board, reducing the risk of accidentally using defaults from a different board.
3. Make way to support different features on different boards for the same version.

That said, your use case is valid, some users may prefer “sticky” defaults. I’ll need to evaluate the feasibility and plan a proper frontend implementation to support this behavior.

[EvansCesilThomas]

Yes, I guess earlier I had to click Reset to Defaults to get the real defaults.
I guess a button can be implemented to activate the sticky feature but then you need the two API calls again.