Improved Check for Secondary Email Address

[Martinski4GitHub]

Improved code to check and make sure the "Secondary Email Address" option actually exists and has been set before setting WebGUI field correctly.

[Martinski4GitHub]

@ExtremeFiretop,

This PR addresses the "undefined" string shown on the "Secondary Email Address" field.

[ExtremeFiretop]

Great catch!

[Martinski4GitHub]

Great catch!

"The devil is always in the little details," ain't it? LOL!!!

[ExtremeFiretop]

Great catch!

"The devil is always in the little details," ain't it? LOL!!!

Yes absolutely! Happy you managed to find that in the code review!
I hope that vlord is happy

[TheS1R]

Improved code to check and make sure the "Secondary Email Address" option actually exists and has been set before setting WebGUI field correctly.

Auto update of dev build fired of at 23:45 EDT last evening.

[ExtremeFiretop]

Improved code to check and make sure the "Secondary Email Address" option actually exists and has been set before setting WebGUI field correctly.

Auto update of dev build fired of at 23:45 EDT last evening.

Love the feedback and continual testing Tom!
Thanks again! As you now know, not every PR to dev will auto update, but the PRs that button everything up for us we will update the timestamp to trigger the dev build auto updates.

[TheS1R]

Improved code to check and make sure the "Secondary Email Address" option actually exists and has been set before setting WebGUI field correctly.

Auto update of dev build fired of at 23:45 EDT last evening.

Love the feedback and continual testing Tom! Thanks again! As you now know, not every PR to dev will auto update, but the PRs that button everything up for us we will update the timestamp to trigger the dev build auto updates.

I would guess (but you're free to do whatever makes sense to you) that if you push something to the dev branch that you'd update the timestamp.

The wife came in from cleaning up snow (I couldn't after elbow surgery) one day in February to announce that she'd had enough winter, so we needed to head someplace warm. I could hardly argue — we're leaving in the morning for a week in St Pete Beach FL...

[ExtremeFiretop]

Improved code to check and make sure the "Secondary Email Address" option actually exists and has been set before setting WebGUI field correctly.

Auto update of dev build fired of at 23:45 EDT last evening.

Love the feedback and continual testing Tom! Thanks again! As you now know, not every PR to dev will auto update, but the PRs that button everything up for us we will update the timestamp to trigger the dev build auto updates.

I would guess (but you're free to do whatever makes sense to you) that if you push something to the dev branch that you'd update the timestamp.

Only when we deem it's ready, otherwise if stuff is still under development then we won't.
Same as Martinski mentioned below:

The new "buid number" on the version file (or more appropriately, the "build timestamp" if we follow my recommendation), is really meant only for developments builds where the version string remains the same so that when users are testing the alpha/beta builds they get new updates automatically when we change the timestamp; but, if the timestamp remains the same, the updates are no longer automatic (they must do "force updates"). This allows us to control when we deem the current development branch to be "good enough" for external testing purposes.

---

The wife came in from cleaning up snow (I couldn't after elbow surgery) one day in February to announce that she'd had enough winter, so we needed to head someplace warm. I could hardly argue — we're leaving in the morning for a week in St Pete Beach FL...

Nice, enjoy!
Hope you have a great time, and that you enjoy the heat! I'm just waiting for it to heat up here. We keep getting little teases of nice weather and it goes back to below zero C shortly after

[Martinski4GitHub]

Improved code to check and make sure the "Secondary Email Address" option actually exists and has been set before setting WebGUI field correctly.

Auto update of dev build fired of at 23:45 EDT last evening.

Love the feedback and continual testing Tom! Thanks again! As you now know, not every PR to dev will auto update, but the PRs that button everything up for us we will update the timestamp to trigger the dev build auto updates.

I would guess (but you're free to do whatever makes sense to you) that if you push something to the dev branch that you'd update the timestamp.

To further clarify the intended behavior. Currently, the build timestamp is not automatically generated for every push/commit to the development branch. By design, it must be updated manually because we want to control if and when a new development beta build is deemed suitable for automatic updates and for testing by the general public. Sometimes, we may have some new code changes/commits that are not yet "fully-cooked" or well-tested by us, so we prefer to keep those from updating automatically until we consider them "good enough" for public beta testing.

The wife came in from cleaning up snow (I couldn't after elbow surgery) one day in February to announce that she'd had enough winter, so we needed to head someplace warm. I could hardly argue — we're leaving in the morning for a week in St Pete Beach FL...

Yep, I hear you!!! When the wife says, "Let's pack up the suitcases and go someplace warm." You cannot argue!! LOL!!

Enjoy the warm weather in Florida!! I hope it's not yet too humid for you. Last time we were in the Tampa Bay area, some days were really humid for my taste, but the water was warm, nice & clear.

[ExtremeFiretop]

To further clarify the intended behavior. Currently, the build timestamp is not automatically generated for every push/commit to the development branch. By design, it must be updated manually because we want to control if and when a new development beta build is deemed suitable for automatic updates and for testing by the general public. Sometimes, we may have some new code changes/commits that are not yet "fully-cooked" or well-tested by us, so we prefer to keep those from updating automatically until we consider them "good enough" for public beta testing.

Exactly! And to even FURTHER clarify 😜 we probably will update that timestamp "manually" pretty often. As you know lots of the time our PRs by the time they are submitted/ merged are pretty much baked.

But other times it may take time to investigate or troubleshoot something, we may submit PRs in parts or bits. Especially for new features which are built in parts normally.

So generally I expect we will update it fairly often, especially for small fixes. But there will be instances were we deem it "not ready, more work to be done" but we are submitting what we have up to that point, and those PRs probably won't update the timestamp.

I actually kinda like the timestamp since Martinski added it, because it gives me a clear indication when he submits if he's in the "ready to test" mindset or "still work in progress " mindset. (Depending if he updated it or not in the PR)

[Martinski4GitHub]

To further clarify the intended behavior. Currently, the build timestamp is not automatically generated for every push/commit to the development branch. By design, it must be updated manually because we want to control if and when a new development beta build is deemed suitable for automatic updates and for testing by the general public. Sometimes, we may have some new code changes/commits that are not yet "fully-cooked" or well-tested by us, so we prefer to keep those from updating automatically until we consider them "good enough" for public beta testing.

Exactly! And to even FURTHER clarify 😜 we probably will update that timestamp "manually" pretty often. As you know lots of the time our PRs by the time they are submitted/ merged are pretty much baked.

But other times it may take time to investigate or troubleshoot something, we may submit PRs in parts or bits. Especially for new features which are built in parts normally.

So generally I expect we will update it fairly often, especially for small fixes. But there will be instances were we deem it "not ready, more work to be done" but we are submitting what we have up to that point, and those PRs probably won't update the timestamp.

I actually kinda like the timestamp since Martinski added it, because it gives me a clear indication when he submits if he's in the "ready to test" mindset or "still work in progress " mindset. (Depending if he updated it or not in the PR)

Yes, all good points.

[ExtremeFiretop]

@Martinski4GitHub

First day back at the office tomorrow since being sent home for COVID in 2020.
So about 5 years from home. All to say I have an early morning and so I'm heading off to bed buddy. Already took a sleeping pill and adjusted my alarms.

Wish me luck, talk more tomorrow!

[Martinski4GitHub]

@Martinski4GitHub

First day back at the office tomorrow since being sent home for COVID in 2020. So about 5 years from home. All to say I have an early morning and so I'm heading off to bed buddy. Already took a sleeping pill and adjusted my alarms.

Wish me luck, talk more tomorrow!

Best of luck, bud!! Have a good night's sleep!!