View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003493||Ham Radio Deluxe||Bug||public||2019-10-13 06:36||2019-11-08 02:32|
|Target Version||Fixed in Version||18.104.22.168|
|Summary||0003493: Complete the Callsign Lookup function for the QRZCQ method|
|Description||Some fields or data are missing from the QRZCQ callsign lookup method.|
Once the QRZCQ data is obtained for a given callsign, the following ALE fields should be populated from the data found as follows:
- COL_QSL_VIA should contain the data in the "bmanager" tag in the response
- COL_QSO_IOTA should contain the data in the "iota" tag in the response
- COL_QSO_LAT should contain the data in the "latitude" tag in the response
- COL_QSO_LON should contain the data in the "longitude" tag in the response
- COL_QSO_STATE should contain the data in the "state" or "dok" tag in the response
- COL_QSO_DXCC should contain the data in the "dxcc" tag in the response
- COL_COUNTRY should contain the Country name found in the Country List for the "dxcc" tag found in the response
- COL_CONT should contain the Continent name found in the Country List for the "dxcc" tag found in the response
- COL_QSO_QTH should contain the data in the "city" tag in the response
None of these fields are being populated.
- The Country name found in the Country List for the "dxcc" tag found in the response should be added as the last line in COL_QSO_ADDRESS
- The data currently found in the COL_QSO_NAME field is repeated below the address in COL_QSO_ADDRESS and should be removed
|Steps To Reproduce||I repro this in the 22.214.171.124 beta build (126.96.36.199 can't be tested because it crashes 0003484).|
- Open up Logbook
- Setup Callsign Lookup by Tools > Configure > Callsign Lookup and make sure that QRZCQ is the only Enabled method listed above Country List in Enabled Methods
- Click "Ok"
- Open an ALE
- Enter the callsign "KH0A" (without the quotes)
- Press the "Lookup" button or hit tab
Result: These fields are populated in the respective fields in the ALE
|Additional Information||The correct result should be:|
- COL_QSL_VIA should contain "JF1MIA" (without the quotes)
- COL_QSO_IOTA should contain "OC-086" (without the quotes)
- COL_QSO_LAT should contain "43.070012" (without the quotes)
- COL_QSO_LON should contain "-77.515333" (without the quotes)
- COL_QSO_STATE should contain "NY" (without the quotes)
- COL_QSO_DXCC should contain "291" (without the quotes)
- COL_COUNTRY should contain "United States" from the Country List (without the quotes)
- COL_CONT should contain "NA" from the Country List (without the quotes)
- COL_QSO_QTH should contain "Pittsford" (without the quotes)
- COL_QSO_ADDRESS should contain:
"Takashi Sugawara, KH0A
C/o Barry Rickett 14 Vincent Dr
Pittsford, NY 14534
United States" (without the quotes)
I've included a copy of the field mapping spec and the QRZCQ response for KH0A.
|Tags||No tags attached.|
CallsignLookupMapping32 (most_current)c.xlsx (25,768 bytes)
QRZCQ (KH0A).xml (857 bytes)
This data source also returns ITU Zone, CQ Zone, Locator, and Name. Should those values be discarded?
Should this source not compute an HRD country number based on the DXCC?
The note above asays the QTH field "should contain "Pittsford" from the Country List (without the quotes)". I don't see any city names in the Country List. What is really meant to happen here?
The purpose of this Mantis issue is to describe the fields that are NOT being populated. I did not clutter it with fields that ARE being populated. I would refer to the field mapping spec that the items highlighted red or yellow are the ones that need to be fixed. the ones that are not highlighted were tested and do work.
So yes... all those fields you mention should be used. But that said - they already work and should continue to work.
I'm correcting my typo in this Mantis record regarding Pittsford.
||The desired results say that COL_QSL_VIA should have "JF1MIA". It's not clear where this value comes from. The given spreadsheet (named "CallsignLookupMapping32 (most_current)c.xlsx") says that, for QRZCQ lookups, the "bmanager" field should be used to populate COL_QSL_VIA. But the given "QRZCQ (KH0A).xml" response, which matches my own response in testing, does not include a "bmanager" field. "JF1MIA" does appear in the "manager" field in the response, though. Is the COL_QSL_VIA field meant to be populated from "manager" instead? Or are the desired results incorrect, and COL_QSL_VIA is meant to come from "bmanager", and should be empty in the given test case?|
Sorry... I don't know why it says "bmanager". The correct field is "manager" as follows:
(I'm going back to look at notes to find out if "bmanager" is a typo or if it was actually in other results.)
This checkin adds IOTA and the country look-aside, and fixes "manager" for "bmanager":
This describes only those fields that are not functioning correctly. If it's not mentioned here, it's working correctly.
Using KH0A as the example with only QRZCQ added as an "Enabled Method" (aside from the two UCSDB and Country List):
- <manager> field in the XLM response is not being populated into the COL_QSL_VIA field
<manager>JF1MIA</manager> should populate JF1MIA in the COL_QSL_VIA field; this would be shown in the QSL tab
- COL_ADDRESS field is no longer being populated. The full name is being repeated below the address. It should popluate as follows:
<city>, <state> <zip>
Thus, the COL_ADDRESS would be populated as:
Takashi Sugawara, KH0A
C/o Barry Rickett 14 Vincent Dr
Pittsford, NY 14534
- <latitude> field in the XML response is not being populated into the COL_LAT field
<latitude>43.070012</latitude> should populated into the Latitude field as "43.070012" without quotes; seen in the Location tab of the ALE
- <longitude> field in the XML response is not being populated into the COL_LON field
<longitude>-77.515333</longitude> should populated into the Latitude field as "-77.515333" without quotes; seen in the Location tab of the ALE
- <city> field in the XML response is not populated in the COL_QTH field
<city>Pittsford</city> should be populated into the field labeled QTH as "Pittsford" without quotes; seen in the main upper window in the ALE and in the Location tab of the ALE
- <state> field in the XML response is not being populated in the COL_STATE field
<state>NY</state> should be populated into the field labeled State as "NY" without quotes; seen in the main upper window in the ALE and in the Location tab of the ALE
Address, Latitude, and Longitude populate just fine for me.
QSL_VIA wasn't being populated because the spreadsheet part of the specification said to use "bmanager" rather than "manager". I've changed the code to use "manager".
QSL_STATE wasn't populating because of a side-effect of the code which built the concatenated address string.
QSL_CNTY and QSL_WEB weren't populating and previously not tested here; now fixed.
Changes made in this set:
I'm posting an image that shows what needs to be fixed for Address, Latitude, and Longitude. (While the Lat/Lon is depicted in the upper ALE, it's not depicted in the Location tab. The data in the upper ALE does not appear to be from the enabled method. It seems to be coming from the Country List because Lat Long fields aren't being populated.)
Some of the other things shown in this image may have been fixed in a check-in that hasn't been built yet.
AddressLatLong.png (145,438 bytes)
AddressLatLong.png (145,438 bytes)
The checkin to fix this issue was made in change set 5230. That change set has not been made available in any build. This is the second time in as many weeks that an issue has been reactivated before it could possibly have been tested.
In my desktop builds, the code is behaving as described here. It can be tested when a new installable build is made available.
||I posted that last comment because your last post began with “Address, Latitude, and Longitude populate just fine for me.”. From that, I got the impression that the work was testable.|
||I thought "Fixed In Version" was used to indicate that an issue was testable. Going forward, what process am I meant to use to avoid revisiting issues like this?|
Now I’m completely confused. I’m not suggesting a process change.
You reported that Address Lat and Lon worked for you.
I tested it and posted my findings.
You then told me that it wasn’t in a build yet (ie no FiV possible yet).
If it’s testable, then it would have an FiV.
If it’s not in a build yet, then it’s not testable and the FiV would refer to the build that I tested.
This has all worked fairly well for the past couple years. Not suggesting a change. Sorry.
I'm looking for a change because issues which aren't testable (because no fix is available) are being tested prematurely, and being re-activated. This issue had no fixed-in vesion set, for example, but was moved from resolved to opened and reassigned to me even though my fix wasn't yet put into a build and made available for testing.
Are you saying that's the intended workflow?
||I'm not suggesting a change in the workflow.|
|2019-10-13 06:36||WA9PIE||New Issue|
|2019-10-13 06:36||WA9PIE||Status||new => assigned|
|2019-10-13 06:36||WA9PIE||Assigned To||=> K7ZCZ|
|2019-10-13 06:36||WA9PIE||File Added: CallsignLookupMapping32 (most_current)c.xlsx|
|2019-10-13 06:36||WA9PIE||File Added: QRZCQ (KH0A).xml|
|2019-10-13 06:36||WA9PIE||Relationship added||related to 0003001|
|2019-10-13 06:37||WA9PIE||Relationship deleted||related to 0003001|
|2019-10-13 06:37||WA9PIE||Relationship added||child of 0003001|
|2019-10-13 06:37||WA9PIE||Relationship added||related to 0003464|
|2019-10-13 07:51||WA9PIE||Description Updated||View Revisions|
|2019-10-13 07:51||WA9PIE||Steps to Reproduce Updated||View Revisions|
|2019-10-13 07:51||WA9PIE||Additional Information Updated||View Revisions|
|2019-10-13 09:04||WA9PIE||Description Updated||View Revisions|
|2019-10-17 19:20||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-10-17 19:20||K7ZCZ||Status||assigned => feedback|
|2019-10-17 19:20||K7ZCZ||Note Added: 0008850|
|2019-10-17 19:31||WA9PIE||Note Added: 0008851|
|2019-10-17 19:33||WA9PIE||Description Updated||View Revisions|
|2019-10-17 19:33||WA9PIE||Additional Information Updated||View Revisions|
|2019-10-17 19:34||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-10-19 11:17||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-10-19 11:17||K7ZCZ||Note Added: 0008869|
|2019-10-19 17:28||WA9PIE||Note Added: 0008872|
|2019-10-19 17:28||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-10-20 15:56||K7ZCZ||Status||feedback => resolved|
|2019-10-20 15:56||K7ZCZ||Resolution||open => fixed|
|2019-10-20 15:56||K7ZCZ||Note Added: 0008883|
|2019-10-21 09:39||WA9PIE||Note Added: 0008887|
|2019-10-21 09:40||WA9PIE||Status||resolved => assigned|
|2019-10-21 09:40||WA9PIE||Resolution||fixed => reopened|
|2019-10-21 10:03||WA9PIE||Note Edited: 0008887||View Revisions|
|2019-10-21 16:59||K7ZCZ||Status||assigned => resolved|
|2019-10-21 16:59||K7ZCZ||Note Added: 0008900|
|2019-10-22 19:17||WA9PIE||File Added: AddressLatLong.png|
|2019-10-22 19:17||WA9PIE||Note Added: 0008905|
|2019-10-22 19:18||WA9PIE||Status||resolved => assigned|
|2019-10-23 10:14||K7ZCZ||Note Added: 0008979|
|2019-10-23 10:14||K7ZCZ||Status||assigned => resolved|
|2019-10-23 16:36||WA9PIE||Note Added: 0008987|
|2019-10-23 16:49||K7ZCZ||Note Added: 0008988|
|2019-10-23 19:47||WA9PIE||Note Added: 0008990|
|2019-10-24 13:09||K7ZCZ||Note Added: 0009006|
|2019-10-24 13:09||K7ZCZ||Assigned To||K7ZCZ => WA9PIE|
|2019-10-24 17:25||WA9PIE||Note Added: 0009007|
|2019-10-24 17:25||WA9PIE||Assigned To||WA9PIE => K7ZCZ|
|2019-10-29 03:29||WA9PIE||Status||resolved => closed|
|2019-10-29 03:29||WA9PIE||Fixed in Version||=> 188.8.131.52|
|2019-10-29 03:29||WA9PIE||Testing||Not Started => Beta Successful|
|2019-10-29 03:29||WA9PIE||Note Added: 0009055|
|2019-11-04 22:05||K7ZCZ||Relationship added||related to 0003548|
|2019-11-08 02:10||WA9PIE||Fixed in Version||184.108.40.206 => 220.127.116.11|
|2019-11-08 02:32||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|