Add firmware upgrade notification to status page #7597
Conversation
This allows each include to perform an action a single time but don't run it on each poll. The function receives all data loaded via the `load` function. Signed-off-by: Paul Spooren <mail@aparcar.org>
If the UCI luci core section contain the option `check_firmware_version` then a load of the status page checks if the download server offers a new firmware compatible with the currently running device. Signed-off-by: Paul Spooren <mail@aparcar.org>
| && boardinfo.release.version > data.stable_version | ||
| && data.upcoming_version > boardinfo.release.version | ||
| && checkDeviceAvailable(boardinfo, data.upcoming_version)) { | ||
| showUpgradeModal("upcomming", boardinfo.release.version, data.upcoming_version) |
There was a problem hiding this comment.
upcoming (or just new?)
There was a problem hiding this comment.
Or maybe "release candidate"? since I think that's the only thing ever to populate the upcoming_release field in .versions.json...
| oneshot: function(data) { | ||
| var boardinfo = data[0]; | ||
| var check_upgrades = uci.get_first('luci', 'core', 'check_firmware_version') || false; | ||
| console.log(check_upgrades) |
| } | ||
| }) | ||
| .catch(error => { | ||
| console.error('Failed to fetch profile information:', error); |
There was a problem hiding this comment.
consider adding more context to the error. A user who doesn't know about this feature might be confused by this err string, even though it's a console message.
|
Consider using // ui.addNotification(a, message, timeout, severity)
ui.addNotification(null, E('p', _('A new firmware is available.')), 60000, 'info'); |
| ]); | ||
| }, | ||
|
|
||
| oneshot: function(data) { | ||
| var boardinfo = data[0]; | ||
| var check_upgrades = uci.get_first('luci', 'core', 'check_firmware_version') || false; |
There was a problem hiding this comment.
I'm not sure but I think that should be 'main' and not 'core', assuming the js versions work like the cli tool:
$ uci show luci.core
uci: Entry not found
$ uci show luci.main
luci.main=core
luci.main.lang='auto'
luci.main.mediaurlbase='/luci-static/openwrt2020'
luci.main.resourcebase='/luci-static/resources'
luci.main.ubuspath='/ubus/'
|
Is this forced to all users? Also for those who regularly build their own builds every few days... I am wondering if this should either
In many OEM firmwares that I have seen, the upgrade check/notice is in a system admin menu, not on the front page. (And hopefully the data is not polled by every 5 seconds) |
At most once a week is optimistic, once a month preferred (cronjob trigger?). But that's probably why the function is a oneshot. I suppose it could have a counter, and disable itself after a few tries, only to be activated after the next upgrade / reboot. |
|
It runs every time you open the status page and does nothing in the background, why should it anyway. It's not enabled by default but could be if users want that. A modal could open once and ask the user if they want to automatically check for upgrades when opening the web interface. Additionally we could add a button somewhere to manually switch. |
Putting a "Don't show me again" button right on the modal dialog would probably be pretty easy, it could just do |
I feel that any automatic call-to-home should be opt-in, not something to be opted out. By default, the OpenWrt routers are currently not contacting OpenWrt servers before the user selects some action like opkg/APK that triggers the contact. That "no automatic call-home" was the OpenWrt stance a few years ago, when there was discussion about collecting usage stats, device counts etc. |
|
This is out of the question, it'd always be an opt in feature. I'll see how to implement that and update this PR accordingly |
|
It's already opt-in. The value for |
|
A couple thoughts:
We could use this to our advantage to handle the "startup case". When that value is undefined, it could be a trigger for LuCI to pop up the "Opt in/Opt out" window. We could treat the Yes and No answers in the obvious way, and treat a click on "ask me later" or simply dismissing the window by leaving it undefined. (We would probably implement similar behavior for the CLI as well...) Once we get permission, the question is "when does the router check?" I am reluctant to queue up any kind of cron job because it creates a permanent load on our servers. My inclination would be to (both) request opt-in/opt-out and check for updates when there's interesting activity in LuCI or the command line, perhaps at login. That way we can be certain that there's a human present who can view and act on the "New Version" notice. |
Yeah, that's the current behavior. You log in, it pops up the notice. I've had this PR running on my main router (23.05.5) for a couple weeks and it simply shows the dialog every morning when I log in for status. It's pretty non-intrusive... |
|
More thoughts:
|
|
Currently snapshots are ignored by this, you need to go to ASU and do a "check for update" to get the check with those. RCs are included as part of the The download URL includes both the current version and target/subtarget of the device, which is the same as when doing ASU's "check for newer", so if you were already doing that, this won't leak any more information than you already did. |
|
To move things forward I'd take the logic from this PR and add it to |
|
Given that we don't live in a perfect world, a link to the current release notes would be my recommendation (firmware selector does not have this prominently displayed anywhere). Rare, but sysupgrades can result in a brick. |
This is likely not cleanly implemented, I'm unfamiliar with the LuCI tricks and JavaScript in general.
The core idea is to show a notification whenever a new firmware is available.
Right now it's just a notification, this could be extended to include the luci-app-attendedsysupgrade functionality or a slimmed down version.
@jow- please have a look
Signed-off-by: <my@email.address>row (viagit commit --signoff)<package name>: titlefirst line subject for packagesPKG_VERSIONin the Makefile