46 lines
4.7 KiB
Markdown
46 lines
4.7 KiB
Markdown
# claims-system – Agentinstruktioner
|
||
|
||
## Syfte
|
||
Bygg ett webbaserat system för hantering av utlägg (”claims”) åt en organisation. Oinloggade användare ska kunna lämna in ett formulär för att begära ersättning. Administratörer loggar in, granskar listan med claims och tar beslut (godkänn/avslå). Systemet ska förberedas för integrationer så att data kan exporteras till bank- och redovisningssystem.
|
||
|
||
## Teknikval och verktyg
|
||
- **Ramverk:** Django.
|
||
- **Pakethantering & virtuella miljöer:** uv (kör `uv add`, `uv run`, `uv sync` osv).
|
||
- **Databas:** SQLite i utveckling. Förbered kodbasen för PostgreSQL i produktion (t.ex. via miljövariabler).
|
||
- **Versionshantering:** Git, använd befintligt repo (initierat i detta steg).
|
||
|
||
## Arkitektur och kodprinciper
|
||
1. Skapa en dedikerad Django-app (t.ex. `claims`) för domänlogiken.
|
||
2. Claims behöver modell med statusfält (t.ex. `PENDING`, `APPROVED`, `REJECTED`) och metadata om belopp, syfte, kostnadsställe samt fält för kvittounderlag (filuppladdning).
|
||
3. Exponera ett offentligt formulär (utan inloggning) där claimers anger kontaktuppgifter, kontonummer och laddar upp kvitto.
|
||
4. Använd Django admin + en enkel intern vy för att lista och uppdatera claims (godkänna/avslå).
|
||
5. Förbered ett integrationslager (t.ex. tjänst eller management command) som kan exportera claims till externa system. Det räcker initialt med en tydlig struktur + TODO.
|
||
6. Dokumentera konfiguration (miljövariabler, hur man startar servern, kör migreringar, exportflöden) i README.
|
||
7. Stöd flera rader i samma inskick, koppla dem till samma användare samt logga varje statusändring.
|
||
8. Tillåt val av valuta per claimrad (default SEK) men håll valet dolt/avancerat för enklare UX.
|
||
9. Tillhandahåll en intern vy som låter användare med rätt behörighet skapa/uppdatera/ta bort konton och toggla `claims.view_claim`/`claims.change_claim`.
|
||
10. Claims ska kopplas till ett projekt/evenemang; projekten hanteras via Django admin.
|
||
11. Offentliga sidor ska använda Tailwind-baserade komponenter (CDN är okej) med minimalistisk layout. Claim-formuläret ska erbjuda klient-side kontroll för antal rader (plus/minus) utan sidladdning och återanvända formsetets tomma form som mall.
|
||
12. Adminvyn för claims ska spegla samma designprinciper (kort per claim, statuschippar, loggtimeline och inlinebeslut).
|
||
13. Hantering av utbetalningar i UI är bakom flaggan `CLAIMS_ENABLE_INTERNAL_PAYMENTS` (styrd via miljövariabel). När den är på ska godkända claims få en summeringssektion med tydlig info (namn, belopp, kontonr) och en "Betala"-knapp som markerar posten som betald (med logg och markerad betalstatus). När flaggan är av saknas knappen och admins instrueras att hantera betalning externt.
|
||
14. När ett utlägg markerats som betalt ska beslut/status vara låst (ingen uppdatering av kommentar eller status i UI eller Django admin). Reset av betalstatus sker endast via admin-knappen.
|
||
15. Filuppladdningar ska alltid få säkra, unika namn (UUID i `receipts/`), och originalnamn ska inte exponeras.
|
||
16. För e-postaviseringar: använd `CLAIMS_EMAIL_ENABLED` (default false) och miljövariablerna `EMAIL_HOST`, `EMAIL_PORT`, `EMAIL_USE_TLS`, `EMAIL_HOST_USER`, `EMAIL_HOST_PASSWORD`, `CLAIMS_EMAIL_FROM`, `CLAIMS_ADMIN_NOTIFICATION_EMAIL`. När flaggan är av ska koden inte försöka skicka mejl (men gärna logga att aviseringar är inaktiverade).
|
||
17. Systemet ska vara tvåspråkigt (sv/en). Alla nya strängar måste wraps i `gettext`/`{% trans %}` och översättningar läggs till via `makemessages`/`compilemessages`. Navbaren innehåller alltid språkväljare och `<html>` ska sätta `lang` enligt vald session.
|
||
18. Efter inskick ska användaren hamna på en Tailwind-baserad bekräftelsesida med knappar för att logga in eller skicka nytt utlägg.
|
||
19. Ett management-kommando `reset_claims` ska alltid finnas uppdaterat för att rensa claims men lämna konton (använd `uv run python manage.py reset_claims`).
|
||
|
||
## Säkerhet och drift
|
||
- Skydda admin-flöden bakom inloggning.
|
||
- Håll känsliga värden (SECRET_KEY, databaskredentialer) i miljövariabler.
|
||
- Automatisk migrering ska fungera lokalt via `uv run python manage.py migrate`.
|
||
|
||
## Nästa steg (högnivå)
|
||
1. Skapa Django-appen `claims`, modellera databastabellen och registrera den i admin.
|
||
2. Implementera det offentliga claim-formuläret med validering och filuppladdning.
|
||
3. Lägg till vyer/templates för att lista och besluta claims i admin/UI.
|
||
4. Skapa exportyta (API-endpoint eller filgenerering) och dokumentera hur integrationer kopplas på.
|
||
5. Skriv tester för modell, formulär och beslutsflöden.
|
||
|
||
Följ ovanstående riktlinjer i fortsatt utveckling. Var konsekvent med uv-kommandon och håll koden modulär så att integrationer kan läggas till utan större omskrivningar.
|