What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

MerlinAU MerlinAU v1.3.10 - The Ultimate Firmware Auto-Updater (GNUTON SUPPORT!)

There are 3 distinct sections. Each of the 2 bottom sections contains its own "Save" button that applies ONLY to that specific section.
What led to that design decision? It’s unlike most of the router UI “design”. All the config (from all addons) needs to be written back to custom_settings.txt every time you save, so I’m curious what you achieve with separate buttons.
 
Oh... I see...

So this "bug" became user not-friendly interface report...

I'll say it became a... "Limitations of a small screen" report 😉

I myself thought it was pretty intuitive when I designed the original interface to have a save for each section.

The thought is to have it similar to how MerlinAU has a main menu and an "Advanced Options" menu both with their own set of options to save.
 
So I’m curious what you achieve with separate buttons.
Honestly it's a fair question coming from another developer such as yourself.

It's just a design choice, the idea behind it is simply to maintain separation of the settings mostly.
 
Honestly it's a fair question coming from another developer such as yourself.

It's just a design choice, the idea behind it is simply to maintain separation of the settings mostly.
I took a look at the code and I see now that you don’t try to keep your settings in custom_settings.txt, but move them to your own config file. Makes a little bit more sense now.

It would still be friendlier to detect changes in either section and write them out together, but no matter. It’s just nice to see someone publish a new add-on WebUI. Well done!
 
I took a look at the code and I see now that you don’t try to keep your settings in custom_settings.txt, but move them to your own config file. Makes a little bit more sense now.

Exactly; basically this design choice came from early development, it was simply easier to troubleshoot the settings with some level of separation.
These days; I can see the argument both ways honestly. But early on when I was still in the process of piecing together how "it all worked" with the WebUI's; this was easier for me to keep track of everything.

It would still be friendlier to detect changes in either section and write them out together, but no matter. It’s just nice to see someone publish a new add-on WebUI. Well done!

Totally hear the feedback @dave14305 and I appreciate your honesty and you testing this out with us!
 
Last edited:
I just wish my router had half the updates that the auto-upgrade tool has. :)

HAHAHAHA. Love it. All I can say is that Martinski and I don't stop or play to any schedule. I get bored, I start writing code. 😉
 
Last edited:
Hi @maghuro
I believe I found the issue for this report below:
A little thing I noticed right away - when I switched to beta branch, in webui, the "enable automatic f/w update checks" was disabled. On terminal, it was enabled.
To solve this, on terminal, I disabled and enabled again this option, refreshed the webui and then the checkbox was shown correctly enabled.
I opened PR: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/418 to resolve it.
In short post upgrade using the "develop" switch, it does not update the value in the settings file; it only adds it:

1740861613704.png


Running the script a second time after installing the develop actually does set the value; and you would have no issues moving forwards.
This is the same thing as you discovered; which is if you immediately disable and enable the setting it also sets the value; and you would have no issues.

It's not a show stopper by any means; because toggling the setting fixes the bug, loading the script a second time fixes the bug, and even the automated cron job would also fix it.
Still wanted you to know we are on top of the report and a fix should be out later today hopefully. Thanks again!

Testing this specific bug will be only possible by completely uninstalling MerlinAU and reconfiguring from scratch (no saved settings)
 
@maghuro

PR has been merged.

Can be tested again by using the following command:

Code:
sh /jffs/scripts/MerlinAU.sh develop

As mentioned in the last reply, to properly test, you would need to downgrade back to the production version of MerlinAU, and delete the settings file... or just uninstall the current version and reconfigure from scratch before using the develop command.

Thanks!
 
@maghuro

PR has been merged.

Can be tested again by using the following command:

Code:
sh /jffs/scripts/MerlinAU.sh develop

As mentioned in the last reply, to properly test, you would need to downgrade back to the production version of MerlinAU, and delete the settings file... or just uninstall the current version and reconfigure from scratch before using the develop command.

Thanks!

Not before doing a Backup(Mon) 😀

Did that, it seems OK now! Thank you for your work 💪🏻
 
Below are recent updates to the DEVELOP branch.

MerlinAU Version 1.4.0 is still unreleased at this time; and only available for beta testing.
If you are currently on the production version 1.3.10 or develop 1.4.0; you may update to test these changes below using the following commands:

- v1.3.10 (update with)
Code:
sh /jffs/scripts/MerlinAU.sh develop

- v1.4.0 (update with)
Code:
sh /jffs/scripts/MerlinAU.sh forceupdate

We request any 1.4.0 testers to try both the new features below and report back.
Thanks!

PR: [ #419 ] - Allow Password Testing from WebUI
  • Added functionality to the WebGUI so that users can optionally select to run a "Router Login Test" when saving the password to verify that the login credentials are indeed valid.
  • This is similar to the option available in the CLI menu where users can select to run the same router login test.
  • (Thanks @Martinski4GitHub @Martinski)
    1. UNKNOWN

      1741544131009.png
      • Initial state displayed when the WebGUI starts and password validity hasn't yet been tested.
    2. VERIFIED

      1741544374635.png
      • Indicates the password has been confirmed valid after successfully completing a login test.
    3. INVALID / NOT verified

      1741544449646.png
      • INVALID: Displayed if a login test explicitly fails, confirming the password is incorrect.
      • NOT verified: Shown if the password was saved without running a login test, meaning the validity remains uncertain until tested explicitly.
PR: [ #420 ] - Allow viewing of the changelog from WebUI
  • I changed the "Approve Changelog" button for a "Latest Changelog" button and then moved the approval into a checkbox below..
  • I think it looks better and adds the additional functionality of the CLI: main menu --> Log Options (lo) --> Changelog (cl)

    1741543974011.png

    1741543939451.png
 
Last edited:
Last edited:

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top