4 Commits

16 changed files with 696 additions and 43 deletions

View File

@ -6,8 +6,8 @@ innehåller två separata applikationer:
- en backend byggd med Java 21, Spring Boot och Maven
- en frontend byggd med React, TypeScript, Vite och pnpm
Backend använder en lokal filbaserad H2-databas i `backend/data`. Databasschemat
hanteras med Flyway. Databasfilerna är lokala och ignoreras av Git.
Backend använder en lokal H2-databas i minnet. Databasschemat hanteras med
Flyway, och lokal utvecklingsdata återställs när backend startas om.
API:t innehåller endpoints under `/api/users` för användare och `/api/tasks` för
att skapa och lista gemensamma hushållsuppgifter.

View File

@ -1,5 +1,14 @@
package se.rubble.hemhub.task;
public record CreateTaskRequest(String title, String description) {
}
import tools.jackson.databind.JsonNode;
public record CreateTaskRequest(String title, String description, JsonNode points) {
Integer integerPoints() {
if (points == null || !points.isIntegralNumber() || !points.canConvertToInt()) {
return null;
}
return points.intValue();
}
}

View File

@ -27,6 +27,9 @@ class Task {
@Column(nullable = false, length = 20)
private TaskStatus status;
@Column(nullable = false)
private int points;
@Column(name = "created_at", nullable = false)
private Instant createdAt;
@ -38,11 +41,18 @@ class Task {
String title,
String description,
TaskStatus status,
int points,
Instant createdAt) {
if (points < 1 || points > 99) {
throw new InvalidTaskException(
"Poäng måste vara ett heltal mellan 1 och 99.");
}
this.id = id;
this.title = title;
this.description = description;
this.status = status;
this.points = points;
this.createdAt = createdAt;
}
@ -62,8 +72,11 @@ class Task {
return status;
}
int getPoints() {
return points;
}
Instant getCreatedAt() {
return createdAt;
}
}

View File

@ -30,7 +30,7 @@ public class TaskController {
public TaskResponse create(@RequestBody(required = false) CreateTaskRequest request) {
return taskService.create(
request == null ? null : request.title(),
request == null ? null : request.description());
request == null ? null : request.description(),
request == null ? null : request.integerPoints());
}
}

View File

@ -8,6 +8,7 @@ public record TaskResponse(
String title,
String description,
TaskStatus status,
int points,
Instant createdAt) {
static TaskResponse from(Task task) {
@ -16,7 +17,7 @@ public record TaskResponse(
task.getTitle(),
task.getDescription(),
task.getStatus(),
task.getPoints(),
task.getCreatedAt());
}
}

View File

@ -33,7 +33,10 @@ class TaskService {
}
@Transactional
TaskResponse create(String requestedTitle, String requestedDescription) {
TaskResponse create(
String requestedTitle,
String requestedDescription,
Integer requestedPoints) {
String title = requestedTitle == null ? "" : requestedTitle.trim();
String description = normalizeDescription(requestedDescription);
@ -47,11 +50,17 @@ class TaskService {
"Beskrivningen får innehålla högst 500 tecken.");
}
if (requestedPoints == null) {
throw new InvalidTaskException(
"Poäng måste vara ett heltal mellan 1 och 99.");
}
Task task = new Task(
UUID.randomUUID(),
title,
description,
TaskStatus.WAITING,
requestedPoints,
Instant.now(clock));
return TaskResponse.from(taskRepository.save(task));
@ -70,4 +79,3 @@ class TaskService {
return value.codePointCount(0, value.length());
}
}

View File

@ -1,7 +1,6 @@
spring.datasource.url=jdbc:h2:file:./data/hemhub;MODE=PostgreSQL;DATABASE_TO_LOWER=TRUE;DEFAULT_NULL_ORDERING=HIGH
spring.datasource.url=jdbc:h2:mem:hemhub;MODE=PostgreSQL;DATABASE_TO_LOWER=TRUE;DEFAULT_NULL_ORDERING=HIGH;DB_CLOSE_DELAY=-1
spring.datasource.username=sa
spring.datasource.password=
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.open-in-view=false
spring.flyway.enabled=true

View File

@ -0,0 +1,8 @@
ALTER TABLE task ADD COLUMN points INTEGER;
UPDATE task SET points = 1 WHERE points IS NULL;
ALTER TABLE task ALTER COLUMN points SET NOT NULL;
ALTER TABLE task
ADD CONSTRAINT ck_task_points_range CHECK (points BETWEEN 1 AND 99);

View File

@ -9,6 +9,7 @@ import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.ResultActions;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;
@ -41,7 +42,8 @@ class TaskApiTest {
.content("""
{
"title": " Dammsuga ",
"description": " Bottenvåningen "
"description": " Bottenvåningen ",
"points": 7
}
"""))
.andExpect(status().isCreated())
@ -49,7 +51,12 @@ class TaskApiTest {
.andExpect(jsonPath("$.title").value("Dammsuga"))
.andExpect(jsonPath("$.description").value("Bottenvåningen"))
.andExpect(jsonPath("$.status").value("WAITING"))
.andExpect(jsonPath("$.points").value(7))
.andExpect(jsonPath("$.createdAt").isString());
mockMvc.perform(get("/api/tasks"))
.andExpect(status().isOk())
.andExpect(jsonPath("$[0].points").value(7));
}
@Test
@ -57,7 +64,7 @@ class TaskApiTest {
mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"title": "Dammsuga", "description": " "}
{"title": "Dammsuga", "description": " ", "points": 1}
"""))
.andExpect(status().isCreated())
.andExpect(jsonPath("$.description").value((Object) null));
@ -66,18 +73,58 @@ class TaskApiTest {
@Test
void rejectsBlankAndTooLongTitles() throws Exception {
assertInvalidTask("""
{"title": " "}
{"title": " ", "points": 1}
""");
assertInvalidTask("{\"title\": \"%s\"}".formatted("a".repeat(101)));
assertInvalidTask(
"{\"title\": \"%s\", \"points\": 1}".formatted("a".repeat(101)));
}
@Test
void rejectsTooLongDescription() throws Exception {
assertInvalidTask("""
{"title": "Dammsuga", "description": "%s"}
{"title": "Dammsuga", "description": "%s", "points": 1}
""".formatted("a".repeat(501)));
}
@Test
void acceptsPointBoundaries() throws Exception {
createTaskWithPoints(1)
.andExpect(status().isCreated())
.andExpect(jsonPath("$.points").value(1));
createTaskWithPoints(99)
.andExpect(status().isCreated())
.andExpect(jsonPath("$.points").value(99));
}
@Test
void rejectsMissingNullAndOutOfRangePoints() throws Exception {
assertInvalidTask("""
{"title": "Saknas"}
""");
assertInvalidTask("""
{"title": "Null", "points": null}
""");
assertInvalidTask("""
{"title": "Noll", "points": 0}
""");
assertInvalidTask("""
{"title": "Negativ", "points": -1}
""");
assertInvalidTask("""
{"title": "För stor", "points": 100}
""");
}
@Test
void rejectsNonIntegerPoints() throws Exception {
assertInvalidTask("""
{"title": "Decimal", "points": 1.5}
""");
assertInvalidTask("""
{"title": "Text", "points": "sju"}
""");
}
@Test
void listsTasksOldestFirstWithIdAsTieBreaker() throws Exception {
Instant older = Instant.parse("2026-07-24T10:00:00Z");
@ -86,17 +133,25 @@ class TaskApiTest {
UUID secondId = UUID.fromString("00000000-0000-0000-0000-000000000002");
UUID newestId = UUID.fromString("00000000-0000-0000-0000-000000000003");
taskRepository.save(new Task(newestId, "Nyast", null, TaskStatus.WAITING, newer));
taskRepository.save(new Task(secondId, "Andra", null, TaskStatus.IN_PROGRESS, older));
taskRepository.save(new Task(firstId, "Första", null, TaskStatus.COMPLETED, older));
taskRepository.save(new Task(newestId, "Nyast", null, TaskStatus.WAITING, 3, newer));
taskRepository.save(new Task(secondId, "Andra", null, TaskStatus.IN_PROGRESS, 2, older));
taskRepository.save(new Task(firstId, "Första", null, TaskStatus.COMPLETED, 1, older));
mockMvc.perform(get("/api/tasks"))
.andExpect(status().isOk())
.andExpect(jsonPath("$[0].title").value("Första"))
.andExpect(jsonPath("$[0].points").value(1))
.andExpect(jsonPath("$[1].title").value("Andra"))
.andExpect(jsonPath("$[2].title").value("Nyast"));
}
private ResultActions createTaskWithPoints(int points) throws Exception {
return mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("{\"title\": \"Uppgift %d\", \"points\": %d}"
.formatted(points, points)));
}
private void assertInvalidTask(String body) throws Exception {
mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)

View File

@ -0,0 +1,27 @@
package se.rubble.hemhub.task;
import java.time.Instant;
import java.util.UUID;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertThrows;
class TaskTest {
@Test
void rejectsPointsOutsideAllowedRange() {
assertThrows(InvalidTaskException.class, () -> taskWithPoints(0));
assertThrows(InvalidTaskException.class, () -> taskWithPoints(100));
}
private Task taskWithPoints(int points) {
return new Task(
UUID.randomUUID(),
"Dammsuga",
null,
TaskStatus.WAITING,
points,
Instant.parse("2026-07-26T12:00:00Z"));
}
}

View File

@ -63,9 +63,9 @@ Aktuella endpoints:
### Databas och migreringar
Lokal körning använder en filbaserad H2-databas under `backend/data`. Katalogen
ignoreras av Git. Automatiska backendtester använder en separat H2-databas i
minnet.
Lokal körning använder en H2-databas i minnet. Databasen finns under
backendprocessens livstid och lokal utvecklingsdata återställs när backend
startas om. Automatiska backendtester använder en separat H2-databas i minnet.
Båda anslutningarna använder H2:s `MODE=PostgreSQL`,
`DATABASE_TO_LOWER=TRUE` och `DEFAULT_NULL_ORDERING=HIGH`. Det är en verifierbar
@ -76,6 +76,7 @@ Flyway kör migreringarna:
- `V1__create_users.sql`
- `V2__create_tasks.sql`
- `V3__add_task_points.sql`
Hibernate är konfigurerat med `ddl-auto=validate`; Flyway skapar schemat och
Hibernate validerar entiteterna mot det.
@ -102,11 +103,13 @@ En uppgift lagras i tabellen `task` med:
- `title`: obligatorisk titel, högst 100 tecken;
- `description`: valfri beskrivning, högst 500 tecken;
- `status`: `WAITING`, `IN_PROGRESS` eller `COMPLETED`;
- `points`: obligatoriskt heltal mellan 1 och 99;
- `created_at`: en `Instant`, lagrad som `TIMESTAMP WITH TIME ZONE`.
Status lagras som enumens textvärde genom `EnumType.STRING`. Nya uppgifter får
alltid status `WAITING`. Det finns ingen relation mellan uppgifter och
användare; alla aktiva användare ser samma uppgiftslista.
alltid status `WAITING`. Poängintervallet skyddas i backend och med en
databasconstraint. Det finns ingen relation mellan uppgifter och användare;
alla aktiva användare ser samma uppgiftslista.
### Aktiv användare

View File

@ -0,0 +1,438 @@
# Feature 3 Uppgiftspoäng
## Status
Pågående.
## Bakgrund
HemHub ska på sikt kunna använda spelifiering för att uppmuntra
familjemedlemmar att utföra uppgifter. Exempel på framtida funktioner kan vara
mål, achievements och belöningar baserade på hur många poäng en användare
samlar under en viss period.
Feature 3 inför den grundläggande poänginformationen på uppgiften. Funktionen
registrerar endast uppgiftens poängvärde. Intjäning av poäng och övrig
spelifiering införs i senare features.
## Mål
Feature 3 ska:
- lägga till ett obligatoriskt poängvärde på varje uppgift;
- låta användaren ange poäng när en uppgift skapas;
- visa poängen på uppgiftskortet;
- validera poängen konsekvent i frontend och backend;
- dokumentera hur lokal utvecklingsdata hanteras.
## Betydelsen av poäng
Poängen uttrycker uppgiftens samlade värde utifrån hur:
- tidskrävande uppgiften är;
- besvärlig uppgiften är;
- viktig uppgiften är.
När poängintjäning införs i en senare feature ska samma värde motsvara hur många
poäng användaren får när uppgiften slutförs.
Poängen är inte en exakt tidsuppskattning. En snabb men viktig uppgift kan
därför ha ett högre poängvärde än en längre men mindre betydelsefull uppgift.
Feature 3 registrerar endast poängvärdet. Den ska inte registrera:
- vem som har tjänat poängen;
- om poängen har delats ut;
- när poängen har tjänats in;
- någon historik över poäng.
## Poängskala
Poäng ska vara ett heltal mellan 1 och 99, inklusive gränsvärdena.
Alla heltal i intervallet är tillåtna. Feature 3 inför inte någon fast skala med
fördefinierade steg.
Giltiga exempel:
- 1
- 7
- 25
- 99
Ogiltiga exempel:
- inget värde;
- `null`;
- 0;
- negativa tal;
- 100 eller högre;
- decimaltal;
- text som inte kan tolkas som ett heltal.
En fast poängskala kan införas senare om erfarenhet från användningen visar att
det är lämpligt.
## Avgränsning
Feature 3 omfattar endast:
- uppgiftens titel;
- uppgiftens valfria beskrivning;
- uppgiftens obligatoriska poängvärde;
- visning av poäng på uppgiftskortet.
Feature 3 ska inte införa:
- tilldelning av uppgifter;
- ändring av uppgiftsstatus;
- drag-and-drop;
- redigering av befintliga uppgifter;
- radering av uppgifter;
- deadlines;
- återkommande uppgifter;
- poänghistorik;
- användares poängsaldo;
- topplistor;
- statistik;
- mål;
- achievements;
- belöningar;
- automatisk utdelning av poäng när en uppgift slutförs.
Dessa funktioner hanteras i senare features enligt roadmapen.
## Användarflöde
När användaren öppnar dialogen för att skapa en uppgift ska formuläret
innehålla:
- titel;
- beskrivning;
- poäng.
Poängfältet ska initialt innehålla värdet `1`.
Användaren kan behålla standardvärdet eller ange ett annat heltal mellan 1 och
99.
När uppgiften skapas ska frontend alltid skicka poängvärdet uttryckligen till
backend. Backend ska inte själv fylla i ett saknat värde.
Efter att en uppgift har skapats framgångsrikt ska formuläret återställas.
Poängfältet ska då återgå till `1`.
Om dialogen stängs och senare öppnas igen ska poängfältet också börja på `1`.
## Skapandedialog
Poäng ska anges med ett vanligt numeriskt inmatningsfält.
Fältet ska ha:
- etiketten `Poäng`;
- initialt värde `1`;
- minsta värde `1`;
- högsta värde `99`;
- heltalssteg.
En kort hjälptext kan visas:
> 199 poäng beroende på hur tidskrävande, besvärlig eller viktig uppgiften är.
Fältet får tillfälligt vara tomt medan användaren redigerar värdet. Frontend ska
inte automatiskt återställa värdet till `1` medan användaren skriver.
Validering ska främst ske när användaren försöker skicka formuläret. Avancerad
validering vid varje tangenttryckning ingår inte i denna feature.
## Frontendvalidering
Frontend ska blockera skapandeanropet om poängen inte är ett heltal mellan 1 och
99.
Vid ett ogiltigt värde ska följande meddelande visas:
> Poäng måste vara ett heltal mellan 1 och 99.
Samma meddelande kan användas för:
- tomt värde;
- värde under 1;
- värde över 99;
- decimaltal;
- annat ogiltigt innehåll.
HTML-fältets attribut för minsta värde, högsta värde och heltalssteg får användas
som stöd, men formulärlogiken ska också kontrollera värdet explicit.
Backend är alltid den slutliga garanten för valideringsreglerna.
## Visning på uppgiftskortet
Uppgiftens poäng ska visas på uppgiftskortet som en kompakt och dynamisk badge.
Badgen ska:
- renderas som en vanlig React- och HTML-komponent;
- använda text och CSS;
- läsa värdet från uppgiftens `points`;
- visa värdet i formatet `{points} p`.
Exempel:
- `1 p`
- `7 p`
- `99 p`
Ingen genererad bild eller statisk grafik ska användas för själva poängvärdet.
Placering och visuell utformning ska följa projektets befintliga skärmbilder och
nuvarande kortdesign. Poängindikatorn ska ligga i kortets metadataområde på
motsvarande plats som poängindikatorn i designreferensen.
Mindre justeringar får göras för att passa den faktiska kortimplementationen.
Feature 3 ska däremot inte införa en ny övergripande design för uppgiftskortet.
## API
Fältnamnet ska vara `points` genomgående i API, backend och frontend.
### Skapa uppgift
Requesten för att skapa en uppgift ska innehålla:
```json
{
"title": "Töm diskmaskinen",
"description": "Ställ in allt i rätt skåp",
"points": 3
}
```
`points` är obligatoriskt.
Backend ska inte tolka ett saknat värde som `1`.
### Uppgiftssvar
API-svar som innehåller en uppgift ska också innehålla `points`.
Exempel:
```json
{
"id": "00000000-0000-0000-0000-000000000000",
"title": "Töm diskmaskinen",
"description": "Ställ in allt i rätt skåp",
"status": "WAITING",
"points": 3,
"createdAt": "2026-07-26T12:00:00Z"
}
```
Det gäller både:
- svaret efter att en uppgift skapats;
- listning av uppgifter.
Det exakta API-formatet ska i övrigt följa den befintliga implementationen.
## Backendregler
En uppgift får aldrig existera med ett poängvärde utanför intervallet 199.
Regeln ska skyddas genom hela backend, inte bara i HTTP-lagret.
Beroende på repositoryts befintliga struktur ska valideringen tillämpas på
relevanta nivåer, exempelvis:
- requestvalidering;
- applikations- eller domänlogik;
- entitetsmodell;
- databasens schema.
Implementation ska följa projektets etablerade kodstruktur och inte introducera
ett nytt arkitekturmönster enbart för denna feature.
## Felhantering
Ett ogiltigt eller saknat `points` ska ge:
```text
400 Bad Request
```
Backend ska använda projektets befintliga felformat och befintliga
felhantering.
Feature 3 ska inte introducera en separat felmodell endast för poäng.
Backend får ge mer precisa valideringsdetaljer för exempelvis:
- saknat värde;
- `null`;
- värde under 1;
- värde över 99.
Frontend behöver inte återge varje backenddetalj separat, utan kan visa det
gemensamma användarmeddelandet:
> Poäng måste vara ett heltal mellan 1 och 99.
Vid andra eller oväntade backendfel ska frontend fortsätta använda projektets
befintliga generella felhantering.
## Databas
Databasschemat ska innehålla ett obligatoriskt heltalsfält för uppgiftens poäng.
Det logiska slutläget är:
```text
points INTEGER NOT NULL
```
Databasen ska, om den befintliga schemahanteringen stödjer det, även skydda
intervallet 199 med en motsvarande constraint.
Databasen ska inte ha ett permanent defaultvärde för nya uppgifter. Nya
uppgifter ska alltid få ett uttryckligt poängvärde från applikationen.
Det förvalda värdet `1` är ett frontendbeteende och inte ett sätt för backend
eller databasen att tyst komplettera ofullständiga anrop.
## Lokal utvecklingsdatabas
Den lokala utvecklingsdatabasen ska vara en in-memory H2-databas.
Databasen och dess innehåll ska återställas när backend startas om.
Lokal utvecklingsdata betraktas därför som tillfällig. Användare och uppgifter
som skapats manuellt under utveckling behöver inte bevaras mellan starter.
Detta innebär att Feature 3 inte behöver migrera verkliga befintliga
utvecklingsposter. En ny databas skapas direkt med det obligatoriska
poängfältet.
Före Feature 3 var lokal H2 filbaserad. Feature 3 ändrar utvecklingsanslutningen
till in-memory och uppdaterar utvecklingsdokumentationen i samma ändring.
## Schemahantering och framtida migrering
Att lokal utvecklingsdata inte bevaras innebär inte att framtida
produktionsdata kan återställas vid varje release.
När HemHub börjar använda en beständig PostgreSQL-databas med data som ska
bevaras måste schemaändringar hanteras med kontrollerade migreringar.
Feature 3 behöver inte införa eller färdigställa hela den framtida
produktionsstrategin om den ännu inte finns i repositoryt.
Projektet använder redan Flyway och versionshanterade migreringar. Feature 3 ska
därför lägga till en ny Flyway-migrering för poängfältet och inte ändra tidigare
migreringar. Hibernate ska fortsatt validera schemat i stället för att skapa
det.
Bytet till in-memory H2 innebär att befintliga lokala utvecklingsposter inte
behöver bevaras eller fyllas på med poäng. Själva schemaändringen ska ändå
hanteras som en kontrollerad migrering så att migrationshistoriken förblir
sammanhängande inför framtida beständig data.
Repositoryts faktiska arkitektur och dokumentation har företräde.
## Backendtester
Feature 3 ska minst verifiera att:
- en uppgift kan skapas med ett giltigt `points`;
- det skapade API-svaret innehåller samma `points`;
- listning av uppgifter innehåller `points`;
- gränsvärdet `1` accepteras;
- gränsvärdet `99` accepteras;
- saknat `points` ger `400 Bad Request`;
- `points: null` ger `400 Bad Request`;
- `points: 0` ger `400 Bad Request`;
- negativa värden ger `400 Bad Request`;
- `points: 100` ger `400 Bad Request`.
Testerna ska följa befintlig teststil och utöka nuvarande tester där det är
lämpligt.
## Frontendtester
Feature 3 ska minst verifiera att:
- skapandedialogen öppnas med poängvärdet `1`;
- ett giltigt poängvärde skickas i create-anropet;
- tomt poängfält blockerar submit;
- ett värde under 1 blockerar submit;
- ett värde över 99 blockerar submit;
- ett ogiltigt värde visar felmeddelandet;
- formuläret återställs till poängvärdet `1` efter lyckad skapning;
- ett uppgiftskort visar uppgiftens dynamiska poängbadge;
- badgen visar värdet från uppgiftsdata, exempelvis `7 p`.
Testerna ska inte vara beroende av en viss pixelplacering eller detaljerad CSS.
## Manuell verifiering
Följande ska verifieras manuellt:
1. Starta frontend och backend enligt projektets utvecklingsinstruktioner.
2. Skapa en uppgift utan att ändra poängfältet.
3. Verifiera att uppgiften får `1 p`.
4. Skapa en uppgift med ett mellanvärde, exempelvis `7`.
5. Verifiera att uppgiften får `7 p`.
6. Skapa en uppgift med `99`.
7. Verifiera att uppgiften får `99 p`.
8. Försök skapa en uppgift med tomt poängfält.
9. Verifiera att anropet blockeras och att rätt felmeddelande visas.
10. Försök använda värdena `0` och `100`.
11. Verifiera att båda avvisas.
12. Kontrollera att poängbadgen följer projektets designreferens och fungerar
med ett- och tvåsiffriga värden.
13. Starta om backend.
14. Verifiera att den lokala utvecklingsdatan inte finns kvar.
## Acceptanskriterier
Feature 3 är klar när:
- varje ny uppgift har ett obligatoriskt `points`;
- `points` är ett heltal mellan 1 och 99;
- frontendens standardvärde är `1`;
- frontend alltid skickar `points` uttryckligen;
- backend avvisar saknat eller ogiltigt `points`;
- backend fyller inte automatiskt i ett saknat värde;
- uppgiftens poäng returneras av API:t;
- uppgiftens poäng visas dynamiskt på uppgiftskortet;
- frontend- och backendtester täcker centrala giltiga och ogiltiga fall;
- lokal H2 körs som in-memory och återställs vid omstart;
- relevant dokumentation är uppdaterad;
- Feature 3 inte inför funktionalitet som hör till senare features.
## Implementationsprinciper
När Feature 3 senare implementeras ska Codex först läsa:
```text
AGENTS.md
README.md
docs/architecture.md
docs/development.md
docs/roadmap.md
docs/decisions/
docs/features/
```
Codex ska även läsa relevant backendkod, frontendkod och befintliga tester innan
ändringar görs.
Repositoryts faktiska kod och dokumentation har företräde framför antaganden i
denna featurebeskrivning.
Dokumentation, implementation och tester ska uppdateras tillsammans.
Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
instruktion.

View File

@ -38,16 +38,16 @@ Feature 02 är klara. Den aktuella applikationen har:
- ett monorepo med separat React/Vite-frontend och Spring Boot-backend;
- centralt lagrade användare och ett lokalt browserval av aktiv användare;
- gemensamma uppgifter med titel, valfri beskrivning och status;
- gemensamma uppgifter med titel, valfri beskrivning, status och poäng;
- skapande och listning av uppgifter;
- en bräda med Väntande, Pågående och Klart;
- nya uppgifter som alltid skapas med status `WAITING`.
Det finns ännu inga poäng, uppgiftstilldelningar, statusändringar,
drag-and-drop, redigeringar, raderingar, deadlines eller återkommande uppgifter.
Det finns ännu inga uppgiftstilldelningar, statusändringar, drag-and-drop,
redigeringar, raderingar, deadlines eller återkommande uppgifter.
Nuvarande användarval är inte autentisering.
**Feature 3 Uppgiftspoäng är nästa planerade produktfeature.**
**Feature 3 Uppgiftspoäng är pågående.**
## Featureöversikt
@ -56,7 +56,7 @@ Nuvarande användarval är inte autentisering.
| 0 Projektgrund | Klar | | Körbar frontend, backend och lokal API-koppling |
| 1 Användarval | Klar | 0 | Centrala användare och lokalt aktivt användar-id |
| 2 Skapa uppgifter | Klar | 01 | Gemensamma uppgifter och trekolumnsbräda |
| 3 Uppgiftspoäng | Planerad | 2 | Poäng på uppgifter |
| 3 Uppgiftspoäng | Pågående | 2 | Poäng på uppgifter |
| 4 Tilldelning | Planerad | 12 | Valfri ansvarig användare |
| 5 Statusändring | Planerad | 4 | Backendstyrda statusövergångar |
| 6 Drag-and-drop | Planerad | 5 | Kortflytt via status-API |
@ -109,7 +109,7 @@ interaktiv brädhantering införs.
### Feature 3 Uppgiftspoäng
**Status:** Planerad
**Status:** Pågående
**Beroenden:** Feature 2
@ -124,10 +124,9 @@ interaktiv brädhantering införs.
Feature 3 ligger först eftersom poäng blir ett centralt uppgiftsfält som senare
ska kunna redigeras och historikföras.
**Öppna frågor:**
- exakt poängskala;
- standardvärde för befintliga uppgifter.
Poängskalan är beslutad till alla heltal mellan 1 och 99. V3-migreringen ger
eventuella befintliga uppgifter värdet `1` innan kolumnen görs obligatorisk;
databasen har inget permanent defaultvärde.
### Feature 4 Tilldelning av uppgifter
@ -422,8 +421,6 @@ Nuvarande aktiva användarval är uttryckligen inte autentisering.
## Öppna tvärgående frågor
- Vilken poängskala ska användas och vilket standardvärde får befintliga
uppgifter?
- Ska uppgifter raderas permanent eller mjukt?
- Hur ska datum, tider och tidszoner representeras?
- Ska H2 behållas för lokal utveckling efter PostgreSQL-införandet?

View File

@ -21,6 +21,7 @@ const tasks = [
title: 'Dammsuga',
description: 'Bottenvåningen',
status: 'WAITING',
points: 7,
createdAt: '2026-07-24T10:00:00Z',
},
{
@ -28,6 +29,7 @@ const tasks = [
title: 'Diska',
description: null,
status: 'IN_PROGRESS',
points: 3,
createdAt: '2026-07-24T10:01:00Z',
},
{
@ -35,6 +37,7 @@ const tasks = [
title: 'Vattna blommor',
description: null,
status: 'COMPLETED',
points: 5,
createdAt: '2026-07-24T10:02:00Z',
},
]
@ -167,12 +170,14 @@ test('brädan visar tre kolumner och grupperar hämtade uppgifter', async () =>
render(<App />)
const waiting = await screen.findByRole('region', { name: 'Väntande' })
await screen.findByText('Dammsuga')
const waiting = screen.getByRole('region', { name: 'Väntande' })
const inProgress = screen.getByRole('region', { name: 'Pågående' })
const completed = screen.getByRole('region', { name: 'Klart' })
expect(within(waiting).getByText('Dammsuga')).toBeInTheDocument()
expect(within(waiting).getByText('Bottenvåningen')).toBeInTheDocument()
expect(within(waiting).getByText('7 p')).toBeInTheDocument()
expect(within(inProgress).getByText('Diska')).toBeInTheDocument()
expect(within(completed).getByText('Vattna blommor')).toBeInTheDocument()
expect(screen.queryByText(/Inga uppgifter/i)).not.toBeInTheDocument()
@ -187,6 +192,7 @@ test('Ny uppgift öppnar modalen med fokus i titelfältet', async () => {
expect(screen.getByRole('dialog', { name: 'Skapa ny uppgift' })).toBeInTheDocument()
expect(screen.getByLabelText('Titel')).toHaveFocus()
expect(screen.getByLabelText('Poäng')).toHaveValue(1)
})
test.each([
@ -220,6 +226,7 @@ test.each([
fireEvent.change(screen.getByLabelText('Beskrivning (valfri)'), {
target: { value: 'Bottenvåningen' },
})
fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: '7' } })
close()
@ -229,6 +236,7 @@ test.each([
expect(screen.getByLabelText('Titel')).toHaveValue('')
expect(screen.getByLabelText('Beskrivning (valfri)')).toHaveValue('')
expect(screen.getByLabelText('Poäng')).toHaveValue(1)
})
test('en skapad uppgift visas längst ned i Väntande och modalen stängs', async () => {
@ -237,6 +245,7 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
title: 'Putsa fönster',
description: 'Köket',
status: 'WAITING',
points: 7,
createdAt: '2026-07-24T10:03:00Z',
}
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
@ -253,6 +262,7 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
fireEvent.change(screen.getByLabelText('Beskrivning (valfri)'), {
target: { value: ' Köket ' },
})
fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: '7' } })
fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
await waitFor(() =>
@ -260,14 +270,39 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
)
const waiting = screen.getByRole('region', { name: 'Väntande' })
expect(within(waiting).getAllByRole('article').map((card) => card.textContent)).toEqual([
'DammsugaBottenvåningen',
'Putsa fönsterKöket',
'Dammsuga7 pBottenvåningen',
'Putsa fönster7 pKöket',
])
expect(fetchMock).toHaveBeenLastCalledWith('/api/tasks', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ title: 'Putsa fönster', description: 'Köket' }),
body: JSON.stringify({ title: 'Putsa fönster', description: 'Köket', points: 7 }),
})
fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
expect(screen.getByLabelText('Poäng')).toHaveValue(1)
})
test.each([
{ värde: '', beskrivning: 'tomt' },
{ värde: '0', beskrivning: 'under 1' },
{ värde: '100', beskrivning: 'över 99' },
{ värde: '1.5', beskrivning: 'decimaltal' },
])('ogiltigt poängvärde ($beskrivning) blockerar submit', async ({ värde }) => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = mockUsersAndTasks(users, [])
render(<App />)
await waitFor(() => expect(fetchMock).toHaveBeenCalledTimes(2))
fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
fireEvent.change(screen.getByLabelText('Titel'), { target: { value: 'Dammsuga' } })
fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: värde } })
fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
expect(await screen.findByRole('alert')).toHaveTextContent(
'Poäng måste vara ett heltal mellan 1 och 99.',
)
expect(fetchMock).toHaveBeenCalledTimes(2)
})
test('formulärdata bevaras när skapande av uppgift misslyckas', async () => {
@ -285,14 +320,17 @@ test('formulärdata bevaras när skapande av uppgift misslyckas', async () => {
fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
const title = screen.getByLabelText('Titel')
const description = screen.getByLabelText('Beskrivning (valfri)')
const points = screen.getByLabelText('Poäng')
fireEvent.change(title, { target: { value: 'Dammsuga' } })
fireEvent.change(description, { target: { value: 'Bottenvåningen' } })
fireEvent.change(points, { target: { value: '7' } })
fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
expect(await screen.findByRole('alert')).toHaveTextContent('Uppgiften är ogiltig.')
expect(screen.getByRole('dialog', { name: 'Skapa ny uppgift' })).toBeInTheDocument()
expect(title).toHaveValue('Dammsuga')
expect(description).toHaveValue('Bottenvåningen')
expect(points).toHaveValue(7)
})
function mockUsersAndTasks(userResponse: unknown, taskResponse: unknown) {

View File

@ -7,6 +7,7 @@ type Task = {
title: string
description: string | null
status: TaskStatus
points: number
createdAt: string
}
@ -92,7 +93,10 @@ function TaskBoard({ activeUserName, onLogOut }: TaskBoardProps) {
.filter((task) => task.status === column.status)
.map((task) => (
<article className="task-card" key={task.id}>
<h3>{task.title}</h3>
<div className="task-card-header">
<h3>{task.title}</h3>
<span className="points-badge">{task.points} p</span>
</div>
{task.description && <p>{task.description}</p>}
</article>
))}
@ -122,6 +126,7 @@ type CreateTaskModalProps = {
function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
const [title, setTitle] = useState('')
const [description, setDescription] = useState('')
const [points, setPoints] = useState('1')
const [error, setError] = useState('')
const [isSubmitting, setIsSubmitting] = useState(false)
const isSubmittingRef = useRef(false)
@ -152,6 +157,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
const trimmedTitle = title.trim()
const trimmedDescription = description.trim()
const numericPoints = Number(points)
if (!trimmedTitle || [...trimmedTitle].length > 100) {
setError('Titeln måste innehålla mellan 1 och 100 tecken.')
@ -163,6 +169,16 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
return
}
if (
!points.trim() ||
!Number.isInteger(numericPoints) ||
numericPoints < 1 ||
numericPoints > 99
) {
setError('Poäng måste vara ett heltal mellan 1 och 99.')
return
}
setError('')
isSubmittingRef.current = true
setIsSubmitting(true)
@ -174,6 +190,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
body: JSON.stringify({
title: trimmedTitle,
description: trimmedDescription || null,
points: numericPoints,
}),
})
@ -212,7 +229,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
×
</button>
</div>
<form onSubmit={(event) => void submit(event)}>
<form noValidate onSubmit={(event) => void submit(event)}>
<label htmlFor="task-title">Titel</label>
<input
id="task-title"
@ -231,6 +248,22 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
onChange={(event) => setDescription(event.target.value)}
/>
<label htmlFor="task-points">Poäng</label>
<input
id="task-points"
type="number"
min="1"
max="99"
step="1"
value={points}
disabled={isSubmitting}
aria-describedby="task-points-help"
onChange={(event) => setPoints(event.target.value)}
/>
<p id="task-points-help" className="field-help">
199 poäng beroende hur tidskrävande, besvärlig eller viktig uppgiften är.
</p>
{error && (
<p className="error" role="alert">
{error}

View File

@ -174,12 +174,36 @@ textarea {
margin: 0;
}
.task-card-header {
display: flex;
align-items: flex-start;
justify-content: space-between;
gap: 0.75rem;
}
.points-badge {
flex: 0 0 auto;
padding: 0.2rem 0.5rem;
border-radius: 999px;
color: #1e3a8a;
background: #dbeafe;
font-size: 0.8rem;
font-weight: 700;
line-height: 1.25;
}
.task-card p {
margin-top: 0.5rem;
color: #475569;
white-space: pre-wrap;
}
.field-help {
margin: -0.25rem 0 0;
color: #64748b;
font-size: 0.85rem;
}
.modal-backdrop {
position: fixed;
inset: 0;