QSL-Print delivers empty ADIF-File

[dg9vh]

This is for reporting bugs with the code, if this issue is regarding setting up on your local server please use the forum see readme for details

Describe the bug I want to export an adif file for using print service.

To Reproduce Steps to reproduce the behaviour:

1. Go to "Print Requested QSLs"
2. Click on "Export requested QSLs to ADIF-file"
3. Get ADIF file in Downloads
4. open ADIF file
5. see empty file only with header information

Expected behaviour The requested QSO should be in the adif file.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome 64
• Version 92.0.4515.159

Additional context The Problem is the Station Location selector. If you select "all" nothing is delivered, else if you select one profile, the adif is filled with the expected QSOs.

[dg9vh]

Addon: this also concerns CSV-output: this also only works, if a concrete profile is selected.

[AndreasK79]

@dg9vh seems like I missed something when I rewrote this part. I thought I tested with "all", but I must have forgotten. I'll see if I can figure something out.

[AndreasK79]

@dg9vh I have it mostly working now. The only problem is that the query for getting data for the csv-export never finishes without a station_id. I'm looking at the query (logbook_model -> get_qsos_for_printing:758), and can't quite figure out why these two are in the where statement:

and (CASE WHEN COL_QSL_VIA != \'\' THEN COL_QSL_VIA ELSE COL_CALL END) like CONCAT(dxcc_prefixes.call,\'%\')

Why exclude deleted dxcc's at all?

and (end is null or end > now())`

Any idea the thought behind these two?

[dg9vh]

This is for having the QSL-Cards sorted by DXCC of the Callsign or by DCXX of Manager ... so if you have a QSO with DG9VH without via-part it is sorted to Germany, if you have DG9VH with Manager K3LR it is sorted to USA. The CSV-file is usually used for creating serial letters via libre-office or similar and prints the cards sorted by DXCC of the QSL-delivery-target (callsign or manager) so you can pack each country separately for your QSL-bureau for sorting them. On ADIF-files this is not necessary, because here a second software (or webservice) is used to process the QSL-printing and this software or print-service has their own rules and processes for sorting and delivery :-)

[dg9vh]

The time-limitation in the second and-part is for getting the right DXCC for sorting for the callsign/and manager. But if I am thinking over it, I don't know what happens, if you try to print a card for a callsign with deleted DXCC... never tested it :-) This could be difficult or otherwise now should be solved by adding the new callsign to the manager field by hand in the corresponding qso.

[AndreasK79]

Thanks. I suspected it might be something like that. Now that I know the thought behind it, I'll see if I can figure out a solution.

[dg9vh]

I don't know, if the csv-part is used in the wild :-) so before wasting time there we should wait for any persons coming up with issues?

[AndreasK79]

The Adif part is solved. So at least I can make a PR for that. Csv should be possible to solve. I'll sleep on it, and see tomorrow.

[dg9vh]

:-) as long as it was working with concrete selection of profiles, it was ok for me - because I only operate actually with one profile :-) the older profiles are ready printed... but I won't stop you .-)

[magicbug]

I'd suggest we don't remove Deleted, some might want to get the card regardless, should just be a matter of exporting for the profile where QSL has been marked as requested. as this is just outputting ADIFs/CSVs the end users can use whatever software they prefer for final sorting etc.

[AndreasK79]

@magicbug well, since the query is joining on prefix to get the entity name, we must filter out deleted. If the join was on the unique dxcc id, it wouldn't be a problem. As the qsl via does only contain a callsign, I see no other way of doing this.

This only affects the csv export.

I rewrote the query a little bit. It now runs, but I need to test some more before making a PR.

[AndreasK79]

I might be able to fix it by sorting so that the line with an end date comes last, then limit the result to 1. This will avoid problems where both current and deleted dxcc have the same prefix.

[AndreasK79]

1141 was pushed to fix this. Awaiting merge.

[dg9vh]

fixed with https://github.com/magicbug/Cloudlog/pull/1141 mni tnx Andreas!

[dg9vh]

Hi, sorry @AndreasK79 I must reopen this issue: You forgot to rework the "mark printed"-function... Export is working but marking them printed still only work when selecting one profile.

[AndreasK79]

@dg9vh no problem. Thanks for testing and reporting. The same flawed logic was used in that part as well. Fixed now (when the PR gets merged).

[dg9vh]

I got the PR 😉 nw waiting for McPeter for doing a McMerge...

Andreas Kristiansen @.***> schrieb am Sa., 4. Sept. 2021, 09:50:

@dg9vh https://github.com/dg9vh no problem. Thanks for testing and reporting. The same flawed logic was used in that part as well. Fixed now (when the PR gets merged).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magicbug/Cloudlog/issues/1139#issuecomment-912929211, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKN5OWKXEQY5WSLNUNPDRLUAHFUDANCNFSM5CS3ZDYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[magicbug]

Done and done so closing :)