e9143f8c27
13 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
e9143f8c27 |
Portal: self-service My profile + secondaryColor on the sidebar
Closes the last two outstanding items from FrontEndPrompt.txt's original phase list. Frontend - New MyProfilePage at /profile, any authenticated user. Two cards: read-only email + roles + editable displayName; current/new/confirm password change with client-side AntD policy validation matching Identity's backend rules. - AppLayout: replace the inline displayName + Sign out with a Dropdown on a user-icon button. Items are "My profile" → /profile and "Sign out". Header is cleaner; logout still one click. - AppLayout: Sider now uses branding.secondaryColor with Menu theme="dark" + transparent background so the brand colour shows through. Sidebar finally reflects the secondary brand colour like the header reflects primary. - useAuth exposes setUser so a successful profile save updates the header name without a /auth/me round-trip (PUT already returns the updated CurrentUserResponse). Backend - PUT /api/auth/me — update own displayName. Email and roles stay immutable here (admin-only for role changes). Returns the updated CurrentUserResponse. - POST /api/auth/me/change-password — requires both current and new password. Wraps UserManager.ChangePasswordAsync so Identity's password policy (8+, upper, lower, digit) runs server-side and the current password is verified before any change. Curl-verified - PUT /me with new displayName → 200 with updated user. - change-password with wrong current → 400 "Incorrect password." - change-password with weak new → 400 listing each policy violation. - change-password valid + revert → 204 / 204. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
e2cbb83397 |
Portal: Client Dashboard, Measurements page, Excel exports, Grafana auth, RLS
A bundle of related portal work — picked up while ensuring per-customer
isolation actually works end-to-end and replacing the placeholder Client
landing page. Build green, full test suite 66/66.
Frontend — Client surface
- DashboardPage: replace placeholder with 4 KPI cards (kWh, current kW,
active devices, estimated cost), 24h active-power ECharts mini-chart,
per-device "today/range" table, and a date-range picker with shortcuts
(Today / 7d / 30d / This month / Custom). 30s auto-refresh.
- New Measurements page (/measurements, Client mode, any authenticated
user) with multi-select device filter, full date range incl. an
"All time" shortcut, server-paginated preview, and Excel export.
- "Export to Excel" buttons on: Client Dashboard summary, Client Dashboard
raw measurements, Admin fleet dashboard, Admin customer-detail Cost tab.
- DashboardsPage sidebar items: let the menu item grow and reset
line-height so the two-line title+description doesn't crush.
Frontend — Admin / user mgmt
- RestrictedAdmin role: admin who only sees their assigned customers.
New UserFormDrawer choice + CustomerAccessModal for granting/revoking
per-customer access; surfaced from the Users page.
Backend
- ClosedXML 0.104.2 + ExcelExportService (pure formatter; frozen header,
currency/kWh/kW/date number formats, AdjustToContents).
- DashboardSummaryService computes per-device totals + estimated cost
(hourly bucketing × site's municipality's active tariff, mirroring
FleetCostService for the Admin side).
- New endpoints:
GET /api/dashboard/summary[+/export.xlsx]
GET /api/measurements/raw[+/export.xlsx] (deviceIds, paginated)
GET /api/sites/devices (flat list w/ site name)
GET /api/fleet/dashboard/export.xlsx
GET /api/fleet/customers/{id}/cost/export.xlsx
GET /api/auth/check (cookie-only liveness)
- AdminCustomerAccess: per-user customer scoping for RestrictedAdmin via
Postgres-row-level filter — RlsContext (per-DI-scope state) +
CustomerFilterMiddleware (populates from claims after auth) +
fleet.* DbSets gain HasQueryFilter expressions. Bootstrappers
Elevate() to bypass the filter for trusted system code.
- Migration: 20260518095759_AddAdminCustomerAccess (mapping table,
composite PK on UserId+CustomerId).
Infra / templating (the "spin it up via the template" piece)
- docker-compose.prod.yml + docker-compose.yml: pass WhiteLabel__*,
Application__RunMode, FleetIngest__* through to the container as
${VAR:-default} substitutions. Previously these were silently dropped
in prod — a customer's .env settings for branding/fleet-push never
reached the running process. Latent bug, fixed.
- docker-compose.prod.yml: forwardAuth middleware labels on the
Grafana router pointing at /api/auth/check. Option (a) from the
README's three prod-auth modes — every Grafana request now gates on
a valid portal cookie. Anonymous stays off.
- .env.example rewritten with a Client section, optional FleetIngest
block, and an Admin variant block — annotated on what's required vs.
optional and where the seed-only-on-first-boot caveat applies.
- README "Grafana embedding" table: option (a) now marked active with
an inline note on how to switch modes later.
- OPERATIONS.md step 3 includes the white-label pre-brand .env snippet;
step 4 (formerly "decide Grafana auth mode") updated to reflect
that auth is wired by default.
Tests
- New BrandingSeedFromOptionsTests (5 tests) pins the env-var → IOptions
→ DB seed contract: first read seeds from options; subsequent reads
return the DB row (UI edits survive restarts); EnsureSeededAsync is
idempotent; UpdateAsync falls back to options for blanked fields.
- CustomerTokenGraceTests helper: pass the new RlsContext to
AdminDbContext (SetAll() so existing semantics hold).
Verified end-to-end
- Real Docker spin-up with WhiteLabel__* in a throwaway .env →
/api/branding returned all six fields verbatim (ApplicationName,
LogoUrl, three colors, FooterText).
- curl login → /api/dashboard/summary returned valid JSON →
/api/dashboard/summary/export.xlsx returned a 6.9 KB file the
`file` command identifies as "Microsoft Excel 2007+".
- /api/measurements/raw with and without deviceIds filter returned
correct paginated rows; /export.xlsx with filter produced a valid
7.1 KB xlsx with the meter count in the filename.
- Frontend tsc -b clean; backend dotnet build 0/0; xunit 66/66.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
|
66660364ec |
Cost-feature followups: libgssapi fix, daily CA, dashboard cost
Three small polish items on top of the cost-compute feature. (A) Dockerfile: install libgssapi-krb5-2 in the runtime stage. Silences the "Cannot load library libgssapi_krb5.so.2" warning that Npgsql logs when probing for Kerberos auth on Linux. We don't actually use Kerberos; the lib is ~3 MB and removes confusing log noise. (B) FleetTimescaleBootstrapper: add hierarchical fleet.daily_per_customer continuous aggregate on top of fleet.hourly_per_device. Per-customer daily totals (samples, kwh imported/exported, avg/max/min kW). Realtime, materialized_only=false, 365-day start_offset, hourly refresh. Available for long-range dashboards / billing summaries that don't need device-level or hourly detail. Not yet consumed by any query — exists as a primitive for the next dashboard / report that wants it. (C) Fleet dashboard: include per-customer cost today. - FleetQueryService.GetDashboardAsync invokes FleetCostService.ComputeAsync per customer for today's UTC window. Failures for one customer don't break the dashboard (leave their CostToday null and continue). - FleetCustomerSummary gains nullable CostToday; FleetDashboardDto gains TotalCostToday (sum across customers). - AdminFleetDashboardPage adds a 5th Statistic card "Cost today" in green, and a "Today (cost)" column in the customer summary table. - Perf note added in service comment: per-load cost compute scales with N customers; revisit with a materialised daily_cost view when N grows beyond ~100. Verified on the running stack - Admin container logs no longer contain "libgssapi" anywhere. - timescaledb_information.continuous_aggregates shows both hourly_per_device and daily_per_customer. - /api/fleet/dashboard returns totalCostToday=161.00, the single customer (DEV0001) row shows costToday=161.00 matching the cost endpoint's total for the same UTC day. Deliberately not in this commit: per-customer Postgres RLS for multi-Admin-user setups. That needs design decisions (claim source, fleet-admin bypass model, connection-pooling interaction with session variables) — I'd rather pose those questions and ship it right than sneak in a half-baked version. Wrap-up message has the design qs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
7627306800 |
Cross-customer cost compute on the Admin side
Per-customer cost over a UTC time range, joining the fleet hierarchy:
hourly_per_device CA × Devices × Sites × Municipalities × active Tariff
× period (in the municipality's local time) → per-bucket kWh × rate.
Per-day rollup + per-device breakdown. VAT applied per bucket so cost
stays correct across mid-window tariff changes.
Backend
- FleetCostService.ComputeAsync(customerId, fromUtc, toUtc):
- Loads device→site→municipality mapping (small per customer).
- Loads tariffs (with periods) grouped by municipality, ordered by
EffectiveFrom desc for active-tariff lookup.
- Reads hourly buckets in range from fleet.hourly_per_device via
raw ADO (the CA isn't an EF entity).
- For each bucket: pick active tariff for the bucket's date, convert
bucket start to local time via Municipality.TimeZoneId, pick the
matching period (or default rate), compute base + VAT.
- Rolls up per UTC date + per device. Tracks BucketsWithoutTariff
when site has no muni or no tariff covers the bucket date.
- New DTOs: FleetCostDto / FleetCostDayDto / FleetCostDeviceDto.
- Endpoint: GET /api/fleet/customers/{id}/cost?from&to. AdminOnly.
Validation: to > from, range <= 366 days (BadRequest on violation).
- Period-selection helper duplicated from CostCalculator (5 lines;
generic abstraction across TariffPeriod / FleetTariffPeriod is
more code than the duplication).
- Fixed monthly charges deliberately NOT applied (whole-month billing
concept; FixedMonthlyChargesIncluded=false in the response).
Frontend
- AdminCustomerDetailPage gets a Cost tab:
- RangePicker with quick ranges (Today, Last 7d, Last 30d, This
month). Default last 7 days.
- 4 Statistic cards: total kWh, base cost, VAT, total.
- Warning alerts: when buckets-without-tariff > 0; always-on info
that fixed monthly charges aren't included.
- Per-day table + per-device table.
Verified end-to-end on the running stack
- Patched DEV0001's existing site to LocalMunicipalityId=1
(Phase 23 test municipality with Domestic TOU tariff).
- Ingested 3 measurements at 10:00 / 10:20 / 10:40 UTC with kWh
totals 2000 / 2020 / 2050 → hourly CA bucket has delta = 50 kWh.
- Total kWh in window = 56 (50 from new bucket + 6 from earlier
Phase 14 backfill bucket).
- Tariff resolution: 10:00-12:00 UTC = 12:00-14:00 SAST, which is
neither Peak (17:00-20:00 weekdays) nor Off-Peak (weekends only)
→ defaults to 2.50/kWh.
- 56 × 2.50 = 140.00 base ✓
- 140 × 0.15 = 21.00 VAT ✓
- Total 161.00 ✓ exactly what the API returned.
Docs: FLEET-DESIGN.md §11 row updated — tariff sync + cost compute
both marked as shipped.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
|
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>
|
||
|
|
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> |
||
|
|
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>
|
||
|
|
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>
|
||
|
|
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>
|
||
|
|
a92b4277ae |
Phase 14: Push + ingest pipeline (end-to-end fleet aggregation)
Customer-stack measurements now flow to the Admin-stack central DB via
HTTPS POST, with firmware buffer-and-replay back-fills handled correctly.
Client side (push)
- monitoring.PowerMeasurements gains ReceivedAt (default NOW()) +
index. Push selects WHERE ReceivedAt > LastCursor, so back-dated
rows from offline-buffer replays are picked up automatically.
- app.FleetPushState table holds per-resource cursors + backoff state.
- FleetPushClient: HttpClient wrapper, X-Customer-Token header,
X-Batch-Type, X-Push-Cursor. 413 returns retry-after halving signal.
- FleetPushService: BackgroundService loop. Per tick: sites (full set),
devices (full set), measurements (cursor-driven up to 3 batches).
Exponential backoff per resource on failure (1m → 30m cap).
Honors 429 Retry-After. Only registered when RunMode=Client AND
FleetIngest__Enabled=true.
Admin side (ingest)
- /api/fleet/ingest: anonymous, X-Customer-Token authed against
fleet.Customers via SHA-256 indexed lookup. 401 on bad token; 400
on bad batch type.
- FleetIngestService dispatches by X-Batch-Type:
sites/devices → upsert by (CustomerId, Id) with ON CONFLICT UPDATE
measurements → bulk INSERT ON CONFLICT (Time, CustomerId, DeviceId)
DO NOTHING (idempotent under re-delivery).
- Updates fleet.Customers.FirstSeenAt/LastSeenAt on each successful batch.
- Writes fleet.IngestEvents audit row per batch (accepted, rejected,
bytes, client cursor, time-spread, error).
- FleetTimescaleBootstrapper runs after MigrateAsync in Admin mode:
CREATE EXTENSION timescaledb, create_hypertable on fleet.PowerMeasurements,
chunk interval 7 days, compression with segmentby=(CustomerId,DeviceId)
+ compress_orderby "Time" DESC, compression policy 7 days, hourly_per_device
continuous aggregate (realtime, materialized_only=false, 30-day start_offset
so back-fills get materialized on next refresh tick).
Wiring
- docker-compose.yml threads Application__RunMode + FleetIngest__* from
.env (defaults safely off) so a single dev host can run two stacks.
- .env.example documents the new vars under their own section.
Tests
- FleetIngestValidationTests (2 new). 53/53 passing.
Verified end-to-end on the dev host
- Client (portal-dev_portal, RunMode=Client, FleetIngest__Enabled=true)
pushes to Admin (portal-admin-test, RunMode=Admin, separate admin_fleet DB)
via container DNS.
- Customer registered on Admin (DEV0001), token captured, dropped into
Client .env, Client restarted, push service started on schedule.
- Ingested measurements (including a 2026-04-01 back-dated sample
simulating firmware replay) all land in fleet.PowerMeasurements with
the correct CustomerId.
- Customer.FirstSeenAt/LastSeenAt update, IngestEvents records every
batch (sites + devices per tick, measurements when cursor advances).
- Hypertable confirmed via timescaledb_information.hypertables;
hourly_per_device CA confirmed via timescaledb_information.continuous_aggregates.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
|
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>
|
||
|
|
880525b306 |
Add Fleet ingest design doc (portal/docs/FLEET-DESIGN.md)
Locked design for Admin / cross-customer aggregation feature. Implementation lands in phases 13-15. Key decisions captured: - Same portal binary, RunMode=Client|Admin config flag. - Two DbContext classes (ClientDbContext + AdminDbContext) to keep schemas cleanly separated and migrations sane. - Fleet ingest is opt-in (FleetIngest__Enabled=false works exactly as today, no data leaves customer stack). - Push by ReceivedAt, not Time, so firmware offline-buffer replays are picked up automatically. - Per-tick batch cap so a back-fill wave from one customer doesn't starve other customers' pushes. - SHA-256 token hash (not bcrypt) for the high-throughput ingest endpoint; tokens shown once on Admin Customers page. - Realtime continuous aggregates with wide start_offset so late back-fills materialize on the next refresh tick. - No retention policy. TimescaleDB compression on chunks older than 7 days handles long-term storage cost. - Open seams (tariff sync, RLS, GDPR delete, dual-token rotation, sharding) documented with v2 extension paths. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
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> |