123 lines
4.7 KiB
Markdown
123 lines
4.7 KiB
Markdown
# Feature 4 – Tilldelning av uppgifter
|
||
|
||
## Status
|
||
|
||
Pågående.
|
||
|
||
## Bakgrund
|
||
|
||
HemHub har centralt lagrade användare och gemensamma uppgifter. För att senare
|
||
kunna införa regler för pågående arbete behöver en uppgift kunna ha en ansvarig
|
||
användare, utan att tilldelning samtidigt ändrar uppgiftens status.
|
||
|
||
## Mål
|
||
|
||
- välja en valfri ansvarig när en uppgift skapas;
|
||
- visa ansvarig på uppgiftskortet;
|
||
- tilldela, byta eller ta bort ansvarig på en väntande uppgift;
|
||
- lagra tilldelningen centralt så att alla användare ser samma värde.
|
||
|
||
## Omfattning
|
||
|
||
En uppgift kan vara otilldelad eller tilldelad exakt en befintlig användare.
|
||
`Ingen` är standard vid skapande och den aktiva browseranvändaren förväljs
|
||
inte. Frontend återanvänder användarlistan som redan hämtas vid appstart.
|
||
|
||
På ett otilldelat väntande kort öppnar `Ta uppgift` ett användarval. Ett
|
||
tilldelat väntande kort visar namnet och öppnar samma val. Ändringen skickas
|
||
direkt till backend och kortet uppdateras först med den bekräftade responsen.
|
||
Vid fel behålls den tidigare tilldelningen och ett lokalt felmeddelande visas.
|
||
|
||
För `IN_PROGRESS` och `COMPLETED` visas ansvarig eller `Otilldelad` utan
|
||
redigerbar kontroll.
|
||
|
||
## Produktregler
|
||
|
||
- En uppgift har högst en ansvarig.
|
||
- Ansvarig är valfri och måste motsvara en befintlig användare.
|
||
- Endast uppgifter med status `WAITING` får få ändrad ansvarig.
|
||
- Tilldelning ändrar aldrig status, titel, beskrivning eller poäng.
|
||
- Vem som helst kan välja valfri ansvarig; aktiv användare är inte
|
||
autentisering eller behörighetskontroll.
|
||
|
||
## API-förändringar
|
||
|
||
`POST /api/tasks` accepterar det valfria fältet `assigneeId`. Saknat fält eller
|
||
`null` skapar en otilldelad uppgift. Ett UUID som inte motsvarar en användare
|
||
ger `404 Not Found`.
|
||
|
||
`PUT /api/tasks/{taskId}/assignee` ändrar endast ansvarig:
|
||
|
||
```json
|
||
{"assigneeId": "d56b54dd-31b0-4d71-8a10-82464be59a61"}
|
||
```
|
||
|
||
`{"assigneeId": null}` tar bort tilldelningen. Fältet måste finnas i requesten.
|
||
Responsen är den uppdaterade uppgiften. Task-responser innehåller:
|
||
|
||
```json
|
||
{"assignee": {"id": "d56b54dd-31b0-4d71-8a10-82464be59a61", "name": "Anna"}}
|
||
```
|
||
|
||
Otilldelade uppgifter har `"assignee": null`. Ogiltigt UUID eller saknat fält
|
||
ger `400`, okänd uppgift eller användare ger `404` och ändring av en uppgift
|
||
som inte väntar ger `409`. Felen använder det befintliga formatet med `code`
|
||
och `message`.
|
||
|
||
## Databasförändringar
|
||
|
||
`V4__add_task_assignee.sql` lägger till `task.assignee_id UUID NULL` med en
|
||
främmande nyckel till `app_user.id`. Befintliga uppgifter blir otilldelade.
|
||
Migreringen använder varken `ON DELETE CASCADE` eller `ON DELETE SET NULL`.
|
||
|
||
JPA-modellen använder en lazy `ManyToOne`. Repositoryts listning och
|
||
id-hämtning använder en entity graph för att hämta ansvarig tillsammans med
|
||
uppgiften och undvika N+1-frågor när responsen byggs.
|
||
|
||
## Frontendförändringar
|
||
|
||
Skapandedialogen innehåller ett tilldelningsval med `Ingen` och samtliga
|
||
användare. Valet bevaras tillsammans med övriga formulärvärden vid fel.
|
||
|
||
Väntande kort har en separat tilldelningskontroll. Kontrollen är inaktiverad
|
||
medan just det kortets request pågår; övriga delar av brädan förblir
|
||
interaktiva. Serverns task-respons ersätter motsvarande uppgift i den befintliga
|
||
listan utan att ändra ordningen.
|
||
|
||
## Tester och verifiering
|
||
|
||
Backendens integrationstester täcker skapande med och utan ansvarig,
|
||
responsformat, okända id:n, tilldelning, byte, av-tilldelning, statuskonflikt
|
||
och att övriga uppgiftsfält inte ändras.
|
||
|
||
Frontendtesterna täcker standardval och användarlista i skapandedialogen,
|
||
create-requestens `assigneeId`, kortens redigerbara och statiska lägen,
|
||
tilldelningsrequest, vänteläge, serverbekräftad uppdatering, av-tilldelning och
|
||
fel utan optimistisk ändring.
|
||
|
||
Manuell verifiering ska omfatta skapande med och utan ansvarig, tilldelning,
|
||
byte, av-tilldelning, bevarad status, omladdning, statiska kontroller för andra
|
||
statusar, felrespons och projektets normala desktop- och mobilbredder.
|
||
|
||
## Avgränsning mot Feature 5
|
||
|
||
Feature 4 inför inget API eller UI för statusändring och inte regeln att
|
||
`IN_PROGRESS` måste ha en ansvarig. Tilldelning leder inte automatiskt till
|
||
`IN_PROGRESS`, och av-tilldelning leder inte automatiskt till `WAITING`.
|
||
|
||
## Ingår inte
|
||
|
||
Flera ansvariga, statusändring, drag-and-drop, generell redigering, radering,
|
||
deadlines, återkommande uppgifter, poänghistorik, användaradministration,
|
||
autentisering, behörighetskontroll och automatisk tilldelning ingår inte.
|
||
|
||
## Kända begränsningar
|
||
|
||
Användare kan ännu inte raderas, så relationens framtida beteende vid
|
||
användarradering är inte beslutat. Frontend har ingen optimistisk uppdatering;
|
||
det tidigare värdet ligger kvar tills backend svarar.
|
||
|
||
## Relaterade commits
|
||
|
||
Fylls i när featuren har committats.
|