[BUG 673] PSKReporter Always Uses FN31 as Grid Square#681
[BUG 673] PSKReporter Always Uses FN31 as Grid Square#681accius merged 1 commit intoaccius:Stagingfrom
Conversation
… as otehr code (eg PSKFilterManager) relies on it.
|
If someone could actually run through that test sequence for me before merge, I would appreciate it. By the time I got to the fix that would correct config.locator on load of the settings panel, I had already corrected it in my saved settings. Looking at the code, whether or not isOpen is true, it should ru the code that fixes the locator if the lat/lon is set. |
|
merging to staging we can test there. |
|
I tested this by downloading the files in the branch . . ./test/Staging into a new test subdirectory on my Linux machine. When I stared the system, my callsign and my grid square were already known - so this was not really a 'new install' where I would have had to start by entering that data . I did steps 1, 2, 3 above. My Grid Square is now correctly shown in the PSK Filter Manager. I am able to select my Grid Square. And I see the Activity in and out of from my Grid Square as expected. While I did not methodically regression test the entire system, I did not see any obvious issues, Bug 673 may be closed. |
|
Correction I got the files from . . . . /tree/Staging |
|
I also tested changing my Grid Square in the Main Settings Menu From PA to FL to verify that the new Grid Square I typed in followed me to the PSKReporter Filter Menu. It did. And the [DE] circle on the map also moved to that new FL Grid Square. All is good. |
What does this PR do?
Addresses #673
Updates SettingsPanel so that any update to the local "grid" variable results in an update to config.locator. Other functions (e.g. PSKFilterManager) pull the grid from config.locator, and as such were pulling a (very) incorrect value.
Type of change
How to test
Checklist
server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)var(--accent-cyan), etc.).bak,.old,console.logdebug lines, or test scripts included