fix(hamlog): stop offering an upload that cannot succeed

HAMLOG.online no longer issues API keys, and its upload API takes
nothing else. An operator without a key cannot obtain one, so the
auto-upload switch, the on-close sweep and the 'Send to' entry were all
arming something that could only fail — silently, once per QSO.

Closed at the source rather than hidden in the UI: the upload returns a
sentinel that says why, the manager stops routing to it and says so once
a session, and the manual path refuses with the same words. The settings
page states it plainly instead of showing a switch that does nothing.

Nothing else goes. Their confirmations arrive as an ADIF FILE and never
needed a key, so that import stays; the sent/received state already in
operators' logs stays readable, filterable and bulk-editable; and the
upload itself is kept whole as uploadHamlogLive, still covered by its
request-shape tests, against the day keys come back.
This commit is contained in:
2026-09-03 22:28:32 +02:00
parent 96b5f2d91f
commit 6cbe29fef1
8 changed files with 69 additions and 29 deletions
+9 -5
View File
@@ -6422,11 +6422,15 @@ function SettingsModalImpl({ onClose, onSaved, initialSection, onMainPaneChanged
</div>
<div className="border-t border-border/60 pt-3 space-y-3">
<label className="flex items-center gap-2 text-sm cursor-pointer">
<Checkbox
checked={hamlog.auto_upload}
onCheckedChange={(c) => setHamlog({ auto_upload: !!c })}
/>
{/* The site stopped issuing API keys and its upload API takes
nothing else, so an auto-upload switch here would arm something
that can only fail. Their confirmations still arrive as a file,
which never needed a key. */}
<p className="text-xs rounded-md border border-warning/40 bg-warning/10 px-2 py-1.5 text-warning-muted-foreground">
{t('es.hamlogClosed')}
</p>
<label className="flex items-center gap-2 text-sm cursor-not-allowed opacity-50">
<Checkbox checked={false} disabled />
{t('es.autoUpload')}
</label>