Nils-Johan Gynther
204 lines
14 KiB
Markdown
204 lines
14 KiB
Markdown
# Nasta steg
|
||
|
||
Detta ar huvudroadmap for Recipe App.
|
||
All detaljhistorik och djup teknisk bakgrund finns i respektive tekniska dokument.
|
||
|
||
## Dokumentstatus (2026-05-03)
|
||
|
||
- Fokus: en gemensam prioriteringslista for produkt, utveckling och drift.
|
||
- Delplaner for underomraden ska referera hit, inte duplicera hela roadmapen.
|
||
|
||
## MVP-plan (2026-05-10)
|
||
|
||
MVP ar uppnadd nar en vanlig anvandare kan importera, granska och spara kvitto/recept utan manuella specialsteg, och admin kan underhalla produkt- och kategoridata stabilt i drift.
|
||
|
||
### Fas 1 - Scopefrysning och releasekandidater
|
||
|
||
1. Las MVP-scope till foljande floden:
|
||
- Kvittoimport end-to-end (parse -> granska -> spara).
|
||
- Receptimport end-to-end (url/pdf/ocr/markdown -> granska -> spara).
|
||
- Admin inventarie/product-hantering (CRUD, merge, filter, restore).
|
||
2. Markera uttryckligen allt annat som post-MVP i denna fil (t.ex. EAN/Open Food Facts, utokad AI, storre webbsakerhetsomlaggning).
|
||
3. Faststall releasekandidat for backend + flutter med versionsetikett.
|
||
|
||
### Fas 2 - Hard validering i produktionslik miljo
|
||
|
||
1. Kor manuell verifiering av aliasstrategi med riktiga kvitton (privat alias, global fallback, prioriteringsordning).
|
||
2. Kor fulla regressionsfloden for import, matchning, kategorisering, merge och spara.
|
||
3. Verifiera deployflode och driftkommandon pa server med healthcheck efter release.
|
||
|
||
### Fas 3 - MVP-release
|
||
|
||
1. Publicera releasekandidat nar alla gransvarden ar godkanda.
|
||
2. Folj upp med kort hypercare-period (felrattning med hog prioritet, inga nya features).
|
||
|
||
### Exit-kriterier (Definition of Done for MVP)
|
||
|
||
- End-to-end importfloden fungerar stabilt for minst ett representativt urval av kvitton och receptkallor.
|
||
- Aliasprioritering fungerar deterministiskt: user alias -> global alias -> ordmatchning -> AI.
|
||
- User-scope och IDOR-skydd ar verifierat i kritiska domaner.
|
||
- Admin kan hantera produkter/inventarie utan datakorruption eller behov av manuella DB-ingrepp.
|
||
- Deploy, healthcheck och testkorning ar reproducerbara i driftmiljo.
|
||
|
||
|
||
## Nyligen klart
|
||
|
||
## Utförda steg (2026-05-19)
|
||
|
||
- [x] **Flyerimport-sessioner i backend:** Implementerat session-endpoints för senaste och specifik session.
|
||
- [x] **Flyerimport-persistens i Flutter:** Lättviktig lagring i `SharedPreferences` med `sessionId` + vald state.
|
||
- [x] **Hydreringsflöde i klient:** Restore lokalt -> hämta via sessionId -> fallback till latest-session.
|
||
- [x] **HTTP-semantik + optimering:** 404 för saknad session och single-query för latest-session.
|
||
- [x] **Regressionstester:** Backendtester för flyer-sessioner tillagda och gröna (3/3).
|
||
|
||
## Utförda steg (2026-05-18)
|
||
|
||
- [x] **ESLint i backend + CI:** ESLint-konfiguration tillagd i backend och CI-workflow uppdaterad med lint-step för PR/push.
|
||
- [x] **Dart lint-konfig aktiverad:** `flutter/analysis_options.yaml` tillagd för att säkerställa `flutter_lints` i analyskörningar.
|
||
- [x] **Prisma query logging styrbar per miljö:** `PRISMA_LOG_QUERIES` implementerad i backend samt kopplad i `compose.yml`.
|
||
- [x] **Dokumenterat aktivering av query-loggar:** Instruktion att sätta `PRISMA_LOG_QUERIES=1` och starta om `recipe-api` i test/staging.
|
||
- [x] **Korrigerat testförväntan i receipt-import:** Security-test för saknat användar-id uppdaterat till `UnauthorizedException`.
|
||
|
||
## Utförda steg (2026-05-13)
|
||
|
||
- [x] **Centralt hjälptextsystem (backend):** Nytt `HelpTextsModule` med service, controller och DTO. `GET /api/help-texts/:key` returnerar rätt hjälptext baserat på användarroll (prioritetsordning: admin → user → default). `PUT /api/help-texts/:key/:scope` kräver admin-roll.
|
||
- [x] **Prisma-migration:** `20260513150000_add_help_texts` — `HelpText`-tabell med `@@unique([key, scope])`-constraint och index. Seed-data för `receipt_import` (default + admin-scope) på svenska.
|
||
- [x] **Flutter — "Läs hjälp"-knapp:** `TextButton.icon` i receipt_import_tab hämtar hjälptext från backend och visar AlertDialog med scopeindikator och datum.
|
||
- [x] **Deploy och verifiering:** Migration tillämpad på produktionsserver (`recipe-api` ombyggd och omstartad). Backend och Flutter live och funktionellt.
|
||
- [x] **Copilot-instruktioner:** `.github/copilot-instructions.md` tillagd i samtliga tre repos med robust `.env`-läsningsmönster.
|
||
|
||
## Utförda steg (2026-05-12)
|
||
|
||
- [x] **Alias-scopehantering (admin):** Admin kan höja privat alias → globalt via PATCH-endpoint. Backend blockerar omvänd riktning utan owner (`BadRequestException`). Vanliga användare blockeras med `ForbiddenException`.
|
||
- [x] **Admin alias-UI:** Switch i edit-dialog begränsad till privat → global (låst om redan globalt). Temporär bekräftelse-chip visas 6 s i listan.
|
||
- [x] **Kategori-chip fallback:** "okänd"-chip borttagen globalt – fallback returnerar `SizedBox.shrink()`.
|
||
- [x] **Beroendehärdning:** Nest 11 + multer 2.1.1. `npm audit --audit-level=high` = 0 sårbarheter i recipe-app backend.
|
||
- [x] **Quality-gates:** `prisma:validate`, `typecheck`, `audit:high`, `quality:ci` tillagda som npm-scripts. CI kör nu typecheck i PR- och push-jobb.
|
||
- [x] **Tester:** Ny testtäckning för alias-scope i `receipt-alias.service.spec.ts` och `receipt-alias.security.spec.ts` (16/16 passerar).
|
||
|
||
## Utförda steg (2026-05-11)
|
||
|
||
- [x] Löste Flutter web build-fel och säkerställde att Docker-build går igenom på både lokal och server.
|
||
- [x] Dokumenterade rutiner för hantering av build-artifacts och merge-konflikter.
|
||
- [ ] Säkerställ att .gitignore exkluderar alla genererade Flutter-filer.
|
||
|
||
- **2026-05-10:** Admin-inventarie (CRUD, merge, filter, sortering, preview, säkerhet), user-scope, IDOR-skydd, säkerhetshärdning, optimeringar och utökad testtäckning är nu genomförda och dokumenterade i README, TEKNISK_BESKRIVNING, SÄKERHETSHÄRDNINGSPLAN och SESSIONLOGGAR.
|
||
|
||
- Kvittoimport: förbättrad antal/förpackningsinferens och robustare regelmotor.
|
||
- Kategorisering: utökade brödregler + contradiction guards och nya regler för pasta, grädde, ägg, juice, godis, och potatis.
|
||
- Kategoriträd: nya noder `Korvbröd` under `Fastfoodbröd` och `Grädde` under `Matlagning` i seed-data.
|
||
- Flutter: klientpersistens för pågående kvittoimport.
|
||
- Produktmodell: user-scoped produkter och seed renodlad till kategorier.
|
||
- Testinfrastruktur: parametriserade enhetstester för kvittoimport (18 testfall).
|
||
- CI/CD: GitHub Actions-pipeline för automatiserad testkörning vid push och pull request.
|
||
- **Node.js versionsparitet:** `package-lock.json` spåras nu i git för båda repos; Dockerfiles kör `npm ci` — reproducerbara byggen i alla miljöer.
|
||
- **PDF-kvittoimport stabiliserad:** `pdf-parse` CJS-fix + `pdfjs-dist/legacy` fallback löser `DOMMatrix`-fel i Node.js.
|
||
- **Felkods-forwarding fixad:** `receipt-import.service.ts` i recipe-api vidarebefordrar nu 503 från importer-api som `ServiceUnavailableException` istället för att alltid returnera 400.
|
||
- **AI-optimering (PDF):** `looksLikeReceiptProductLine()` i importer-api filtrerar bort header/footer-rader — Mistral anropas enbart för rader som faktiskt kan vara produkter.
|
||
- **Receptparser hardening:** gemensam parserutility, intervall/parantes/brak-forbattringar samt testtackning for parsern.
|
||
- **Receptsakerhet och dataintegritet:** aktiv-produktvalidering, transaktion vid update, orphan-fil-cleanup och striktare owner-hantering av legacy-recept.
|
||
- **Alternativa ingredienser (Option A):** lagring i `alternativeProductIds` (JSON), matchning mot flera alternativ och lagerkoll som inkluderar alternativ.
|
||
- **Flutter felhantering:** kopierbara felmeddelanden i snackbar + global textselektion for enklare support/felsokning.
|
||
- **Kvittoimport — Simplified Matching Logic (2026-05-09):** Unified matcher som konsoliderar product matching + categorization i en explicit flödestre. Eliminar split mellan `matchProducts()` och `enrichWithAiCategories()`. Ger tydligare trace-logging och bättre debuggability för varför ett item matchades på ett visst sätt. Systemet är nu mer underhållsbart och framtida förbättringar på matching/kategorisering går snabbare.
|
||
|
||
## Huvudprioriteringar
|
||
|
||
1. 🟡 Aliasstrategi i kvittoimport: DELVIS GENOMFÖRD (2026-05-09)
|
||
- Målbild:
|
||
- Vanliga användare skapar och använder privata alias som bara gäller deras egna importer.
|
||
- Admin kan dessutom skapa globala alias som fungerar som fallback för alla användare.
|
||
- Matchningsordning ska alltid vara: user alias -> global alias -> vanlig produktmatchning.
|
||
- Genomfört nu:
|
||
- Gemensam aliasnormalisering införd för lookup, upsert och alias-inlärning.
|
||
- Guardrails införda för tomma alias och brusalias som `rabatt`, `summa`, `pant`.
|
||
- Receipt import lär inte längre in alias automatiskt; användaren måste välja det explicit i edit-dialogen.
|
||
- Aliasöversikter i Flutter visar nu scope tydligare (`privat` vs `global fallback`).
|
||
- Tester tillagda för normalisering, prioritet och behörighet.
|
||
- Kvar:
|
||
- Manuell verifiering i produktionslik miljö av aliasflödet under riktig receipt import.
|
||
- Eventuell vidareutveckling av separat aliasöversikt om behov uppstår.
|
||
- Backend:
|
||
- Centralisera normalisering av `receiptName` så samma regler används i lookup, upsert och alias-inlärning.
|
||
- Härda guardrails för alias: blockera tomma alias, uppenbart brus (`rabatt`, `summa`, `pant`) och andra olämpliga kvittonamn.
|
||
- Säkerställ deterministisk prioritet mellan privata och globala alias i receipt-import.
|
||
- Behåll nuvarande schema i första fasen; ingen ny migration behövs så länge nuvarande `ReceiptAlias`-modell räcker.
|
||
- Flutter:
|
||
- Lägg alias-lärande nära manuell korrigering i receipt-import så användaren explicit kan välja att spara matchningen för framtida importer.
|
||
- Lägg en enkel aliasöversikt där användaren kan se och ta bort sina privata alias.
|
||
- Admin-UI ska kunna skapa globala alias utan att blanda ihop dem med vanliga användares privata alias.
|
||
- Tester:
|
||
- Verifiera att user alias alltid prioriteras före global alias för samma `receiptName`.
|
||
- Verifiera att global alias används när user alias saknas.
|
||
- Verifiera att vanlig användare inte kan skapa globala alias eller ta bort andras alias.
|
||
- Verifiera att manuell korrigering + `learnAlias` ger direkt träff vid nästa import.
|
||
- Verifiera att normalisering gör alias robust mot versaler, whitespace och enklare stavningsvariationer.
|
||
- Leveransordning:
|
||
- ✅ Fas 1: backend-hardening + tester.
|
||
- ✅ Fas 2: UI-stöd i receipt import för alias-inlärning.
|
||
- 🟡 Fas 3: separat aliasöversikt för användare och admin (grund finns, kan vidareutvecklas vid behov).
|
||
2. ✅ **[CLEANUP] Receipt import legacy code (2026-05-09):** KLART
|
||
- Borttaget: `matchProducts()`, `enrichWithAiCategories()`, `findWordMatch()` (gammal), m.fl.
|
||
- Tester uppdaterade och gröna (66/66)
|
||
- Se `SESSION_2026-05-09_RECEIPT_IMPORT.md` för detaljer
|
||
3. ✅ **[FEATURE] Product Management & Scroll Fix (2026-05-09):** KLART
|
||
- Scroll-issue i kvittoimport fixat (7 rader nu synliga)
|
||
- Admin rename/merge endpoints implementerade
|
||
- Private rename/merge endpoints för users implementerade
|
||
- Kodduplicering i products.service.ts eliminerad (~80 rader)
|
||
- admin_products_panel optimerad (cache, parallell restore, expression switches)
|
||
- Deploy-script förbättrad med selektiv build och seed-kontroll
|
||
- Se `SESSION_2026-05-09_RECEIPT_IMPORT.md` för detaljer
|
||
- **Todo:** Deploy till prod, testa i live miljö, ev. add UI för user private rename/merge
|
||
4. Verifiera flyerimportens sessionhydrering end-to-end i test/staging (tab-byte + app-omstart).
|
||
5. Lokalisera kvarvarande stora Flutter-vyer i import/inventarie.
|
||
6. Förbereda avancerad AI-integration med tydlig loggning/audit.
|
||
7. Påbörja EAN-stöd via Open Food Facts.
|
||
|
||
## Beslut som styr arbetet
|
||
|
||
- User-scope for data som ar personligt agd.
|
||
- Backend-kontrakt ar sanningskalla; klienter foljer kontrakten.
|
||
- Importfunktionalitet ar delegerad till microservice-importer dar det ar beslutat.
|
||
|
||
## Framtida förbättringsområden
|
||
|
||
### Säkerhet: httpOnly cookies för Flutter Web
|
||
|
||
Idag lagras JWT-token i localStorage via SharedPreferences i Flutter Web. För att minska XSS-risk bör backend och Flutter Web stödja httpOnly-cookies för tokens. Detta kräver:
|
||
- Backend: endpoint för att sätta och läsa httpOnly-cookie vid login.
|
||
- Flutter Web: anpassning så att token inte läses från localStorage utan session hanteras via cookie.
|
||
Detta är en större arkitekturändring och endast relevant för webben.
|
||
|
||
### Säkerhet: Gitea webhook-signaturvalidering
|
||
|
||
Om Gitea-webhooks används, implementera endpoint i backend som validerar `X-Gitea-Signature` med timing-safe jämförelse. Lägg till `GITEA_WEBHOOK_SECRET` i .env.example. Se säkerhetshärdningsplanen för kodexempel.
|
||
|
||
### Alternativa ingredienser — migrering till relationsmodell (Option B)
|
||
|
||
Nuläge: `RecipeIngredient.alternativeProductIds` lagras som JSON-kolumn (Option A).
|
||
Detta fungerar men saknar referensintegritet — om en alternativ produkt tas bort uppdateras inte kolumnen automatiskt.
|
||
|
||
Framtida lösning: Ersätt JSON-kolumnen med en separat tabell:
|
||
```prisma
|
||
model RecipeIngredientAlternative {
|
||
id Int @id @default(autoincrement())
|
||
recipeIngredientId Int
|
||
recipeIngredient RecipeIngredient @relation(fields: [recipeIngredientId], references: [id], onDelete: Cascade)
|
||
productId Int
|
||
product Product @relation(fields: [productId], references: [id], onDelete: Cascade)
|
||
}
|
||
```
|
||
Fördelar: FK-integritet, möjlig sortering/prioritering av alternativ, lättare att querrya.
|
||
Förutsättning: migration som konverterar befintlig JSON-data till rader i tabellen.
|
||
|
||
## Relaterade dokument
|
||
|
||
- `README.md` - anvandarperspektiv.
|
||
- `TEKNISK_BESKRIVNING.md` - teknisk huvudreferens.
|
||
- [produktlansering.md](_archive/docs/produktlansering.md) - releasechecklista i arkiv.
|
||
- [migrering-MSI.md](_archive/docs/migrering-MSI.md) - migreringshistorik for importer i arkiv.
|
||
- [flutter/next_steps_flutter.md](_archive/docs/flutter/next_steps_flutter.md) - Flutter-specifik plan i arkiv.
|
||
- `_archive/microservice-ai/AI-FUNKTIONER.md` - AI-strategi och historik.
|
||
|
||
## 2026-05-10: Admin-inventarie (CRUD, merge, filter, sortering, preview, säkerhet), user-scope, IDOR-skydd, säkerhetshärdning, optimeringar och utökad testtäckning är nu genomförda och dokumenterade i README, TEKNISK_BESKRIVNING, SÄKERHETSHÄRDNINGSPLAN och SESSIONLOGGAR.
|