[finlstrm]

Add api/get_contacts_adif endpoint for incremental ADIF export

Summary

Adds POST /api/get_contacts_adif, which lets an API client download the QSOs of one station location as ADIF using a QSO-ID cursor, so new contacts can be synced without re-downloading the whole logbook.

POST /index.php/api/get_contacts_adif
Content-Type: application/json

{"key": "YOUR_API_KEY", "station_id": 1, "fetchfromid": 0, "limit": 5000}

The response includes exported_qsos, lastfetchedid (pass it as fetchfromid next time), has_more and the adif string. limit defaults to 5000, maximum 10000.

Security

• Uses the existing API key model: active key, r or rw rights, with an owning user.
• station_id must be a station location owned by the key's user. The SQL is scoped by station and owner, so changing the ID or cursor can't reach another user's data. Nonexistent and unauthorized stations return the same 403.
• Strict JSON and integer validation, and responses are always pure JSON.

Changes

• Api.php: new get_contacts_adif() method.
• Adif_data.php: new scoped query.
• AdifHelper.php: new getAdifHeader().
• New Adif_export_request.php for request validation.
• New docs: docs/api_get_contacts_adif.md.

No schema changes or migrations, and no existing endpoints are modified.

Tests

No unit tests have been included or written.
Active testing live against my own Cloudlog installation at v2.8.19 with no errors.

Inspiration

Developing my own unofficial desktop companion to Cloudlog, kc1mjp/cloudlog-desktop, I wanted to pull down my logbooks from Cloudlog via the API. Among other things, this allows an operator to see worked-before information using an offline local QSO cache. This would be great for the POTA/SOTA operator.

Other than the clunky method I was already using the Backup function of Cloudlog kc1mjp-tools/cloudlogBackup.sh and requires server-side cleanup of backups, I discovered there was still no proper API endpoint pulling down QSOs.

What I did find was Wavelog had implemented just the endpoint I was looking for, but I've already standardized on Cloudlog. So to scratch another itch, I implemented it here for Cloudlog.

Limitations

The cursor only detects newly added QSOs, not edits or deletions, though re-download of entire logbook is supported. Stations shared through a shared logbook are not exportable.

[magicbug]

Thanks for taking the time to put this together, but I've got a few concerns before I'd consider merging it.

1. What it's actually for. The description says this lets clients sync logbooks to a local cache, but what's here is an endpoint that exports a station's QSOs as ADIF. There's no cache in the PR, and no client that uses it. Can you explain the real use case and which client (or clients) you're building this for? If it's for Wavelog compatibility, please say so.
2. It only syncs new QSOs. Paging from a QSO ID cursor (fetchfromid) only picks up QSOs added after that ID. Edits (QSL status, corrections, LoTW/eQSL confirmations) and deletes never come through, so any "local cache" built on it will drift out of date. Proper sync would need something like a modified timestamp plus a way to report deletions.
3. Wrong base branch. All PRs need to target dev, not master. master is only updated at release time.
4. Maintainer edits are turned off, so I can't retarget or tidy this up myself. Please enable "Allow edits by maintainers".
5. Tests. The docs refer to unit tests in tests/unit, but the PR doesn't include any. Either add them or take that out of the docs.
6. Checks. CI isn't green on this yet, so that needs sorting.
7. New public API. Every endpoint we add is something we have to support long term, so I'd rather agree the design in an issue or discussion first than review a finished PR.

If you can open a discussion with the use case, rebase onto dev and turn on maintainer edits, I'm happy to take another look.

73, Peter

[finlstrm]

This should have been saved as draft, not submitted. I'll finish up the PR and your concerns.

[finlstrm]

1 & 2. Think I covered this in the updated description. As far as wavelog, wasn't initially for wavelog compatibility, but did end up being similar to their API endpoint of the same name.
3. Moved PR to dev.
4. This took a deep dive as the setting is not visible to me. I found this setting is conditional, "collaboration by allowing repository maintainers to commit changes to pull request branches created from forks in your personal account". This PR was submitted via a branch owned by my organization 'kc1mjp', so I cannot enable it. If you'd like, I can close this PR and re-fork directly under my personal account where I can enable that option.
5. Removed.
6. Workflow is awaiting approval.
7. Opened-> #3484

[magicbug]

Thanks for sorting those so quickly, and for the background on cloudlog-desktop.

Yes please, if you don't mind re-forking under your personal account and opening a fresh PR against dev with "Allow edits by maintainers" ticked, that would be great. It means I can push small tweaks myself rather than going back and forth. Feel free to close this one once the new PR is up, and link it here so it's easy to follow.

73, Peter

[finlstrm]

Closing this PR, continuing in #3485 with "edits by maintainers" enabled.