100 lines
3.3 KiB
Markdown
100 lines
3.3 KiB
Markdown
# Feature 1 – Användarval
|
||
|
||
## Status
|
||
|
||
Färdig och mergad till `main`.
|
||
|
||
## Bakgrund
|
||
|
||
HemHub behövde centralt lagrade användare och ett enkelt sätt att välja vem som
|
||
använder applikationen, utan att införa autentisering.
|
||
|
||
## Mål
|
||
|
||
Göra det möjligt att lista och skapa användare, välja en aktiv användare,
|
||
återanvända valet i samma browser och lämna den aktiva vyn.
|
||
|
||
## Omfattning
|
||
|
||
- persistens, API och validering för användare;
|
||
- startflöden för tom och befintlig användarlista;
|
||
- lokalt lagrad aktiv användare;
|
||
- användarval, skapande och felhantering;
|
||
- automatiserade backend- och frontendtester.
|
||
|
||
## Avgränsningar
|
||
|
||
Ingen autentisering, lösenord, roll, behörighet, e-post, avatar,
|
||
hushållsrelation, redigering eller radering infördes.
|
||
|
||
## Beslut
|
||
|
||
Backend är slutlig auktoritet för namnvalidering. Namn normaliseras separat för
|
||
skiftlägesokänslig unikhet. Frontend lagrar endast UUID under
|
||
`hemhub.activeUserId` och verifierar det mot den hämtade användarlistan.
|
||
|
||
## Implementerad lösning
|
||
|
||
Vid appstart hämtar frontend alltid användarna. En tom lista leder direkt till
|
||
formuläret Skapa användare. Om användare finns men inget giltigt lokalt val
|
||
finns visas Vem är du?.
|
||
|
||
Val eller lyckat skapande sparar användarens id och aktiverar användaren. Ett
|
||
ogiltigt lagrat id rensas utan tekniskt fel. Feature 1:s tillfälliga startsida
|
||
och kontrollen Byt användare ersattes i Feature 2 av uppgiftsbrädan och
|
||
kontrollen Logga ut; lagringsmekanismen är oförändrad.
|
||
|
||
## API-förändringar
|
||
|
||
- `GET /api/users` returnerar alla användare.
|
||
- `POST /api/users` skapar en användare och returnerar `201 Created`.
|
||
|
||
API-responsen innehåller `id`, `name` och `createdAt`. `normalizedName` exponeras
|
||
inte.
|
||
|
||
Tomt namn eller namn längre än 50 Unicode-kodpunkter ger `400` med
|
||
`INVALID_USER_NAME`. Ett dubblettnamn utan hänsyn till stora och små bokstäver
|
||
ger `409` med `USER_NAME_ALREADY_EXISTS`.
|
||
|
||
## Databasförändringar
|
||
|
||
Flyway-migreringen `V1__create_users.sql` skapade tabellen `app_user`:
|
||
|
||
- UUID som primärnyckel;
|
||
- `name VARCHAR(50)`;
|
||
- unikt `normalized_name VARCHAR(150)`;
|
||
- `created_at TIMESTAMP WITH TIME ZONE`.
|
||
|
||
Lokalt används filbaserad H2 och i tester H2 in-memory. Backend genererar UUID
|
||
och `createdAt` med en UTC-klocka.
|
||
|
||
## Frontendförändringar
|
||
|
||
Frontend fick laddnings-, fel-, användarvals- och användarskapandevyer.
|
||
Skapandeformuläret trimmar namnet, gör en enkel längdkontroll, blockerar
|
||
dubbelsubmit och behåller inmatningen vid fel.
|
||
|
||
Nuvarande utloggning tar bort `hemhub.activeUserId`, rensar aktiv användare och
|
||
visar Vem är du? även om endast en användare finns.
|
||
|
||
## Tester och verifiering
|
||
|
||
Backendens integrationstester verifierar tom lista, skapande och listning,
|
||
trimning, ogiltiga namn, skiftlägesokänsliga dubbletter och alfabetisk
|
||
sortering.
|
||
|
||
Frontendtesterna verifierar tom lista, användarval, automatisk aktivering efter
|
||
skapande, bevarad inmatning vid fel, hämtfel med återförsök, ogiltigt lagrat id
|
||
och utloggning. API-anropen mockas.
|
||
|
||
## Kända begränsningar
|
||
|
||
Aktiv användare är ett lokalt gränssnittsval, inte säker autentisering. Valet
|
||
synkroniseras inte mellan browsers eller enheter. Användare kan inte redigeras
|
||
eller raderas.
|
||
|
||
## Relaterade commits
|
||
|
||
- `1ec7a729085d456d3185a1c74d02f99f40de0e8d` – `feat: add user selection flow`
|
||
- `050f248857a01db2dc236a0ca35982fd70dab3d6` – merge till `main`
|