View Issue Details

IDProjectCategoryView StatusLast Update
00035573 - Current Dev ListBugpublic2019-11-07 10:09
ReporterWA9PIEAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0003557: Add DXCC Country as the last row in the address field for HamCall.net
DescriptionBecause the address field is used for the mailing label, and because our customers are International, we should add the DXCC country as the last row in the address field.

(The address field is correctly being placed here for all other lookup methods except Hamcall; separate Mantis issue for it.)
Steps To Reproduce1 - Launch Rig Control
2 - Launch Logbook
3 - Go to Tools > Configure > Callsign Lookup... Enable tab
4 - Add only HamCall.net
resulting order is UCSDB (Public), UCSDB (Private), HamCall.net, Country List
5 - Press "Apply"
6 - Click the "Test" tab
7 - Enter "WA9PIE" (without quotes) and click "Lookup"
8 - Observe the results where the address field does not populate Country at the bottom of the address field.

See attached image.
Additional InformationI don't consider this a show-stopper for the 6.7 release. If it gets done... great. Otherwise, we can do this in an upcoming maintenance release.
TagsNo tags attached.
ModuleLogbook
Sub-ModuleCall lookup
TestingNot Started

Relationships

related to 0003556 newK7ZCZ Add DXCC Country as the last row in the address field for callook.info 

Activities

WA9PIE

2019-11-06 16:25

administrator  

Hamcall address field.png (88,000 bytes)
Hamcall address field.png (88,000 bytes)

K7ZCZ

2019-11-06 21:55

administrator   ~0009185

The code is behaving per the specification right now. The specification says that the country line (the last line) of the address comes from field #209, which the API documentation describes as "mailing country". The lookup from WA9PIE yields no value for 209, so nothing is aded to the field.

The DXCC country field (the undocumented #225 field) is also blank, so there's no way to compute a DXCC country.

I don't see a way to do what you're asking. That must mean that you've actually intended to ask for something else. What is it? For example, the WA9PIE lookup returns "USA" for field #189, which the API describes as "Prefix Country". Should that value be used instead of the mailing country?

WA9PIE

2019-11-06 22:22

administrator   ~0009186

I had it wrong in the version of the field mapping spec you're looking at.

It later occurred to me that - if we're obtaining the country from the Country List... then it's a matter of putting the country name from the Country List as the last line in the address field.

Sorry about that. I'm attaching an in-progress version of that field mapping spec that I'm using to keep track of the "as-built" mapping. You'll see this in the yellow high-lighted HamCall.net column.

CallsignLookupMapping4x.xlsx (25,936 bytes)

K7ZCZ

2019-11-07 08:27

administrator   ~0009193



I don't think releasing a product with a specification that' described as "in-progress" is good process.

If the code is changed to match what you're asking for here, the repro case provided still won't show a country name in the address because the call sign given doesn't offer a DXCC number at this data source. Is that what's desired?

WA9PIE

2019-11-07 08:30

administrator   ~0009195

Put the country from the distilled results on the last row of the address field.

K7ZCZ

2019-11-07 10:09

administrator   ~0009197

Right now, code for each lookup source produces a set of name-value pairs. In this case, the HamCall lookup produces an "Address" name with the a value that has an address that doesn't include a country name. The country name isn't included because this source doesn't provide one. This arrangement matches the specification, where each column in the spreadsheet shows a set of mappings from source fields to logbook column fields.

Since the HamCall lookup source (like all other lookup sources) atomically produces each named value it contributes to the results, we can't readily take one named value from the distilled results and use that value to edit the existing results from another value, from another source.

The lookup code works this way so that each source standardizes its representation of the results in a way that can be readily combined, displayed to the user, and placed in a logbook database record. For that standardization, "ADDRESS" is the name of one of the values. While other values exist which might be part of the address, the "ADDRESS" value is computed by each lookup source for itself, using its locally-known fields and rules.

Changing that would require removing the "ADDRESS" field and breaking it into component parts, standardized across each component, so that something added to the distillation step could consider different values from different sources when displaying the final "ADDRESS" value to users, or preparing COL_ADDRESS for the database.

Until today, this approach was compatible with the specification. The approach is modular, isolated, readily exensible, easy to understand, and pretty flexible.

Now that it's not, we're forced to consider alternatives -- and to do so just before a shipping deadline.

My first suggestion for an alternative would be to consider different sources for the country name. First, use field #209 ("Mailing address country"), if it's available. If not, use field #189 ("Prefix Call") from this source, if it is avaialble. If not, use the DXCC country name based on looking up the DXCC entity number in field #225.

Or, maybe there should be a different order.

As this repro case shows, there are records from this data source which have neitehr #209 nor #225 populated. Since the specification says to ignore #189, the source ends up producing no country name in the address (or in the COL_COUNTRY field, or any of the related fields).

If you'd like, we could have this component side-step the Coutry List component and have the country list produce a country name based on the prefix matching logic it has. If we take this approach, should it be done unconditionally without considering any other fields? Or should it be done only if certain fields are blank? In which order?

Issue History

Date Modified Username Field Change
2019-11-06 16:25 WA9PIE New Issue
2019-11-06 16:25 WA9PIE Status new => assigned
2019-11-06 16:25 WA9PIE Assigned To => K7ZCZ
2019-11-06 16:25 WA9PIE File Added: Hamcall address field.png
2019-11-06 16:25 WA9PIE Issue generated from: 0003556
2019-11-06 16:25 WA9PIE Relationship added related to 0003556
2019-11-06 21:55 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-11-06 21:55 K7ZCZ Status assigned => feedback
2019-11-06 21:55 K7ZCZ Note Added: 0009185
2019-11-06 22:22 WA9PIE File Added: CallsignLookupMapping4x.xlsx
2019-11-06 22:22 WA9PIE Note Added: 0009186
2019-11-06 22:22 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-11-06 22:22 WA9PIE Status feedback => assigned
2019-11-06 22:22 WA9PIE Description Updated View Revisions
2019-11-06 22:22 WA9PIE Steps to Reproduce Updated View Revisions
2019-11-07 08:27 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-11-07 08:27 K7ZCZ Status assigned => feedback
2019-11-07 08:27 K7ZCZ Note Added: 0009193
2019-11-07 08:30 WA9PIE Note Added: 0009195
2019-11-07 08:31 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-11-07 08:31 WA9PIE Status feedback => assigned
2019-11-07 10:09 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-11-07 10:09 K7ZCZ Status assigned => feedback
2019-11-07 10:09 K7ZCZ Note Added: 0009197