37 lines
2.8 KiB
Markdown
37 lines
2.8 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.
|
||
|
||
## 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.
|