First version of the "QSL Manager" that doesn't do anything useful yet.

[hugosilvaparagramanet]

Introduction

I have started work on a "QSL Manager" to help me process paper QSL for my activations (I do a lot of portable, mainly WWFF but also SOTA and HEMA, and some grids on SAT QT-100). This is not yet a MVP but it shows my approach to code and I tought that it might be useful to show to the community to gather feedback.

Look and Feel

The functionality is accessible trough the QSO menu, and consists of a large full width table with QSOs from all the stations belonging to current user, a search form with filters, and a set of buttons for bulk actions.

Only the first button, "Update from Callbook", that should go the callbook and query information about the Dx station's preferences and updates the QSO is partially working (it only reads from the callbook and updates the view, not the QSO on database)

The basic mode of operation is:

• you search for QSOs that are part of a "group" you wish to manage for QSL (out)
• you get information from the callbook about the Dx station QSL preference
• you copy your reference data to the QSL MSG field (for the automated QSL bureaus)
• you (bulk, or single) update the QSOs with the method (Bureau, Direct, etc.) and status
• you export the QSOs as ADIF for uploading (or label generation, or...)
• you are now closer to having all your pending QSLs processed

Code

Code structure departs a bit on the common CodeIgniter project. There is a controler Qslmanager that does what's expected, and some code was added to the existing models so as not break too much, but the two main classes for this domain, QSO and SearchCriteria exist inside a QSLManager namespace that is in a src/ directory working according to the PSR-4 standard. An helper was created to do the class autoloading (with an extremely simple approach) that is loaded on the controller's constructor.

Finally, a composer.json file was added to the project just to support the Unit Tests that were written, and it's not needed for running the code. The same is true for tests/ directory.

Some other small changes were made to accommodate the loading of the proper javascript libraries (and some other minor details) at the right places, on the header and the footer.

Future Plans

• Finish the half-working button, and the remaining functionality
• More testing, I'm not 100% sure the front end works across other (than Firefox Linux) browsers
• Try to refactor database code to make it more decoupled (if it's exclusive of this domain should it be on separate repository?)

Expectation

This isn't useful yet, so I don't expect it to be merged right away, but since I've taken the liberty of not coupling too much with CodeIgniter I would like to get some feedback.

[magicbug]

Hugo,

First of all this looks wonderful and needed, the decoupling isn't too much of a concern as long as things are commented properly for anyone who has to touch it in the future.

If your planning to decouple from the database then perhaps might be better to run separate guess see what happens over time?

Keep up the good work.

Peter

[hugosilvaparagramanet]

Thanks Peter, I will work a bit more and push more changes soon.

[AndreasK79]

This seems like a much needed feature for Cloudlog for handling QSL'ing. Keep up the good work, and let us know when you want us to test.