View Issue Details

IDProjectCategoryView StatusLast Update
0003493Ham Radio DeluxeBugpublic2019-11-08 02:32
ReporterWA9PIEAssigned ToK7ZCZ 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0003493: Complete the Callsign Lookup function for the QRZCQ method
DescriptionSome 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.

Additionally:
- 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 ReproduceI repro this in the 6.7.0.232 beta build (6.7.0.234 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 InformationThe 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.
TagsNo tags attached.
ModuleLogbook
Sub-ModuleCall lookup
Testing Beta Successful

Relationships

related to 0003464 closedWA9PIE Some fields missing from QRZ.com call sign lookup 
related to 0003548 closedK7ZCZ qrzcq.com, the Callsign Lookup does not correctly assign DXCC and HRDCountry 
child of 0003001 closedWA9PIE Callsign lookup function does not appear to be working as designed 

Activities

WA9PIE

2019-10-13 06:36

administrator  

CallsignLookupMapping32 (most_current)c.xlsx (25,768 bytes)
QRZCQ (KH0A).xml (857 bytes)

K7ZCZ

2019-10-17 19:20

administrator   ~0008850

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?

WA9PIE

2019-10-17 19:31

administrator   ~0008851

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.

K7ZCZ

2019-10-19 11:17

administrator   ~0008869

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?

WA9PIE

2019-10-19 17:28

administrator   ~0008872

Sorry... I don't know why it says "bmanager". The correct field is "manager" as follows:

<manager>JF1MIA</manager>

(I'm going back to look at notes to find out if "bmanager" is a typo or if it was actually in other results.)

K7ZCZ

2019-10-20 15:56

administrator   ~0008883

This checkin adds IOTA and the country look-aside, and fixes "manager" for "bmanager":
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5227

WA9PIE

2019-10-21 09:39

administrator   ~0008887

Last edited: 2019-10-21 10:03

View 2 revisions

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:

<name>, <call>
<address>
<city>, <state> <zip>
<country>

Thus, the COL_ADDRESS would be populated as:
Takashi Sugawara, KH0A
C/o Barry Rickett 14 Vincent Dr
Pittsford, NY 14534
United States

- <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

K7ZCZ

2019-10-21 16:59

administrator   ~0008900

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:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5230

WA9PIE

2019-10-22 19:17

administrator   ~0008905

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)

K7ZCZ

2019-10-23 10:14

administrator   ~0008979

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.

WA9PIE

2019-10-23 16:36

administrator   ~0008987

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.

K7ZCZ

2019-10-23 16:49

administrator   ~0008988

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?

WA9PIE

2019-10-23 19:47

administrator   ~0008990

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.

K7ZCZ

2019-10-24 13:09

administrator   ~0009006

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?

WA9PIE

2019-10-24 17:25

administrator   ~0009007

I'm not suggesting a change in the workflow.

WA9PIE

2019-10-29 03:29

administrator   ~0009055

Validated

Issue History

Date Modified Username Field Change
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 => 6.7.0.239
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 6.7.0.239 => 6.7.0.244
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe