From c71345f002f6874d8ee453202886f65bb5e4ba08 Mon Sep 17 00:00:00 2001 From: Grant Date: Tue, 12 May 2026 12:42:10 -0500 Subject: [PATCH] =?UTF-8?q?v0.2.0:43=20=E2=80=94=20BTCPay=20success=20page?= =?UTF-8?q?:=20return=20to=20Keysat,=20not=20StartOS?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Connect now lives inside Keysat's admin UI, so the post-authorize return target is Keysat's own tab. One-line copy in two paths. --- licensing-service/src/api/btcpay_authorize.rs | 4 ++-- startos/versions/v0.2.0.ts | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/licensing-service/src/api/btcpay_authorize.rs b/licensing-service/src/api/btcpay_authorize.rs index fb7fd16..e245c77 100644 --- a/licensing-service/src/api/btcpay_authorize.rs +++ b/licensing-service/src/api/btcpay_authorize.rs @@ -158,7 +158,7 @@ pub async fn callback( Form(form): Form, ) -> AppResult { finish_connect(&state, &q.state, &form.api_key).await?; - Ok(success_page("BTCPay connected successfully. You can close this tab and return to StartOS.")) + Ok(success_page("BTCPay connected successfully. You can close this tab and return to Keysat.")) } /// Some BTCPay deployments send the apiKey back as a query string on a GET. @@ -190,7 +190,7 @@ pub async fn callback_get( }; match finish_connect(&state, &q.state, &api_key).await { Ok(()) => success_page( - "BTCPay connected successfully. You can close this tab and return to StartOS.", + "BTCPay connected successfully. You can close this tab and return to Keysat.", ), Err(e) => Html(format!( "

BTCPay authorization failed

{}

", diff --git a/startos/versions/v0.2.0.ts b/startos/versions/v0.2.0.ts index 3166c15..f896598 100644 --- a/startos/versions/v0.2.0.ts +++ b/startos/versions/v0.2.0.ts @@ -58,6 +58,8 @@ const RELEASE_NOTES = [ // in RELEASE_NOTES above (the milestone). Subsequent revisions // append here. const ROUTINE_NOTES = [ + '0.2.0:43 — **BTCPay authorize success page now says "return to Keysat" instead of "return to StartOS".** The success page is the lightweight HTML BTCPay redirects to after the operator clicks Authorize. With the BTCPay connect flow living inside Keysat\'s admin UI (since the :40-era admin-UI redesign), "return to StartOS" was misdirecting the operator — Keysat\'s own tab is what they came from and what they want to return to. One-line copy change in `success_page()` and the GET fallback path in `btcpay_authorize.rs`; no behavior change.', + '', '0.2.0:42 — **Revert the implicit Patron→Pro entitlement expansion shipped in :41.** Reasoning on revert: the only license affected by the missing-entitlement bug was the master operator\'s own pre-launch self-license, issued under an earlier entitlement scheme. The Patron policy on the master Keysat now lists the correct entitlements, so any fresh Patron license issued today carries them in the signed payload directly. Making `patron` a magic superset at the resolution layer was paying ongoing complexity tax (entitlement-renames have to update a hardcoded list; the gate behavior diverges from what the policy literally says) for a one-shot migration that won\'t recur. Operators with a stuck old-scheme Patron license should re-issue + run "Activate Keysat license" — the new license overwrites `/data/keysat-license.txt` and the daemon picks up the fresh entitlements without a restart. The :41 BTCPay one-click authorize-flow restoration in the admin UI is unchanged.', '', '0.2.0:41 — **Two fixes: Patron tier now implies the full Pro feature surface, and BTCPay Connect is back to one-click authorize.** Both came from operator-side bugs that the admin-UI redesign exposed.', @@ -519,7 +521,7 @@ const ROUTINE_NOTES = [ ].join('\n\n') export const v0_2_0 = VersionInfo.of({ - version: '0.2.0:42', + version: '0.2.0:43', releaseNotes: { en_US: ROUTINE_NOTES }, // No on-disk transformation needed — v0.2.0:0 is a label change. // SQLite-level migrations live separately under