450 lines
22 KiB
Markdown
450 lines
22 KiB
Markdown
# Senaste ändringar (2026-04-24)
|
||
|
||
**Arkitektur- och UX-förbättringar:**
|
||
- Grid-vy för recept: Kolumnval (2/4/6/8) via ikon i AppShell, med Riverpod-provider och SharedPreferences.
|
||
- RecipesScreen är nu body-only, ingen egen Scaffold/AppBar.
|
||
- AppShell visar grid-ikon endast på /recipes.
|
||
- Buggfix: Produktväljaren i pantry/inventarie (ProductPickerField) — bottenark implementeras.
|
||
- Sprint 2: Databas > Produkter visar nu en riktig adminpanel i profilflödet med sök, okategoriserat-filter och bulk-kategorisering.
|
||
- Sprint 2: Användare-fliken stödjer nu Premium av/på direkt från användarmenyn.
|
||
- Kodkvalitet: Inga absoluta Windows-sökvägar.
|
||
- Dokumentation och next_steps uppdaterade.
|
||
# Nästa steg: Flutter-migrering
|
||
|
||
Relaterade dokument:
|
||
- [README.md](README.md)
|
||
- [teknisk_beskrivning_flutter.md](teknisk_beskrivning_flutter.md)
|
||
|
||
## Mål och prioriteringar för produktion
|
||
|
||
### Övergripande mål
|
||
- **Funktionell parity:** Säkerställa att alla kärnfunktioner är stabila och fungerar som förväntat.
|
||
- **Användarupplevelse:** Förenkla onboarding och säkerställa att användare snabbt förstår appens värde.
|
||
- **Produktionsklar:** Säkerställa att appen är redo för lansering genom att adressera kritiska buggar och förbättra prestanda.
|
||
|
||
### Icke-förhandlingsbara ramar
|
||
|
||
1. Inget ska tas bort eller ändras i `recipe-api` utom explicit beslutade backend-ändringar för användarscope i pantry och matplan.
|
||
2. Inget ska tas bort eller ändras i `recipe-frontend`.
|
||
3. Migreringen sker i Flutter-spåret som separat klient mot befintliga API-kontrakt.
|
||
4. Next-frontend körs parallellt tills Flutter har verifierad parity i kärnflöden.
|
||
|
||
## Arbetsplan
|
||
|
||
### Pågående arbete
|
||
- **Kvittoimport (Fas 6b):** ✅ Klar (2026-05-01) — Granskning, redigering, val av destination (inventarie/baslager), merge och spara implementerat.
|
||
- **Kvittoimport (Fas 6c):** ✅ Klar (2026-05-01) — Separering av AI-chip och produktsuggestions-chip, produktnamns-normalisering, och validering av AI-kategorier.
|
||
- **Bildimport:** Säkerställa att containrar är uppdaterade med senaste kod och att diagnostikloggar syns vid felsökning.
|
||
- **Adminfunktioner:** Avancerad AI-integration och ytterligare adminfunktioner planeras men är ej migrerade.
|
||
|
||
### Prioriterade nästa steg
|
||
1. Säkerställa robust bildimport och diagnostik.
|
||
2. Implementera avancerad AI-integration för produktkategorisering.
|
||
3. Utöka adminfunktioner för användarhantering och produktadministration.
|
||
4. Förbättra UI/UX för användarflöden, inklusive onboarding och profilhantering.
|
||
|
||
## Beslut 2026-04-22 - User-scope för pantry och matplan
|
||
|
||
- Pantry och matplan ska vara per användare, inte globala.
|
||
- Detta kräver backend-ändringar i `recipe-api` innan Flutter kan nå full parity för dessa flöden.
|
||
- Flutter ska följa de nya kontrakten när de finns på plats, utan klientspecifik speciallogik.
|
||
|
||
## Malbild för v1 (funktionell parity)
|
||
|
||
För v1 ska dessa flöden vara stabila i Flutter:
|
||
- [x] Auth: login, session, logout, auth-guard.
|
||
- [x] Recept: lista, detalj, skapa, uppdatera, ta bort.
|
||
- [x] Inventarie: lista, skapa, uppdatera, konsumera, historik.
|
||
- [x] Matplan: veckovy, val av recept per dag, portionsjustering, inköpslista, inventariejämförelse.
|
||
- [x] Import: quick-import + parse-markdown-flöde.
|
||
- [x] Produktadmin: lista, sök, sortera, filtrera, AI-kategorisering, merge, restore, inline kategori.
|
||
- [x] Användaradmin: lista, premium, e-post, skapa, ta bort, återställ lösenord.
|
||
|
||
## Arbetsordning för produktion
|
||
|
||
### Fas 1: Kritiska funktioner och buggfixar
|
||
- **Mål:** Säkerställa att alla kärnfunktioner är stabila och buggfria.
|
||
|
||
- **Åtgärder:**
|
||
- [x] **Kvittoimport (OCR, bulk-spara) — KLAR 2026-05-01:**
|
||
- [x] Granskningssteg med checkbox, redigering och destination-väljare.
|
||
- [x] Bulk-spara till inventarie (ny/merge) eller baslager (ny/hoppa-över).
|
||
- [x] `file_picker: ^8.0.0` integrerat för filval på Flutter Web.
|
||
|
||
- [ ] **UI/UX-förbättringar för adminpaneler:**
|
||
- [ ] Lägg till tydlig placeholder-text i sökfältet.
|
||
- [ ] Gör filtreringsalternativen mer visuellt tydliga.
|
||
- [ ] Lägg till bekräftelsedialog för bulk-åtgärder.
|
||
- [ ] Förbättra laddningsindikatorn för AI-kategorisering.
|
||
|
||
- [ ] **Receptvy:**
|
||
- [ ] Lägg till tydlig växlingsknapp för grid- och listvy.
|
||
- [ ] Implementera sorteringsalternativ.
|
||
- [ ] Förbättra det tomma tillståndet med en tydlig CTA.
|
||
|
||
- [ ] **Receptdetaljvy:**
|
||
- [ ] Lägg till stöd för att visa receptbilder i större format.
|
||
- [ ] Gör ingredienslistan mer läsbar.
|
||
|
||
- [ ] **Gemensamma UI-komponenter:**
|
||
- [ ] Förbättra felmeddelanden med tydliga instruktioner.
|
||
- [ ] Använd en visuellt tilltalande laddningsindikator.
|
||
|
||
- [ ] **Allmänt:**
|
||
- [ ] Säkerställa tillgänglighet med tydliga `tooltip`-texter och tillräcklig kontrast.
|
||
- [ ] Lägg till bekräftelsemeddelanden efter åtgärder.
|
||
|
||
### Fas 2: Förbättra konverteringsvägen och onboarding
|
||
- **Mål:** Säkerställa att användare snabbt får värde och förstår appens fördelar.
|
||
|
||
- **Åtgärder:**
|
||
- **CTA (Call-to-Action):**
|
||
- [ ] Skapa tydliga och lockande CTAs som "Se vad du kan laga med det du har hemma."
|
||
- [ ] Placera CTAs strategiskt i appen för att maximera synlighet.
|
||
|
||
- **Förenkla onboarding:**
|
||
- [ ] Implementera en gästinloggning eller demo-läge så att användare kan prova appen utan att registrera sig direkt.
|
||
- [ ] Minska antalet obligatoriska fält vid registrering och implementera sociala inloggningar (t.ex. Google, Facebook).
|
||
- [ ] Skapa en kort välkomstguide för nya användare som visar de viktigaste funktionerna.
|
||
- [ ] Använd pop-up-tips eller tooltips för att visa hur man använder olika funktioner.
|
||
|
||
- **Snabb start med exempeldata:**
|
||
- [ ] Låt användare börja med förifyllt exempeldata, t.ex. en standardinköpslista eller vanliga ingredienser.
|
||
- [ ] Lägg till en "Snabbstart"-knapp som automatiskt fyller i exempeldata och visar receptförslag.
|
||
|
||
- **Fokusera på "Aha!"-momentet:**
|
||
- [ ] Visa omedelbara receptförslag när användaren lägger till sina första ingredienser.
|
||
- [ ] Generera en automatisk inköpslista baserad på de recept användaren väljer.
|
||
|
||
- **Tydliga instruktioner och feedback:**
|
||
- [ ] Visa tydliga instruktioner för varje steg i onboarding-processen.
|
||
- [ ] Ge omedelbar feedback när användaren utfört en åtgärd.
|
||
|
||
- **Användarvänlig design:**
|
||
- [ ] Håll gränssnittet enkelt och fokuserat på kärnfunktioner.
|
||
- [ ] Visa endast de viktigaste funktionerna för nya användare.
|
||
|
||
- **Möjlighet att hoppa över onboarding:**
|
||
- [ ] Lägg till en knapp som låter användare hoppa över onboarding och börja använda appen direkt.
|
||
|
||
### Fas 3: Testa och iterera
|
||
- **Mål:** Identifiera friktion och förbättra konverteringsvägen.
|
||
|
||
- **Åtgärder:**
|
||
- [ ] Gå igenom appen som en ny användare för att identifiera eventuella problem.
|
||
- [ ] A/B-testa olika CTAs och onboarding-flöden för att se vad som fungerar bäst.
|
||
- [ ] Implementera analytik för att spåra var användare hoppar av och varför.
|
||
|
||
### Fas 4: Anpassa till målgruppen
|
||
- **Mål:** Se till att marknadsföring och CTAs talar direkt till målgruppen.
|
||
|
||
- **Åtgärder:**
|
||
- [ ] Anpassa marknadsföring och CTAs till målgruppen (t.ex. familjer, matintresserade, meal preppers).
|
||
- [ ] Var tydlig med appens värdeproposition, t.ex. "Slipp slösa mat – vi visar vad du kan laga med det du har hemma."
|
||
|
||
### 3. Avancerade adminfunktioner
|
||
- [ ] Implementera "Visa endast ändrade rader" i produktadmin.
|
||
- [ ] Säkerställa att AI-integration för kategorisering är robust.
|
||
|
||
### 4. Dokumentation och testning
|
||
- [ ] Uppdatera `README.md` med senaste ändringar.
|
||
- [ ] Lägg till testfall för nya funktioner.
|
||
- [ ] Validera med `flutter analyze` och fixa eventuella varningar.
|
||
|
||
### 5. Övrigt
|
||
- [ ] Säkerställa att alla containrar är uppdaterade för robust bildhantering.
|
||
|
||
## Prioriterad plan (ordning)
|
||
|
||
## Fas 0 - Backend-förarbete för user-scope (KLAR 2026-04-22)
|
||
- [x] Gör `PantryItem` user-scopad (userId + productId unik per användare).
|
||
- [x] Gör matplan user-scopad och filtrera list/upsert/delete per inloggad användare.
|
||
- [x] Uppdatera matplanens inventory-jämförelse till användarspecifikt pantry.
|
||
- [x] Publicera uppdaterade API-kontrakt innan vidare Flutter-parity för matplan/baslager.
|
||
- [x] Migration 20260422130000_user_scope_pantry_meal_plan applicerad.
|
||
|
||
## Fas 1 - Stabil app-shell (KLAR 2026-04-22)
|
||
- [x] Bygg tydlig auth-gate i router.
|
||
- [x] Centralisera API-fel (401/403/500) i ett gemensamt lager (`mapErrorToUserMessage`).
|
||
- [x] Skapa gemensamma UI-komponenter för loading, empty, error.
|
||
- [x] Sätt en enhetlig navigationsstruktur (web först, mobil-redo).
|
||
- [x] Lokalisering: ARB-infrastruktur på plats (`flutter_localizations`, `l10n.yaml`, `app_sv.arb`, `synthetic-package: false`, `flutter gen-l10n` i Dockerfile).
|
||
- [x] Regressionstest för svenska strängkvalitet tillagd.
|
||
|
||
## Fas 2 - Auth parity (KLAR 2026-04-22)
|
||
- [x] Hårdna loginflödet (tydliga felmeddelanden, retries där relevant).
|
||
- [x] Verifiera token-livscykel (reload/hard refresh/logout).
|
||
- [x] Implementera automatisk hantering av utgången token (401 -> logout -> login).
|
||
|
||
## Fas 3 - Recept parity (KLAR 2026-04-22)
|
||
- [x] Lista -> detalj -> skapa -> redigera -> ta bort.
|
||
- [x] Knyt ihop med parse-markdown-proxy.
|
||
- [x] Behåll backend som enda plats för matchning, validering och affärslogik.
|
||
|
||
## Fas 4 - Inventarie parity (KLAR 2026-04-22)
|
||
- [x] Lista med filter/sortering (plats + sort via Riverpod-querystate).
|
||
- [x] Skapa och uppdatera inventariepost.
|
||
- [x] Konsumtion och konsumtionshistorik.
|
||
|
||
## Fas 5 - Matplan parity (KLAR 2026-04-22)
|
||
- [x] Veckovy med receptval per dag mot user-scopat `GET /api/meal-plan?from=&to=`.
|
||
- [x] Portionsjustering per dag.
|
||
- [x] Inköpslista och inventariejämförelse mot användarens pantry.
|
||
|
||
## Fas 6 - Import parity
|
||
|
||
### 6a — Recept-import
|
||
- [x] URL via JSON-body `{ input: string }`.
|
||
- [x] Svar: `{ markdown: string, source: 'ica'|'pdf'|'image'|'other', imageUrl?: string }`.
|
||
- [x] På lyckat resultat: navigera till `/recipes/create` med markdown-texten förifylld.
|
||
|
||
### 6b — Kvittoimport (KLAR 2026-05-01)
|
||
- [x] Endpoint: `POST /api/receipt-import`
|
||
- [x] Läge: filuppladdning, `multipart/form-data`, fält `file`, max 15 MB.
|
||
- [x] Svar: `ParsedReceiptItem[]` med fälten `rawName`, `quantity`, `unit`, `suggestedProductId?`, `suggestedProductName?`, `categorySuggestion?`.
|
||
- [x] Granskningssteg: checkboxlista med per-rad redigering (produkt, antal, enhet, destination).
|
||
- [x] Destination per rad: **Inventarie** eller **Baslager** via SegmentedButton i redigeringsdialogen.
|
||
- [x] Inventarie: ny post skapas, eller befintlig post slås ihop (PATCH quantity) med merge-förhandsvisning.
|
||
- [x] Baslager: produkt läggs till om den inte redan finns, annars hoppas den över.
|
||
- [x] AI-kategorisuggestion visas som chip (grön, `AI: kategori`) för premium-användare.
|
||
- [x] Snackbar med separat räkning: skapade/sammanslagna i inventarie + tillagda/redan-i-baslager.
|
||
|
||
## UI/UX-förbättringar (KLAR 2026-04-22)
|
||
- [x] Produktval med bottenark (ProductPickerField) i inventarie/pantry.
|
||
- [x] Swipe-för-±1 på inventarielistan (SwipeableInventoryTile med visuell ledtråd).
|
||
|
||
## Prioriterad plan (ordning)
|
||
|
||
## Fas 0 - Backend-forarbete for user-scope (KLAR 2026-04-22)
|
||
- [x] Gor `PantryItem` user-scopad (userId + productId unik per anvandare).
|
||
- [x] Gor matplan user-scopad och filtrera list/upsert/delete per inloggad anvandare.
|
||
- [x] Uppdatera matplanens inventory-jamforelse till anvandarspecifikt pantry.
|
||
- [x] Publicera uppdaterade API-kontrakt innan vidare Flutter-parity for matplan/baslager.
|
||
- [x] Migration 20260422130000_user_scope_pantry_meal_plan applicerad.
|
||
|
||
## Fas 1 - Stabil app-shell (KLAR 2026-04-22)
|
||
- [x] Bygg tydlig auth-gate i router.
|
||
- [x] Centralisera API-fel (401/403/500) i ett gemensamt lager (`mapErrorToUserMessage`).
|
||
- [x] Skapa gemensamma UI-komponenter for loading, empty, error.
|
||
- [x] Satt en enhetlig navigationsstruktur (web forst, mobil-redo).
|
||
- [x] Lokalisering: ARB-infrastruktur pa plats (`flutter_localizations`, `l10n.yaml`, `app_sv.arb`, `synthetic-package: false`, `flutter gen-l10n` i Dockerfile).
|
||
- [x] Regressionstest for svenska strangkvalitet tillagd.
|
||
|
||
## Fas 2 - Auth parity (KLAR 2026-04-22)
|
||
- [x] Hardna loginflodet (tydliga felmeddelanden, retries dar relevant).
|
||
- [x] Verifiera token-livscykel (reload/hard refresh/logout).
|
||
- [x] Implementera automatisk hantering av utgangen token (401 -> logout -> login).
|
||
|
||
## Fas 3 - Recept parity (KLAR 2026-04-22)
|
||
- [x] Lista -> detalj -> skapa -> redigera -> ta bort.
|
||
- [x] Knyt ihop med parse-markdown-proxy.
|
||
- [x] Behall backend som enda plats for matchning, validering och affarslogik.
|
||
|
||
## Fas 4 - Inventarie parity (KLAR 2026-04-22)
|
||
- [x] Lista med filter/sortering (plats + sort via Riverpod-querystate).
|
||
- [x] Skapa och uppdatera inventariepost.
|
||
- [x] Konsumtion och konsumtionshistorik.
|
||
|
||
## Fas 5 - Matplan parity (KLAR 2026-04-22)
|
||
- [x] Veckovy med receptval per dag mot user-scopat `GET /api/meal-plan?from=&to=`.
|
||
- [x] Portionsjustering per dag.
|
||
- [x] Inkoplista och inventariejamforelse mot anvandarens pantry.
|
||
|
||
## UI/UX-förbättringar (KLAR 2026-04-22)
|
||
- [x] Produktval med bottenark (ProductPickerField) i inventarie/pantry.
|
||
- [x] Swipe-för-±1 på inventarielistan (SwipeableInventoryTile med visuell ledtråd).
|
||
|
||
## Fas 6 - Import parity
|
||
|
||
### Analys (2026-04-22)
|
||
|
||
#### 6a — Recept-import
|
||
(2) URL via JSON-body `{ input: string }`.
|
||
- Svar: `{ markdown: string, source: 'ica'|'pdf'|'image'|'other', imageUrl?: string }`.
|
||
- På lyckat resultat: navigera till `/recipes/create` med markdown-texten förifylld.
|
||
|
||
- Endpoint: `POST /api/receipt-import`
|
||
- Läge: filuppladdning, `multipart/form-data`, fält `file`, max 15 MB,
|
||
- Svar: `ParsedReceiptItem[]` med fälten `rawName`, `quantity`, `unit`,
|
||
`suggestedProductId?`, `suggestedProductName?`, `categorySuggestion?`.
|
||
- På lyckat resultat: granskningssteg där användaren bekräftar/skippar rader
|
||
- Komplexitetsgrad: hög — granskningsvyn är det tyngsta steget.
|
||
|
||
**Nytt paket som krävs:**
|
||
- `file_picker: ^8.0.0` — hanterar filval på Flutter web (ger `Uint8List bytes`,
|
||
ingen filsökväg). Läggs till i `pubspec.yaml`.
|
||
|
||
**Fil-/mappstruktur:**
|
||
```
|
||
flutter/lib/features/import/
|
||
domain/
|
||
quick_import_result.dart # { markdown, source, imageUrl? }
|
||
parsed_receipt_item.dart # { rawName, quantity, unit, ... }
|
||
data/
|
||
import_repository.dart # API-anrop (multipart + JSON URL-läge)
|
||
import_providers.dart # Riverpod-providers
|
||
presentation/
|
||
import_screen.dart # TabBar: "Recept" | "Kvitto"
|
||
recipe_import_tab.dart # Fas 6a — fil + URL, laddningsindikator
|
||
|
||
**Router och shell:**
|
||
- Ny route `/import` inuti `ShellRoute` i `app_router.dart`.
|
||
placeras efter "Baslager" och innan "Profil".
|
||
- Multipart-uppladdning kan ta 5–30 s (OCR, LLM) — `LinearProgressIndicator`
|
||
med text "Tolkar…" under hela anropet, inte en vanlig spinner.
|
||
- Timeout via `http`-klienten: sätt `Duration(seconds: 120)` för import-anrop.
|
||
- Nätverks- och serverfel mappas via befintlig `mapErrorToUserMessage`.
|
||
|
||
**Genomförandeordning:**
|
||
1. Lägg till `file_picker` i `pubspec.yaml`.
|
||
2. Utöka `CreateRecipeScreen` med `initialMarkdown`-parameter + GoRouter extra-stöd.
|
||
3. Bygg `domain/` + `data/` (modeller, repository, providers).
|
||
4. Bygg `recipe_import_tab.dart` (fas 6a — enklare).
|
||
- [x] Registrera `/import` i router och lägg till nav-destination i AppShell.
|
||
- [ ] Verifiera recept-import end-to-end (fil + URL → create-screen).
|
||
- [ ] Bygg `presentation/receipt_import_tab.dart` (uppladdning + granskningssteg).
|
||
- Adminfunktioner migreras sist for att minimera risk i karnfloden.
|
||
|
||
1. Verifiera request/response mot befintligt backendkontrakt.
|
||
3. Kontrollera felbanor innan UI-polish.
|
||
|
||
Ingen ad-hoc backendforandring goras for att "fa Flutter att funka".
|
||
Backend-andringar for user-scope i pantry/matplan ar explicit beslutade och ska goras kontrollerat forst.
|
||
|
||
## Kvalitetsgrind (Definition of Done)
|
||
|
||
En feature ar klar nar allt nedan ar uppfyllt:
|
||
2. Auth/rollskydd fungerar (inklusive 401/403).
|
||
3. Loading/empty/error ar konsekvent hanterat.
|
||
4. Navigation in/ut ur feature fungerar utan specialfall.
|
||
5. Smoke-test i testmiljo ar godkant.
|
||
|
||
## Leveransmodell
|
||
|
||
- Leverera 1 feature i taget till testdoman.
|
||
- Demo och snabb feedback innan nasta feature.
|
||
- Hall dubbel drift (Next + Flutter) tills karnfloden ar stabila.
|
||
- Flytta trafik gradvis nar parity ar verifierad.
|
||
|
||
|
||
## Nästa konkreta sprint (rekommenderad)
|
||
|
||
1. Fas 6: Import parity (URL/PDF/bild, robust felhantering).
|
||
2. Fas 7: Profil/admin parity.
|
||
3. Fortsatt flytt av UI-strängar till ARB (inventarie, pantry, recept).
|
||
4. Smoke-test på testdomän och avstämning.
|
||
|
||
## Tumregel
|
||
|
||
- Sikta pa funktionell parity forst.
|
||
- Pixel-perfect parity tas efter stabil funktion.
|
||
|
||
## Utförda förbättringar och nästa steg (2026-04-24)
|
||
|
||
- Navigationslänkar har lagts till mellan recept, inventarie, baslager och matplan för att förenkla användarflödet.
|
||
- Efter redigering av recept och konsumtion av inventariepost sker nu automatisk navigering till relevant vy.
|
||
- Efter import av recept sker automatisk navigering till receptlistan.
|
||
- Receptdetaljvyn har fått förbättrad bakgrundsbildshantering och mjukare scrollning.
|
||
- Kodbasen har granskats för att säkerställa att inga absoluta Windows-sökvägar används.
|
||
|
||
**Nästa steg:**
|
||
- Fortsatt användartestning av nya navigationsflöden och insamling av feedback.
|
||
- Finslipa UI och tillgänglighet i samband med de nya navigationsmöjligheterna.
|
||
- Färdigställ kvittoimport och adminfunktioner enligt plan.
|
||
- Lägg till snabbfilter i Produkt-admin: "Visa endast ändrade rader" för inline-kategoribyten (planerad förbättring till nästa pass).
|
||
|
||
# Nästa steg: Flutter-migrering
|
||
|
||
Relaterade dokument:
|
||
- [README.md](README.md)
|
||
- [teknisk_beskrivning_flutter.md](teknisk_beskrivning_flutter.md)
|
||
|
||
## Mål och prioriteringar för produktion
|
||
|
||
### Övergripande mål
|
||
- **Funktionell parity:** Säkerställa att alla kärnfunktioner är stabila och fungerar som förväntat.
|
||
- **Användarupplevelse:** Förenkla onboarding och säkerställa att användare snabbt förstår appens värde.
|
||
- **Produktionsklar:** Säkerställa att appen är redo för lansering genom att adressera kritiska buggar och förbättra prestanda.
|
||
|
||
### Icke-förhandlingsbara ramar
|
||
|
||
1. Inget ska tas bort eller ändras i `recipe-api` utom explicit beslutade backend-ändringar för användarscope i pantry och matplan.
|
||
2. Inget ska tas bort eller ändras i `recipe-frontend`.
|
||
3. Migreringen sker i Flutter-spåret som separat klient mot befintliga API-kontrakt.
|
||
4. Next-frontend körs parallellt tills Flutter har verifierad parity i kärnflöden.
|
||
|
||
## Arbetsplan
|
||
|
||
### Pågående arbete
|
||
- **Kvittoimport (Fas 6b):** ✅ Klar (2026-05-01) — granskningssteg, destination-väljare, merge och spara klart.
|
||
- **Bildimport:** Säkerställa att containrar är uppdaterade med senaste kod och att diagnostikloggar syns vid felsökning.
|
||
- **Adminfunktioner:** Avancerad AI-integration och ytterligare adminfunktioner planeras men är ej migrerade.
|
||
|
||
### Prioriterade nästa steg
|
||
1. ~~Slutför kvittoimport och bulk-spara.~~ ✅ Klart (2026-05-01)
|
||
2. Säkerställa robust bildimport och diagnostik.
|
||
3. Implementera avancerad AI-integration för produktkategorisering.
|
||
4. Utöka adminfunktioner för användarhantering och produktadministration.
|
||
5. Förbättra UI/UX för användarflöden, inklusive onboarding och profilhantering.
|
||
|
||
## Plan för Implementering av Fas 6b
|
||
|
||
### 1. Slutför Kvittoimport
|
||
- **Aktiviteter:**
|
||
- Implementera parsers för kvitton (PDF, bildbaserade kvitton).
|
||
- Utveckla gränssnitt för att granska importerade kvitton.
|
||
- Implementera bulk-spara-funktionalitet för kvitton.
|
||
|
||
- **Tekniska Detaljer:**
|
||
- Använd `pdf-parse` och `tesseract.js` för att extrahera data från kvitton.
|
||
- Säkerställa att API-endpoints (`/receipt-import`) hanterar filuppladdning och returnerar strukturerad data.
|
||
|
||
### 2. Förbättra Bildhantering
|
||
- **Aktiviteter:**
|
||
- Säkerställa att `downloadAndOptimizeImage` fungerar korrekt i Docker-miljön.
|
||
- Implementera robust felhantering och diagnostikloggning för bildimport.
|
||
|
||
- **Tekniska Detaljer:**
|
||
- Använd miljövariabler för att definiera sökvägar för bildlagring.
|
||
- Säkerställa att bilder optimeras och lagras korrekt på servern.
|
||
|
||
### 3. Säkerställa Kompatibilitet med Linux/Ubuntu
|
||
- **Aktiviteter:**
|
||
- Kontrollera att alla sökvägar är relativa eller konfigurerbara via miljövariabler.
|
||
- Säkerställa att Docker-miljön är korrekt konfigurerad för att köra på Ubuntu.
|
||
|
||
- **Tekniska Detaljer:**
|
||
- Använd `path.join()` för att bygga sökvägar på ett plattformsoberoende sätt.
|
||
- Säkerställa att `IMAGE_DEST_DIR` är korrekt konfigurerad för Linux/Ubuntu.
|
||
|
||
### 4. Förbättra API-Integration
|
||
- **Aktiviteter:**
|
||
- Säkerställa att API-endpoints har korrekt felhantering och tidsgränser.
|
||
- Implementera robusta tidsgränser och återförsöksmekanismer för API-anrop.
|
||
|
||
- **Tekniska Detaljer:**
|
||
- Använd `http.Client` med korrekta tidsgränser för API-anrop.
|
||
- Implementera återförsöksmekanismer för tillfälliga fel.
|
||
|
||
## Verifiering och Testning
|
||
|
||
### 1. Enhets- och Integrationstester
|
||
- **Aktiviteter:**
|
||
- Skapa enhets- och integrationstester för nya parsers och API-endpoints.
|
||
- Säkerställa att alla tester körs i Docker-miljön.
|
||
|
||
- **Tekniska Detaljer:**
|
||
- Använd `flutter test` för att köra enhetstester.
|
||
- Använd `jest` eller `supertest` för att testa API-endpoints.
|
||
|
||
### 2. Manuell Testning
|
||
- **Aktiviteter:**
|
||
- Manuell testning av kvittoimport och bulk-spara-funktionalitet.
|
||
- Säkerställa att bildhantering fungerar korrekt i Docker-miljön.
|
||
|
||
- **Tekniska Detaljer:**
|
||
- Använd Postman eller liknande verktyg för att testa API-endpoints.
|
||
- Säkerställa att gränssnittet för kvittoimport fungerar som förväntat.
|
||
|
||
## Slutsats
|
||
För att slutföra Fas 6b krävs implementering av parsers för kvitton, förbättringar av bildhantering, och säkerställande av kompatibilitet med Linux/Ubuntu. En robust API-integration och omfattande testning är avgörande för att säkerställa att importfunktionen fungerar som förväntat i produktion. |