known operator list forgets entries

[caver456]

Multiple reports of this problem over the last several months. Is it possible that the known operators file gets clobbered with version upgrades?

[caver456]

Running the 3.7.0 installer to overwrite an installation of 3.6.1 did not clobber the operators file - an operator from 3.6.1 was still in the known operators list when starting 3.7.0. So - need to look deeper.

[caver456]

Also - should try in R5 as well, since the test above was done on a different computer.

[caver456]

Checked before and after upgrade to 3.8.0 on SAR 1A, R5 dispatch, and trailer dispatch. In all cases, the operator list before upgrade was the same as the operator list after upgrade.

The operator file is different per Windows account, but that wouldn't explain any apparent problems in R5.

[caver456]

saveOperators() is called from these places:

• end of loginDialog.accept
• MainWindow.closeEvent

self.operatorsDict is written to the operators file. self.operatorsDict is modified in these places:

• MainWindow.init (of course - initialized as a dict with one key 'operators' whose valie is an empty list)
• loadOperators (of course)
• MainWindow.closeEvent - usage dictionaries are updated (by reference?) before saving the file
• loginDialog.accept to add a new operator
• loginDialog.accept to update usage dictionaries (by reference?)

[caver456]

added code in commit to master to show operatorsDict names at each place that it's modified, loaded, or saved as above

[caver456]

Got some transcripts using 3.10.0dev from R5. The extra log lines mentioned above are in place and working, but, they didn't show the problem. So - add some additional code to copy the operators file into the run dir, at startup time, and again at shutdown time.

[caver456]

Got a lucky break on this issue, just checking for file sizes of operators_at_startup.json vs operators_at_shutdown.json. In a test case run thing_1_20203_11_26_163719, the startup json has several entries but the shutdown json is empty (though properly formatted):

These are the only snippets from that run's transcript that reference 'operator':

...
162430:useOperatorLogin after readConfigFile:True
...
163732:Updating operator usage statistics from MyWindow.closeEvent.  List of operators before update:
[]
163732:saveOperators called
163732:Saving operator data file C:\Users\caver\RadioLog\.config\radiolog_operators.json with these operators:[]

followed by just a few more lines to the end of the transcript, which looks like a normal shutdown:

163732:  writing C:\Users\caver\RadioLog\thing_1_2023_11_26_163719\thing_1_2023_11_26_163719.csv
163732:  done writing C:\Users\caver\RadioLog\thing_1_2023_11_26_163719\thing_1_2023_11_26_163719.csv
163732:  writing C:\Users\caver\RadioLog-2WD\thing_1_2023_11_26_163719.csv
163732:  done writing C:\Users\caver\RadioLog-2WD\thing_1_2023_11_26_163719.csv
163732:  writing C:\Users\caver\RadioLog\thing_1_2023_11_26_163719\thing_1_2023_11_26_163719_clueLog.csv
163732:  done writing C:\Users\caver\RadioLog\thing_1_2023_11_26_163719\thing_1_2023_11_26_163719_clueLog.csv
163732:  writing C:\Users\caver\RadioLog-2WD\thing_1_2023_11_26_163719_clueLog.csv
163732:  done writing C:\Users\caver\RadioLog-2WD\thing_1_2023_11_26_163719_clueLog.csv
163732:Writing file C:\Users\caver\RadioLog\thing_1_2023_11_26_163719\radiolog_fleetsync.csv

So it looks like the issue is that loadOperators was never called. Investigating why this would happen...

[caver456]

Compare this snippet from a 'correct' session (i.e. loadOperators was called right after the COM port scan):

053600:radiolog sessions from the last 4 days:
053600: (hiding empty sessions; only showing the most recent session of continued incidents)
053600:C:\Users\caver\RadioLog\New_Incident_2023_11_10_211944\New_Incident_2023_11_10_211944
053600:C:\Users\caver\RadioLog\test1_2023_11_09_202741\test1_2023_11_09_202741
053604:Initial entry: Radio Log Begins: Sat Nov 11, 2023
053604:Renamed session directory to "C:\Users\caver\RadioLog\New_Incident_2023_11_11_053604"
053604:fsLoadLookup called: startupFlag=True  fsFileName=None  hideWarnings=False
053604:Loading FleetSync Lookup Table from file C:\Users\caver\RadioLog\.config\radiolog_fleetsync.csv
053604:Writing file C:\Users\caver\RadioLog\New_Incident_2023_11_11_053604\radiolog_fleetsync.csv
053605:  Opened newly found port COM2
053607:loadOperators called
053607:Loading operator data from file C:\Users\caver\RadioLog\.config\radiolog_operators.json
053607:  loaded these operators:['DAUGHERTY,KATHI', 'henscheid,marci', 'Alex,Joiner', 'Weidler ,Jerry', 'Smith,Gary', 'Dyer,Chris', 'Grundy,Tom']
053607:operator items to show in loginDialog knownComboBox (current operator excluded):[['Alex, Joiner  1SAR87', ['Alex', 'Joiner', '1SAR87']], ['DAUGHERTY, KATHI  1SAR29', ['DAUGHERTY', 'KATHI', '1SAR29']], ['Dyer, Chris  1SAR8', ['Dyer', 'Chris', '1SAR8']], ['Grundy, Tom  1SAR35', ['Grundy', 'Tom', '1SAR35']], ['Smith, Gary  1SAR2', ['Smith', 'Gary', '1SAR2']], ['Weidler , Jerry  SAR 1 ', ['Weidler ', 'Jerry', 'SAR 1 ']], ['henscheid, marci  1sar85', ['henscheid', 'marci', '1sar85']]]
053619:     DATA IS WAITING!!!
053619:      VALID FLEETSYNC DATA!!!

with this snippet from 'incorrect' session thing_1:

162431:radiolog sessions from the last 4 days:
162431: (hiding empty sessions; only showing the most recent session of continued incidents)
162431:C:\Users\caver\RadioLog\thing_1_2023_11_26_162415\thing_1_2023_11_26_162415
163719:Initial entry: Radio Log Begins - Continued incident "thing 1": Operational Period 2 Begins: Sun Nov 26, 2023
163719:Renamed session directory to "C:\Users\caver\RadioLog\thing_1_2023_11_26_163719"
163719:fsLoadLookup called: startupFlag=True  fsFileName=None  hideWarnings=False
163719:Loading FleetSync Lookup Table from file C:\Users\caver\RadioLog\.config\radiolog_fleetsync.csv
163719:Writing file C:\Users\caver\RadioLog\thing_1_2023_11_26_163719\radiolog_fleetsync.csv
163720:  Opened newly found port COM1
163720:  Opened newly found port COM2
163720:  Opened newly found port COM4
163724:non-team-hotkey "2" pressed; calling openNewEntry

The obvious difference is that the incorrect session was a continued incident. Trying it now, sure enough, starting a continued incident does NOT show the login dialog. Smoking gun.

But why does this problem show up so infrequently? Because any time the operator dialog is shown, loadOperators is called. So, as long as the operator icon is clicked and the dialog is shown at least once in a given session, even if that session is a continued incident, then the operators table will be loaded and populated correctly. The only time the 'forgetting' would happen is for a continued incident where the the operator button is never clicked during the session. Then, when radiolog is closed, the blank operator table gets saved, clobbering the one that never got loaded.

So the solution should be to make sure the operator dialog is shown no matter what, to trigger loadOperators, even for continued incidents.

[caver456]

This part of the existing code in MainWindow.init shows that the decision to not show options is intentional:

        if not restoreFlag:
            self.checkForContinuedIncident()

        if self.isContinuedIncident:
            showStartupOptions=False
                        ...

loginDialog is only shown from inside startupOptions - so, if startupOptions is never called, loginDialog is never shown:

    def startupOptions(self):
                ...
        if self.useOperatorLogin:
            self.loginDialog.toggleShow()
            self.loginDialog.exec_() # force modal

Should probably change this logic:

1. make sure loadOperators is called even if loginDialog is not shown
2. show loginDialog even if startupOptions is not called

[caver456]

Also modifying saveOperators to not save the file if there are no operators.

[caver456]

Also took steps to make sure the operator dialog shows up after the options dialog (if shown at startup) is closed, and to make sure it is shown after the main window is open (with the singleshot near the end of MainWindow.init)