hemhub/docs/features/004-task-assignment.md

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:

{"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:

{"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.