add confirmation to (OS) install on update

[Mariusthvdb]

please consider as title.

background:
the new install/skip on the new update entities are great…

until you accidentally click install on an OS update, which you really wanted to skip.

Happened to me this morning, when my phone slipped out of my hand. some sort of “Are you sure” would have been nice, now I am running a beta OS and am not sure I like that just yet…

I am aware we can cli a OS downgrade, but a confirmation could simply prevent an accident like this.
Thing is, I have encountered a few ‘bricked’ Rpis before when updating the OS and because of that am very cautious updating them. Always check the issues on the OS GitHub repo first etc etc, and, wait a bit. Its way more impactful than updating Core (of which I run the dev nightly, and never have any issues with)

A confirmation on an OS update would be very welcome because of that.

thanks for considering

[CaptTom9]

I'd expand this to any updates; core, OS or supervisor. I'm always checking the updates, and clicking/tapping on the link to the release notes.

Normally, I hate confirmation dialogs, and think they're overused. This is one of the few times that one would really make sense. I live in fear of the day something like this happens to me, and the update button gets inadvertently selected.

[spacegaier]

PR created #12449

[spacegaier]

Update: PR rejected and I closed it now

[matthiasdebaat]

As responded to #12449, Nielsen Norman group has a nice article about confirmation dialogs. We should use them before committing actions with serious consequences, but not for routine actions. People will stop paying attention to the question and the confirmation dialog will lose its power to prevent errors. Exactly what the discussion above is about. When it's a repetitive task with the severity of different outcomes we should only show confirmation dialogs when the risk is significantly high. That is for us to decide.

We should only show a confirmation dialog when there are breaking changes, because this kind of update might stop your system. It would be great if we show what kind of breaking changes affect him.

[frenck]

We could add a flag to the update entity to indicate such a thing?
It's up to the implementer/integration to indicate whether it's major or not at that point.

An advantage of this approach could be that this information would also be available for automations (e.g., do not automatically upgrade in such cases).

[matthiasdebaat]

Sounds great!

[Mariusthvdb]

not sure where this now is going, but, as you can see in my opening title, I already made a distinction between updates of more gravity (OS) than the regular (Core) updates... at least that was what I was trying to bring across.

for me, I almost click the update Core button blindly, also knowing a downgrade is fairly easy using the CLI. However, downgrading a bricked Instance because of a failing beta OS is way less obvious, hence the requested confirmation on that.

Would maybe be a start to differentiate between those 2 installs using the flag?