When there are settings differences between those stored locally on Cockpit and those backed up on the vehicle (in BlueOS), the current conflict resolution mechanism provides limited information about what is actually different (which is confusing), does not clearly identify what the different options mean (so decisions are unintuitive), and requires confirming each setting individually (which can be rather annoying).
Problem identified by Phil, and agreed with by @vshie and me.
Expected or desired behaviour
A better approach would be to:
[ ] Describe more clearly what it means to have a settings conflict
"Your local Cockpit configuration does not match the backup on the connected vehicle. Which values should be used?"
A help icon tooltip or an expandable section could clarify "Your [Cockpit instance / vehicle] has been used with a different [vehicle / Cockpit instance], and the {user} user settings were reconfigured."
If Cockpit has more recent settings then it has been used with a different vehicle, and vice versa
[ ] Allow confirming all conflicting settings at once
[ ] Provide descriptions/tooltips to explain what each setting is actually used for
[ ] Specify which set of settings is newer, and ideally how old they are
Storing a timestamp when they're updated would allow this to be done intuitively
By default, select the newer settings
[ ] Provide some form of semantic diff between the options (i.e. what is new, what is removed)
Ideally this would be able to show visual differences for Views and the like, but that's probably excessive
A simpler (but still much better than current) approach would be to just show a diff between the json for that setting (over multiple lines if necessary)
This could potentially skip "hash" rows, and others determined to be unhelpful for the differentiation
[ ] Provide reasonable "don't ask me again" options
Users using the "user" options as intended should be able to decide on a personal preference for this and not need to think about it all the time
Prerequisites
[X] I have checked to make sure that a similar request has not already been filed or fixed.
Current behaviour
When there are settings differences between those stored locally on Cockpit and those backed up on the vehicle (in BlueOS), the current conflict resolution mechanism provides limited information about what is actually different (which is confusing), does not clearly identify what the different options mean (so decisions are unintuitive), and requires confirming each setting individually (which can be rather annoying).
Problem identified by Phil, and agreed with by @vshie and me.
Expected or desired behaviour
A better approach would be to:
{user}user settings were reconfigured."Prerequisites