Cloudlog icon indicating copy to clipboard operation
Cloudlog copied to clipboard

US county is not re-enabled after field reset

Open phl0 opened this issue 3 years ago • 5 comments

Describe the bug The US county field is disabled upon entry of a non-US callsign. But it remains disabled after resetting the fields. So Logging a second QSO after that entry of US county or prefill of US county is not possible. Reloading the log entry page re-enables the field.

To Reproduce Steps to reproduce the behaviour:

  1. Enter a non-US callsign into the callsign field
  2. Check the "General" tab
  3. US County field is disabled (i.e. greyed out)
  4. Press ESC or "Reset" button
  5. US County field is not re-enabled

Expected behaviour US County field should be re-enabled during field reset

Screenshots

Screenshot from 2022-09-24 21-20-26

phl0 avatar Sep 24 '22 19:09 phl0

A patch for this behaviour can be found in https://github.com/magicbug/Cloudlog/pull/1619.

phl0 avatar Sep 24 '22 20:09 phl0

It is disabled because no state is filled. It does only check against that, not dxcc. And if you enable it, then press reset, it is still enabled. I remember that selectize.destroy would create trouble with some other js. I don't know what it was, but it was commented out in qso_edit in footer.php and also around line 2609.

AndreasK79 avatar Sep 24 '22 20:09 AndreasK79

It is also commented out in qso.js:58.

AndreasK79 avatar Sep 24 '22 20:09 AndreasK79

The only problem I see here, is that it is enabled after reset, so that it should not be enabled after reset. The reason why I did this, is that the state is needed to search correctly after county. There are so many counties, and many of them have the same name, just different state, so state if used to filter.

AndreasK79 avatar Sep 24 '22 20:09 AndreasK79

I think it also has to do with https://github.com/magicbug/Cloudlog/issues/1615#issue-1382892278. The lookup function gives callsign_usa_county back. And there are two cases which obviously lead to different tesults. It can be an empty string "" which I think works correct. But there is also the case where it gives NULL and this leads to different behaviour (where it should not imho).

Need to look deeper into this why and where this differs. So my current patch my be inappropriate (though I think separate variable names to the selections would not harm).

phl0 avatar Sep 25 '22 05:09 phl0