Pairs with the satmachineadmin Phase 1 refactor that hoisted LP state
into `satoshimachine.dca_lp` (one row per user). This extension is now
the WRITER for that table; satmachineadmin only reads it during
distribution.
API surface:
- `GET /api/v1/dca-client/preferences` — returns the LP's
`dca_lp` row, AUTO-CREATING it with the authenticated wallet
as the default DCA destination on first call. Hitting this
endpoint is the act that marks the LP as onboarded on the
operator side (gating their deposit creation).
- `PUT /api/v1/dca-client/preferences` — LP-side update of
wallet / mode / fixed-mode limit / autoforward fields. Ensures
the row exists before applying. Replaces the old
`PUT /autoforward` endpoint (which is gone).
- `GET /api/v1/dca-client/positions` — same shape as before
but also auto-inits dca_lp on entry (so opening the dashboard
onboards the LP). Now INNER JOINs dca_lp so only onboarded
LPs see positions (matches the operator-side "must onboard
before deposits" gate).
- `GET /api/v1/dca-client/transactions` — unchanged.
Models:
- New `LpPreferences` / `UpdateLpPreferences` exposing the
dca_lp fields.
- `UpdateClientAutoforward` removed (replaced by the broader
`UpdateLpPreferences`).
- `PerMachinePosition.dca_mode` now sourced from `dca_lp` (it's
LP-wide, echoed on each position row for legacy display
compatibility).
CRUD:
- `_fetch_user_clients` rewritten: INNER JOIN dca_lp, drop
references to removed `dca_clients.wallet_id` / `.dca_mode`
columns (they don't exist anymore post-Phase-1).
- New: `get_lp_preferences`, `ensure_lp_preferences`,
`update_lp_preferences`. The first writes nothing; the second
is the get-or-create that defends the auto-onboard invariant.
- `update_lp_autoforward` removed — write path is now
`update_lp_preferences` against `dca_lp`, not the multi-row
UPDATE on `dca_clients` that used to be needed because the
state was denormalised across enrolments.
Note: the legacy static/js/index.js in this extension references
endpoints that no longer exist (`/registration-status`, `/register`,
`/dashboard/summary`, ...) — that's pre-existing tech debt from when
the LP UX was moved to ~/dev/webapp. Not regressed by this commit;
the deprecated frontend is out of scope. For now LP onboarding works
via direct API call (curl `GET /preferences` once with the LP's wallet
admin key); the webapp will own the proper UI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Updates the LP-facing client extension to work against the v2 admin schema
(per-machine dca_clients, leg_type-discriminated dca_payments, settlement
audit trail) and strips the dead v1 code paths.
Maintenance-mode framing: the richer LP UI is migrating to ~/dev/webapp.
This extension now provides a minimal stable read-mostly surface so
existing LP installs don't break against the v2 admin schema.
models.py — rewrite:
+ PerMachinePosition: LP's position at a single machine
~ ClientDashboardSummary: now aggregates across all the LP's machines
and exposes per-machine breakdown in `positions` field
~ ClientTransaction: gains machine_id + machine_npub + settlement_id;
drops transaction_type / lamassu_transaction_id (v1 fields)
~ leg_type discriminator on ClientTransaction so the LP can tell DCA,
operator-initiated balance-settle, and auto-forward legs apart
+ UpdateClientAutoforward: LPs control their own autoforward setting
- ClientDashboardSummaryAPI, ClientTransactionAPI: deleted (GTQ-only
parallel "API" models that duplicated the internal ones)
- ClientPreferences, ClientRegistrationData, UpdateClientSettings:
deleted (registration + settings are operator-controlled in v2)
crud.py — rewrite:
+ _fetch_user_clients: all dca_clients rows for the LP, joined with
dca_machines for display metadata
+ _position_for_client: per-machine aggregation helper
+ get_client_dashboard_summary: aggregates positions + sums sats/fiat
+ computes cost basis on fiat-spent (not gross deposits)
+ get_client_transactions: filters to LP-visible leg_types
(dca / settlement / autoforward); optional machine_id filter
+ update_lp_autoforward: LP self-manages autoforward across all their
machine positions
- get_client_analytics (300+ lines of date-parsing pretzels): deleted;
webapp will own analytics
- register_dca_client: deleted (admin owns registration in v2)
- update_client_dca_settings: deleted (admin owns DCA mode/limits)
- Lamassu-era status='confirmed' (now 'completed'), transaction_type
column refs, lamassu_transaction_id column refs: all gone
views_api.py — rewrite to 3 endpoints:
GET /api/v1/dca-client/positions (aggregated dashboard)
GET /api/v1/dca-client/transactions (filterable history)
PUT /api/v1/dca-client/autoforward (LP self-manages forwarding)
All require_admin_key on the LP's wallet. Old registration / settings
/ analytics endpoints removed.
Files deleted:
tasks.py — empty stub ("No background tasks needed")
transaction_processor.py — empty stub ("No transaction processing")
README.md gains a status banner pointing LP audience at webapp.
.gitignore gains `data/` + sqlite db files + __pycache__ to prevent
LNbits runtime artifacts (auth keys, dev DBs) from being committed.
4 routes registered. Zero ruff errors across the extension.
Refs: aiolabs/satmachineadmin#9 — completes P7
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Refactor DCA Admin page endpoints: Update description, remove unused CRUD operations and API endpoints related to MyExtension, and streamline the code for improved clarity and functionality.
Remove QR Code dialog from MyExtension index.html: streamline the UI by eliminating unused dialog components, enhancing code clarity and maintainability.
