giteaadmin/Tau.Acuvim
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
11 Commits 1 Branch 0 Tags 905 KiB
b654997fc9
Commit Graph

7 Commits

Author SHA1 Message Date
Diseri Pearson
b654997fc9 Fleet sync: Municipalities + Tariffs + TariffPeriods 
Mirror the customer-side rate hierarchy (Municipality → Tariff →
TariffPeriod) to the central DB, scoped by CustomerId.
Per-municipality rate structure is preserved exactly as customers
configure it locally — each tariff still references its municipality
and carries its own per-period TOU rates.

Backend
- New fleet entities: FleetMunicipality, FleetTariff, FleetTariffPeriod.
  Composite PKs (CustomerId, Id) like Sites/Devices so two customers'
  rate trees never collide. FleetTariff has a real FK to
  FleetMunicipality on (CustomerId, MunicipalityId); FleetTariffPeriod
  cascades from its FleetTariff parent.
- Two new push batch types: "municipalities" (full set) and "tariffs"
  (full set with periods nested inside each tariff). Push order per
  tick: sites → devices → municipalities → tariffs → measurements.
- FleetIngestService dispatches the new types. Municipalities upsert
  by (CustomerId, Id). Tariffs run inside a single transaction per
  batch: upsert the tariff row, DELETE all periods for that tariff,
  INSERT the new set — atomic period replacement matches the
  customer-side UpsertTariffRequest semantics.
- FleetPushState gains ResourceMunicipalities + ResourceTariffs
  constants so the per-resource cursor/backoff state has slots for them.
- FleetQueryService.GetCustomerDetailAsync now includes municipalities
  and tariffs (with periods, with municipality name joined client-side
  from the lookup dict). New DTOs: FleetMunicipalityViewDto,
  FleetTariffViewDto, FleetTariffPeriodViewDto.
- AdminDbContext migration AddFleetRates creates the three tables and
  their indexes/FKs.

Frontend
- Customer detail page gains a "Tariffs (N)" tab. Each tariff renders
  as a collapsible card with its municipality, active flag, effective
  window, default rate / fixed charge / VAT, and an inline period
  table (Period name, day-of-week bitmask formatted as MTWTFSS, start,
  end, rate). Empty state when no tariffs synced yet.

Verified end-to-end on the dev host
- Created "Phase23 Test City" municipality + "Domestic TOU" tariff
  with two periods (Peak weekdays 17:00-20:00 @ 3.75, Off-Peak
  weekends 00:00-23:59 @ 1.20) on the Client.
- Within one push tick (~20s) all three rows landed on Admin:
  fleet.Municipalities (1), fleet.Tariffs (1), fleet.TariffPeriods (2).
- /api/fleet/customers/{id}/detail returns the full tree with
  municipality name resolved.

Tests: 61/61 still passing.

Design doc (FLEET-DESIGN.md §11) updated — tariff sync row marked
shipped, cross-customer cost compute flagged as the natural next step.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 11:10:51 +02:00
Diseri Pearson
3333202f3a Dual-token rotation grace window (24h default) 
Token rotation used to be immediate cutover — push gap from when
ops rotates to when the customer's .env is updated and portal
restarted. Now the old token keeps working for 24h after rotation,
so customer ops has a full workday to swap it in without dropping a
single push tick.

Backend
- Customer entity gains PreviousTokenHash + PreviousTokenExpiresAt
  (both nullable). Non-unique index on PreviousTokenHash so the
  OR-lookup in FindByTokenAsync stays cheap.
- CustomerService.RotateTokenAsync(id, graceWindow=null, ct):
  copies the existing TokenHash into PreviousTokenHash with
  PreviousTokenExpiresAt = now + graceWindow (default 24h, lifted
  to CustomerService.DefaultTokenGracePeriod), then issues a new
  current token. Second rotation overwrites the previous slot —
  at most one previous token is ever honoured.
- CustomerService.FindByTokenAsync matches either current OR
  (previous AND PreviousTokenExpiresAt > now). IsActive=false
  still rejects both.
- DTO exposes PreviousTokenExpiresAt so the UI can render the
  grace window status.
- New EF migration AddPreviousTokenGraceWindow on AdminDbContext.

Frontend
- Customers table "Token" column shows an "Old token valid until …"
  orange tag with a tooltip whenever the grace window is active,
  plus the issue/rotation date as before.
- TokenShownOnceModal mentions the 24h grace window so ops knows
  they have time to update .env without urgency.
- Rotate-token popconfirm copy updated to reflect the new behavior.

Tests (+5, 61/61 passing)
- CustomerTokenGraceTests covers: create doesn't set previous;
  rotate moves current into previous slot with future expiry;
  zero grace window rejects original immediately; second rotation
  overwrites previous (original dies, first-rotation becomes the
  new previous); inactive customer rejects both current AND previous.

Verified end-to-end on the dev host
- Migration applied cleanly on the existing admin_fleet DB (existing
  DEV0001 customer got NULL previous columns, no data loss).
- Created GRACE01 → got token1.
- Rotated → got token2. PreviousTokenExpiresAt = +24h. Both token1
  and token2 push successfully (200).
- Rotated again → got token3. token1 push now returns 401 (gone).
  token2 push still 200 (now the previous). token3 push 200 (current).

Docs
- FLEET-DESIGN.md §6 rewritten — no longer "immediate cutover".
- §11 "open seams" row for this feature marked as shipped.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 10:45:31 +02:00
Diseri Pearson
59c3f949d0 Admin customer detail: "Open Grafana drilldown" button 
Wires the existing customer-drilldown dashboard JSON to the customer
detail page. Button opens ${Grafana.BaseUrl}/d/customer-drilldown
in a new tab with var-customer=<customer-id> pre-filled, kiosk mode,
light theme.

- Fetches /api/grafana/config (cached 5min, reuses the existing
  TanStack query key so GrafanaInfoCard's cache is shared).
- Button disabled with tooltip explaining when Grafana baseUrl isn't
  configured for the Admin stack (points to Settings → Grafana).
- Customer id is URI-encoded before interpolation (defence in depth —
  it's a UUID, but encodeURIComponent costs nothing).
- Dashboard UID hardcoded as 'customer-drilldown' to match the
  provisioned JSON. Renaming requires changing both together.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 10:37:48 +02:00
Diseri Pearson
aaa522058e Settings → App config: surface RunMode + FleetIngest push state 
ConfigOverviewService now reports the runtime mode and (on Client only)
the fleet-push configuration + live push-state per resource. The token
is reduced to a boolean (TokenConfigured) in the DTO — never a string —
so it cannot be accidentally serialised.

Backend
- FleetIngestInfoDto: { enabled, url, intervalSeconds, batchSize,
  batchMaxBytes, tokenConfigured }. No Token property at all.
- FleetPushStateRowDto: { resourceType, lastCursor, lastSyncedAt,
  consecutiveFailures, lastError }.
- ConfigOverviewDto gains RunMode (string), nullable FleetIngest +
  FleetPushState (null in Admin mode).
- ConfigOverviewService becomes async + injects IServiceProvider so it
  can read AppDbContext in Client mode without that DbContext being
  required (GetService returns null in Admin mode, where it's not
  registered).
- AdminConfigEndpoints awaits the async call.

Tests (+3, 56/56 passing)
- FleetIngestInfoDto has no Token property (reflection check).
- Serialised DTO never contains the literal token value (string scan).
- ConfigOverviewDto's FleetIngest + FleetPushState are nullable so
  Admin-mode payloads serialise them as absent rather than empty.

Frontend
- ConfigOverviewCard adds a Run mode row to the Application section
  (gold tag for Admin, blue for Client).
- New "Fleet push (Client → Admin)" descriptions card (enabled, token
  configured, url, interval, batch sizes) — hidden in Admin mode.
- "Push state per resource" table — resource, last cursor, last sync,
  consecutive failures (color-coded), last error.

Verified end-to-end on the dev host
- /api/admin/config-overview on the Client returns runMode=Client +
  fleetIngest={enabled,url,interval,batchSize,batchMaxBytes,tokenConfigured}
  + fleetPushState[3] rows (sites/devices/measurements, failures=0).
- The 64-char dev token (from the running Client's .env) is verified
  absent from the response body via direct string search.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 10:33:52 +02:00
Diseri Pearson
c5787a7a7f Phase 15: Admin operator surface + fleet dashboards + onboarding docs 
The Admin stack now has a usable operator UI for managing the fleet.
End-to-end verified locally: Client pushes → Admin dashboard reflects
the activity within the CA refresh window.

Backend (Admin-only)
- FleetQueryService: dashboard headline (totals, active count, today's
  measurements + kWh from the hourly_per_device CA) and per-customer
  detail (sites, devices, last 50 measurements, last 20 ingest events).
- /api/fleet/dashboard and /api/fleet/customers/{id}/detail endpoints.
- DTOs added; Program.cs wires the service + endpoints under RunMode=Admin.

Frontend
- DashboardPage now branches on RunMode — Admin renders the fleet
  headline (statistic cards + customer summary table with lag tags),
  Client keeps the existing placeholder.
- AdminCustomerDetailPage drills into one customer: descriptions card +
  tabs for Recent ingest (with rejection counts, batch sizes, time-spread
  for visible firmware-replay waves), Recent measurements, Sites, Devices.
- AdminCustomersPage rows are clickable → /admin/customers/:id (skips
  the click when target is a button/popover so action buttons still work).
- App.tsx adds the /admin/customers/:id route, RequireRole-gated.

Grafana
- grafana/dashboards-admin/fleet-overview.json — 4 stat panels (active
  customers, total, last-24h samples, today's kWh) plus 2 time series
  (per-customer active power, per-customer hourly kWh). Reads from
  fleet.hourly_per_device CA.
- grafana/dashboards-admin/customer-drilldown.json — parameterized by
  $customer (template variable querying fleet.Customers). Per-device
  active power, cumulative kWh, recent ingest events table.

Docs
- README: Phase 15 section describing the new admin UI surface +
  pointer to dashboard-admin folder.
- OPERATIONS: new "Fleet aggregator (Admin stack)" section covering
  one-time provisioning (Admin portal + Admin Grafana), end-to-end
  customer-onboarding workflow (register on Admin → drop token in
  customer .env → restart → verify in UI/SQL), common ops (rotate
  token, disable, investigate, compression stats, force CA refresh,
  decommission), and Admin-DB backup notes.
- README decommissioning note now mentions deleting from fleet.Customers
  if the customer was registered for aggregation.

Verified end-to-end
- Phase 14's Client + Admin stacks rebuilt with Phase 15 code.
- /api/fleet/dashboard returns correct totals (1 customer, 1 active,
  measurements + kWh derived from CA).
- /api/fleet/customers/{id}/detail returns sites, devices, recent
  measurements, recent ingest events.
- Ingested a fresh measurement on Client → after CA refresh, totals
  in Admin dashboard advance correctly.
- All 53 tests still passing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 10:27:55 +02:00
Diseri Pearson
2c618b776b Phase 13: RunMode flag + AdminDbContext + Customers registry 
Adds the plumbing for the fleet-aggregation feature without moving any
data yet. Same portal binary now supports two modes selected via
Application:RunMode (Client | Admin).

Backend
- New AdminDbContext (identity + branding shared via SharedSchemaConfiguration
  helper + fleet schema). AppDbContext keeps existing identity + branding +
  monitoring + rates; renamed implicitly the "Client" context. Only one is
  registered with DI per RunMode.
- IWhiteLabelStore interface implemented by both contexts so BrandingService
  works in either mode.
- Fleet entities: Customer, FleetSite, FleetDevice, FleetPowerMeasurement,
  IngestEvent (all in the new fleet schema). Migration in Migrations/Admin/.
- CustomerService: 32-byte random token, SHA-256 hash stored, plaintext
  shown once on create + rotate. Token lookup is a single O(log N) indexed
  query.
- RunModeGuards: refuses Admin without conn string; refuses Client+push
  without URL/token; refuses cross-DB pointing (Client at admin_fleet DB
  with fleet.Customers, or Admin at customer DB with monitoring.PowerMeasurements).
- Endpoint maps now branch on RunMode:
  Client → sites/measurements/rates/admin-sites/admin-rates
  Admin  → admin/customers
  Shared → auth, users, branding, grafana, admin-config, app/info, health
- /api/app/info (anonymous) returns {runMode, applicationName, version} so
  the SPA can drive nav without re-fetching auth state.

Frontend
- AppInfoProvider + useAppInfo hook fetch /api/app/info once on load.
- AdminCustomersPage with create / edit / rotate-token / delete.
- TokenShownOnceModal: shows token once, copy-to-clipboard, "I've stored
  it" confirmation gate before closing.
- AppLayout nav swaps Sites <-> Customers based on RunMode and shows a
  FLEET ADMIN tag in the header when in Admin mode.

Tests
- 11 new tests: CustomerTokenTests (5) + RunModeGuardsTests (6).
- 51/51 passing locally.

Verified
- dotnet build + dotnet test clean (zero errors, one EF1002 warning
  suppressed in Phase 11 already).
- Client mode docker rebuild: no regressions, /api/app/info returns
  Client, login works, /api/sites/ works.
- Admin mode spun up on port 8090 against a fresh admin_fleet DB:
  /api/app/info returns Admin, customer ABC0001 registered, 64-char
  token returned, list shows the row.
- Cross-DB guard: Client run against admin_fleet refuses with explicit
  "is pointed at a database that contains fleet.Customers" error.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 10:09:41 +02:00
Diseri Pearson
e17921a122 Add portal: customer-facing white-labeled monitoring stack 
New top-level portal/ project, peer to console/ and firmware/. Delivers a
.NET 10 + React 18 + TimescaleDB + Grafana stack, one container set per
customer behind Traefik. Built in 12 phases per FrontEndPrompt spec; no
changes to existing console or firmware.

Backend (src/Tau.Acuvim.Portal/):
- .NET 10 minimal API, Serilog, ASP.NET Identity (cookie auth, lockout).
- Single AppDbContext with identity / app / monitoring schemas.
- MigrateAsync + TimescaleBootstrapper (idempotent hypertable creation)
  + IdentityBootstrapper (seeded admin + branding) on startup.
- Pure CostCalculator + DB-backed RateService for tariffs (effective-dated,
  TOU periods, VAT, fixed charges, per-municipality timezone).
- BrandingService with logo upload to mounted volume.
- Time-series ingest + bucketed query services (time_bucket aggregates,
  ON CONFLICT for idempotent re-delivery).
- ConfigOverviewService with redaction-by-construction (passwords never in
  payload).
- DataProtection keys persisted to /data/keys volume for cookie survival
  across container restarts.

Frontend (frontend/):
- React 18 + TypeScript + Vite + Ant Design 5 + TanStack Query.
- BrandingProvider + ThemedRoot for live re-themed white-labelling.
- RequireAuth / RequireRole guards.
- Pages: Login, Dashboard, Dashboards (embedded Grafana), Sites (admin),
  Settings tabs (Branding / Rates / Users / Grafana / App config).

Infra:
- Dev (docker-compose.yml) and prod (docker-compose.prod.yml) compose
  files. Three services per customer; Traefik subdomain + same-origin
  /grafana path-prefix routing wired with labels.
- Grafana 11 with provisioned timescaledb datasource (uid pinned) and
  starter power-overview.json dashboard with device template variable.
- Compose project name documented as lowercase (Compose v2 requirement).

Tests (tests/Tau.Acuvim.Portal.Tests/):
- xUnit, 40 tests. Covers CostCalculator (period match, TZ, overlap,
  VAT, fixed), ConnectionStringResolver (all 4 precedence branches incl.
  Production refusal), TariffValidator, DayOfWeekFlag.
- All passing locally against .NET 10.

Docs:
- README.md (onboarding + 11 spec sections), OPERATIONS.md (per-customer
  provisioning, secret rotation, backup, troubleshooting), TESTING.md
  (manual integration scenarios, frontend test scaffolding recipe).

Production safety guards:
- Refuses to start if Authentication:DefaultAdminPassword is unchanged
  default in Production.
- Refuses to start if Database:AutoProvisionLocalTimescaleDb=true in
  Production.
- Prod Grafana ships with anonymous off and auth mode unset (three
  options documented in README Security) so iframe refuses to load
  until a deliberate prod auth choice is made.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-18 09:30:30 +02:00