MerlinAU MerlinAU v1.1.2 - The Ultimate Firmware Auto-Updater (Now available in AMTM)

[ExtremeFiretop]

I've just experienced the "high-risk phrases" workflow, and have some gentle suggestions for improvement.

I'd prefer if the change-log scan happened before the postponement period.

Unfortunately this suggestion would require a complete redesign of the workflow compared to our current method.
Will need to think about this more. It probably wouldn't work the way your suggesting but could maybe piggy back on an upcoming feature in v1.1.3

What happened instead is, I had already reviewed the change-log and didn't notice anything of concern or high-risk. After the postponement period had passed, I was puzzled that no update had occurred. I ran the update check to see what was wrong and only then was I told that I need to approve the update.

I would recommend setting up email notifications so you know that a high risk phrases is found in the changelog, and that's the reason the flash didn't happen.
In 1.1.3 the email notification's will contain the changelog contents for review as well.

So I reviewed the change-log again and still could not tell what the high risk item is.

The high risk item is:

- CHANGED: SIP, RTSP and H323 ALG (NAT helpers) are now
disabled by default, as these legacy features tend
to create issues with modern VoIP setups.
This change will only apply to people doing a
factory default reset of their router.

(Also identified with the arrow in the screenshot above)

 

[nlurker]

Please don't redesign everything based on my suggestion. I think I misunderstood how it is intended to work.

The new features in 1.1.3 look like they will help a lot with this situation, along with your suggestion to enable email.

(Perhaps you should call it 1.2, since there is new functionality and it is more than a bug fix.)

 

[ExtremeFiretop]

Please don't redesign everything based on my suggestion. I think I misunderstood how it is intended to work.

The new features in 1.1.3 look like they will help a lot with this situation, along with your suggestion to enable email.

(Perhaps you should call it 1.2, since there is new functionality and it is more than a bug fix.)

This release is slow cookin for sure, but it will have a decent amount of improvements and new features.

As for your suggestion the real issue I see is that currently the postpone stops "all" the logic for an update.
The entire run to flash an update as in, checking memory, setting up directories, downloading the zip, extracting the zip, doing file cleanups, etc all that stuff is held behind the postpone.

If all of a sudden I had to move stuff out from behind the postpone, or move the postpone to a different area of the script it could cause a mess I am not sure I am ready to deal with at the moment lol.
However that being said as you saw above we are working on new log related features. One of which is to download the latest changelog file for review at anytime.

This code works outside the main update logic and is not withheld by the postpone, it also doesn't include all the additional steps for a flash like memory checks and management, file management and downloading large zips for extractions.
Instead this new logic goes online just to grab the single .txt file related to your latest firmware's changelog and nothing else and makes that available to display.

I'm thinking we could maybe make that "arm" of the code be the one to do the changelog checks and it could run independently of the rest of the main update logic without a complete redesign of the flow.
Again I'll need to think more about this, it's not a solid no, but it's also not a solid yes lol. I need to sleep on this suggestion and make some decisions based on complexity and ideal use-cases.

Thanks again for the comment!
I do think you'll benefit from setting up email notifications in AMTM in the long run, and then configuring them in MerlinAU, at least this way if something fails in the future, you'll wake up to a message explaining "why' it did, without a need to troubleshoot.

 

[nlurker]

I agree with everything you said. Moving the changelog check out of the update logic would satisfy my request. It could be triggered immediately when a new release is discovered. The postponed update that comes along later would only need to check if an approval is needed and that I had given it.