15 Commits

Author SHA1 Message Date
b6460a3924 docs: close feature 7 2026-07-27 22:06:08 +02:00
5df0146672 Merge pull request 'feat: add task deletion' (#11) from feature/007-task-deletion into main
Reviewed-on: #11
2026-07-27 21:27:25 +02:00
f296d15446 feat: add task deletion 2026-07-27 21:26:19 +02:00
5dea4c4027 docs: close feature 6 2026-07-27 13:21:17 +02:00
2696195e74 Merge pull request 'feat: add task drag and drop' (#10) from feature/006-task-drag-and-drop into main
Reviewed-on: #10
2026-07-27 13:18:19 +02:00
c3c64482c0 feat: add task drag and drop 2026-07-27 13:15:39 +02:00
ddd706536e Update docs/roadmap.md 2026-07-27 10:44:41 +02:00
dd145db12f Update docs/features/005-task-status.md 2026-07-27 10:39:22 +02:00
5b9e562722 Merge pull request 'feat: add task status transitions' (#9) from feature/005-task-status into main
Reviewed-on: #9
2026-07-27 00:48:44 +02:00
65a6488c0b feat: add task status transitions 2026-07-27 00:46:37 +02:00
6570aad4a2 Merge pull request 'docs: align completed feature status' (#8) from chore/005-align-feature-status into main
Reviewed-on: #8
2026-07-26 23:57:51 +02:00
85afc3d3a3 docs: align completed feature status 2026-07-26 23:56:58 +02:00
d78611f5f7 Merge pull request 'feat: add task assignment' (#7) from feature/004-task-assignment into main
Reviewed-on: #7
2026-07-26 22:50:09 +02:00
aaebe888f3 feat: add task assignment 2026-07-26 22:49:06 +02:00
2e62261f49 Merge pull request 'feat: add task points' (#6) from feature/003-task-points into main
Reviewed-on: #6
2026-07-26 17:45:58 +02:00
39 changed files with 3902 additions and 102 deletions

View File

@ -10,7 +10,10 @@ 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.
att skapa, lista, tilldela, ändra status på och permanent radera gemensamma
hushållsuppgifter. Uppgiftskort kan flyttas mellan brädans statuskolumner med
drag-and-drop eller med de befintliga statusknapparna. Radering kräver
bekräftelse och genomförs först när backend har bekräftat operationen.
## Starta backend

View File

@ -2,10 +2,16 @@ package se.rubble.hemhub.api;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.method.annotation.MethodArgumentTypeMismatchException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import se.rubble.hemhub.task.InvalidTaskException;
import se.rubble.hemhub.task.InvalidTaskAssignmentException;
import se.rubble.hemhub.task.InvalidTaskStatusException;
import se.rubble.hemhub.task.AssigneeNotFoundException;
import se.rubble.hemhub.task.TaskNotFoundException;
import se.rubble.hemhub.task.TaskRequiresAssigneeException;
import se.rubble.hemhub.user.InvalidUserNameException;
import se.rubble.hemhub.user.UserNameAlreadyExistsException;
@ -33,5 +39,47 @@ public class ApiExceptionHandler {
return ResponseEntity.badRequest()
.body(new ApiError("INVALID_TASK", exception.getMessage()));
}
@ExceptionHandler(InvalidTaskAssignmentException.class)
public ResponseEntity<ApiError> handleInvalidTaskAssignment(
InvalidTaskAssignmentException exception) {
return ResponseEntity.badRequest()
.body(new ApiError("INVALID_TASK_ASSIGNMENT", exception.getMessage()));
}
@ExceptionHandler(MethodArgumentTypeMismatchException.class)
public ResponseEntity<ApiError> handleInvalidPathParameter() {
return ResponseEntity.badRequest()
.body(new ApiError(
"INVALID_TASK_ASSIGNMENT",
"Uppgifts-id måste vara ett giltigt UUID."));
}
@ExceptionHandler(TaskNotFoundException.class)
public ResponseEntity<ApiError> handleTaskNotFound() {
return ResponseEntity.status(HttpStatus.NOT_FOUND)
.body(new ApiError("TASK_NOT_FOUND", "Uppgiften finns inte."));
}
@ExceptionHandler(AssigneeNotFoundException.class)
public ResponseEntity<ApiError> handleAssigneeNotFound() {
return ResponseEntity.status(HttpStatus.NOT_FOUND)
.body(new ApiError("USER_NOT_FOUND", "Användaren finns inte."));
}
@ExceptionHandler(InvalidTaskStatusException.class)
public ResponseEntity<ApiError> handleInvalidTaskStatus() {
return ResponseEntity.badRequest()
.body(new ApiError(
"INVALID_TASK_STATUS",
"Status måste vara WAITING, IN_PROGRESS eller COMPLETED."));
}
@ExceptionHandler(TaskRequiresAssigneeException.class)
public ResponseEntity<ApiError> handleTaskRequiresAssignee() {
return ResponseEntity.status(HttpStatus.CONFLICT)
.body(new ApiError(
"TASK_REQUIRES_ASSIGNEE",
"En pågående uppgift måste ha en ansvarig."));
}
}

View File

@ -0,0 +1,4 @@
package se.rubble.hemhub.task;
public class AssigneeNotFoundException extends RuntimeException {
}

View File

@ -2,7 +2,11 @@ package se.rubble.hemhub.task;
import tools.jackson.databind.JsonNode;
public record CreateTaskRequest(String title, String description, JsonNode points) {
public record CreateTaskRequest(
String title,
String description,
JsonNode points,
JsonNode assigneeId) {
Integer integerPoints() {
if (points == null || !points.isIntegralNumber() || !points.canConvertToInt()) {
@ -11,4 +15,8 @@ public record CreateTaskRequest(String title, String description, JsonNode point
return points.intValue();
}
UUIDValue parsedAssigneeId() {
return UUIDValue.optional(assigneeId);
}
}

View File

@ -0,0 +1,8 @@
package se.rubble.hemhub.task;
public class InvalidTaskAssignmentException extends RuntimeException {
public InvalidTaskAssignmentException(String message) {
super(message);
}
}

View File

@ -0,0 +1,4 @@
package se.rubble.hemhub.task;
public class InvalidTaskStatusException extends RuntimeException {
}

View File

@ -8,7 +8,11 @@ import jakarta.persistence.Entity;
import jakarta.persistence.EnumType;
import jakarta.persistence.Enumerated;
import jakarta.persistence.Id;
import jakarta.persistence.JoinColumn;
import jakarta.persistence.ManyToOne;
import jakarta.persistence.Table;
import jakarta.persistence.FetchType;
import se.rubble.hemhub.user.User;
@Entity
@Table(name = "task")
@ -30,6 +34,10 @@ class Task {
@Column(nullable = false)
private int points;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "assignee_id")
private User assignee;
@Column(name = "created_at", nullable = false)
private Instant createdAt;
@ -42,17 +50,22 @@ class Task {
String description,
TaskStatus status,
int points,
User assignee,
Instant createdAt) {
if (points < 1 || points > 99) {
throw new InvalidTaskException(
"Poäng måste vara ett heltal mellan 1 och 99.");
}
if (status == TaskStatus.IN_PROGRESS && assignee == null) {
throw new TaskRequiresAssigneeException();
}
this.id = id;
this.title = title;
this.description = description;
this.status = status;
this.points = points;
this.assignee = assignee;
this.createdAt = createdAt;
}
@ -76,6 +89,29 @@ class Task {
return points;
}
User getAssignee() {
return assignee;
}
void changeAssignee(User assignee) {
if (status == TaskStatus.IN_PROGRESS && assignee == null) {
throw new TaskRequiresAssigneeException();
}
this.assignee = assignee;
}
void changeStatus(TaskStatus targetStatus, User automaticAssignee) {
if (targetStatus == TaskStatus.IN_PROGRESS && assignee == null) {
if (automaticAssignee == null) {
throw new TaskRequiresAssigneeException();
}
assignee = automaticAssignee;
}
status = targetStatus;
}
Instant getCreatedAt() {
return createdAt;
}

View File

@ -1,10 +1,14 @@
package se.rubble.hemhub.task;
import java.util.List;
import java.util.UUID;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseStatus;
@ -28,9 +32,44 @@ public class TaskController {
@PostMapping
@ResponseStatus(HttpStatus.CREATED)
public TaskResponse create(@RequestBody(required = false) CreateTaskRequest request) {
UUIDValue assigneeId = request == null
? UUIDValue.optional(null)
: request.parsedAssigneeId();
return taskService.create(
request == null ? null : request.title(),
request == null ? null : request.description(),
request == null ? null : request.integerPoints());
request == null ? null : request.integerPoints(),
assigneeId.value());
}
@PutMapping("/{taskId}/assignee")
public TaskResponse updateAssignee(
@PathVariable UUID taskId,
@RequestBody(required = false) UpdateTaskAssigneeRequest request) {
if (request == null) {
throw new InvalidTaskAssignmentException("Fältet assigneeId måste anges.");
}
return taskService.updateAssignee(taskId, request.parsedAssigneeId().value());
}
@PutMapping("/{taskId}/status")
public TaskResponse updateStatus(
@PathVariable UUID taskId,
@RequestBody(required = false) UpdateTaskStatusRequest request) {
if (request == null) {
throw new InvalidTaskStatusException();
}
return taskService.updateStatus(
taskId,
request.parsedStatus(),
request.parsedActiveUserId().value());
}
@DeleteMapping("/{taskId}")
@ResponseStatus(HttpStatus.NO_CONTENT)
public void delete(@PathVariable UUID taskId) {
taskService.delete(taskId);
}
}

View File

@ -0,0 +1,4 @@
package se.rubble.hemhub.task;
public class TaskNotFoundException extends RuntimeException {
}

View File

@ -4,9 +4,13 @@ import java.util.List;
import java.util.UUID;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.EntityGraph;
interface TaskRepository extends JpaRepository<Task, UUID> {
@EntityGraph(attributePaths = "assignee")
List<Task> findAllByOrderByCreatedAtAscIdAsc();
}
@EntityGraph(attributePaths = "assignee")
java.util.Optional<Task> findOneById(UUID id);
}

View File

@ -0,0 +1,4 @@
package se.rubble.hemhub.task;
public class TaskRequiresAssigneeException extends RuntimeException {
}

View File

@ -9,6 +9,7 @@ public record TaskResponse(
String description,
TaskStatus status,
int points,
AssigneeResponse assignee,
Instant createdAt) {
static TaskResponse from(Task task) {
@ -18,6 +19,14 @@ public record TaskResponse(
task.getDescription(),
task.getStatus(),
task.getPoints(),
AssigneeResponse.from(task.getAssignee()),
task.getCreatedAt());
}
public record AssigneeResponse(UUID id, String name) {
static AssigneeResponse from(se.rubble.hemhub.user.User user) {
return user == null ? null : new AssigneeResponse(user.getId(), user.getName());
}
}
}

View File

@ -9,19 +9,24 @@ import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import se.rubble.hemhub.user.User;
import se.rubble.hemhub.user.UserRepository;
@Service
class TaskService {
private final TaskRepository taskRepository;
private final UserRepository userRepository;
private final Clock clock;
@Autowired
TaskService(TaskRepository taskRepository) {
this(taskRepository, Clock.systemUTC());
TaskService(TaskRepository taskRepository, UserRepository userRepository) {
this(taskRepository, userRepository, Clock.systemUTC());
}
TaskService(TaskRepository taskRepository, Clock clock) {
TaskService(TaskRepository taskRepository, UserRepository userRepository, Clock clock) {
this.taskRepository = taskRepository;
this.userRepository = userRepository;
this.clock = clock;
}
@ -36,7 +41,8 @@ class TaskService {
TaskResponse create(
String requestedTitle,
String requestedDescription,
Integer requestedPoints) {
Integer requestedPoints,
UUID requestedAssigneeId) {
String title = requestedTitle == null ? "" : requestedTitle.trim();
String description = normalizeDescription(requestedDescription);
@ -55,17 +61,65 @@ class TaskService {
"Poäng måste vara ett heltal mellan 1 och 99.");
}
User assignee = findAssignee(requestedAssigneeId);
Task task = new Task(
UUID.randomUUID(),
title,
description,
TaskStatus.WAITING,
requestedPoints,
assignee,
Instant.now(clock));
return TaskResponse.from(taskRepository.save(task));
}
@Transactional
TaskResponse updateAssignee(UUID taskId, UUID requestedAssigneeId) {
Task task = taskRepository.findOneById(taskId)
.orElseThrow(TaskNotFoundException::new);
User assignee = findAssignee(requestedAssigneeId);
task.changeAssignee(assignee);
return TaskResponse.from(task);
}
@Transactional
TaskResponse updateStatus(
UUID taskId,
TaskStatus targetStatus,
UUID activeUserId) {
Task task = taskRepository.findOneById(taskId)
.orElseThrow(TaskNotFoundException::new);
User automaticAssignee = null;
if (targetStatus == TaskStatus.IN_PROGRESS && task.getAssignee() == null) {
if (activeUserId == null) {
throw new TaskRequiresAssigneeException();
}
automaticAssignee = findAssignee(activeUserId);
}
task.changeStatus(targetStatus, automaticAssignee);
return TaskResponse.from(task);
}
@Transactional
void delete(UUID taskId) {
Task task = taskRepository.findById(taskId)
.orElseThrow(TaskNotFoundException::new);
taskRepository.delete(task);
}
private User findAssignee(UUID requestedAssigneeId) {
if (requestedAssigneeId == null) {
return null;
}
return userRepository.findById(requestedAssigneeId)
.orElseThrow(AssigneeNotFoundException::new);
}
private static String normalizeDescription(String requestedDescription) {
if (requestedDescription == null) {
return null;

View File

@ -0,0 +1,25 @@
package se.rubble.hemhub.task;
import java.util.UUID;
import tools.jackson.databind.JsonNode;
import tools.jackson.databind.node.JsonNodeType;
record UUIDValue(boolean present, UUID value) {
static UUIDValue optional(JsonNode node) {
if (node == null || node.isNull()) {
return new UUIDValue(node != null, null);
}
if (node.getNodeType() != JsonNodeType.STRING) {
throw new InvalidTaskAssignmentException("Användar-id måste vara ett giltigt UUID.");
}
try {
return new UUIDValue(true, UUID.fromString(node.stringValue()));
} catch (IllegalArgumentException exception) {
throw new InvalidTaskAssignmentException("Användar-id måste vara ett giltigt UUID.");
}
}
}

View File

@ -0,0 +1,16 @@
package se.rubble.hemhub.task;
import tools.jackson.databind.JsonNode;
public record UpdateTaskAssigneeRequest(JsonNode assigneeId) {
UUIDValue parsedAssigneeId() {
UUIDValue parsed = UUIDValue.optional(assigneeId);
if (!parsed.present()) {
throw new InvalidTaskAssignmentException("Fältet assigneeId måste anges.");
}
return parsed;
}
}

View File

@ -0,0 +1,23 @@
package se.rubble.hemhub.task;
import tools.jackson.databind.JsonNode;
import tools.jackson.databind.node.JsonNodeType;
public record UpdateTaskStatusRequest(JsonNode status, JsonNode activeUserId) {
TaskStatus parsedStatus() {
if (status == null || status.getNodeType() != JsonNodeType.STRING) {
throw new InvalidTaskStatusException();
}
try {
return TaskStatus.valueOf(status.stringValue());
} catch (IllegalArgumentException exception) {
throw new InvalidTaskStatusException();
}
}
UUIDValue parsedActiveUserId() {
return UUIDValue.optional(activeUserId);
}
}

View File

@ -10,7 +10,7 @@ import jakarta.persistence.Table;
@Entity
@Table(name = "app_user")
class User {
public class User {
@Id
private UUID id;
@ -34,11 +34,11 @@ class User {
this.createdAt = createdAt;
}
UUID getId() {
public UUID getId() {
return id;
}
String getName() {
public String getName() {
return name;
}

View File

@ -4,8 +4,7 @@ import java.util.UUID;
import org.springframework.data.jpa.repository.JpaRepository;
interface UserRepository extends JpaRepository<User, UUID> {
public interface UserRepository extends JpaRepository<User, UUID> {
boolean existsByNormalizedName(String normalizedName);
}

View File

@ -0,0 +1,6 @@
ALTER TABLE task
ADD COLUMN assignee_id UUID;
ALTER TABLE task
ADD CONSTRAINT fk_task_assignee
FOREIGN KEY (assignee_id) REFERENCES app_user (id);

View File

@ -15,6 +15,7 @@ import org.springframework.web.context.WebApplicationContext;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.put;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@ -52,6 +53,7 @@ class TaskApiTest {
.andExpect(jsonPath("$.description").value("Bottenvåningen"))
.andExpect(jsonPath("$.status").value("WAITING"))
.andExpect(jsonPath("$.points").value(7))
.andExpect(jsonPath("$.assignee").value((Object) null))
.andExpect(jsonPath("$.createdAt").isString());
mockMvc.perform(get("/api/tasks"))
@ -59,6 +61,67 @@ class TaskApiTest {
.andExpect(jsonPath("$[0].points").value(7));
}
@Test
void createsUnassignedTaskWhenAssigneeIsExplicitlyNull() throws Exception {
mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"title": "Dammsuga", "points": 1, "assigneeId": null}
"""))
.andExpect(status().isCreated())
.andExpect(jsonPath("$.assignee").value((Object) null));
}
@Test
void createsAndListsTaskWithAssignee() throws Exception {
UUID userId = createUser("Anna");
mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{
"title": "Dammsuga",
"points": 7,
"assigneeId": "%s"
}
""".formatted(userId)))
.andExpect(status().isCreated())
.andExpect(jsonPath("$.assignee.id").value(userId.toString()))
.andExpect(jsonPath("$.assignee.name").value("Anna"));
mockMvc.perform(get("/api/tasks"))
.andExpect(status().isOk())
.andExpect(jsonPath("$[0].assignee.id").value(userId.toString()))
.andExpect(jsonPath("$[0].assignee.name").value("Anna"));
}
@Test
void rejectsUnknownAssigneeWhenCreatingTask() throws Exception {
mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{
"title": "Dammsuga",
"points": 7,
"assigneeId": "00000000-0000-0000-0000-000000000099"
}
"""))
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("USER_NOT_FOUND"));
mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{
"title": "Dammsuga",
"points": 7,
"assigneeId": "inte-ett-uuid"
}
"""))
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_ASSIGNMENT"));
}
@Test
void storesBlankDescriptionAsNull() throws Exception {
mockMvc.perform(post("/api/tasks")
@ -133,9 +196,12 @@ 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, 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));
taskRepository.save(new Task(
newestId, "Nyast", null, TaskStatus.WAITING, 3, null, newer));
taskRepository.save(new Task(
secondId, "Andra", null, TaskStatus.WAITING, 2, null, older));
taskRepository.save(new Task(
firstId, "Första", null, TaskStatus.COMPLETED, 1, null, older));
mockMvc.perform(get("/api/tasks"))
.andExpect(status().isOk())
@ -145,6 +211,74 @@ class TaskApiTest {
.andExpect(jsonPath("$[2].title").value("Nyast"));
}
@Test
void assignsChangesAndRemovesAssigneeWithoutChangingOtherTaskFields() throws Exception {
UUID firstUserId = createUser("Bo");
UUID secondUserId = createUser("Cecilia");
String taskId = createTask("Dammsuga", "Bottenvåningen", 7, null);
updateAssignee(taskId, """
{"assigneeId": "%s"}
""".formatted(firstUserId))
.andExpect(status().isOk())
.andExpect(jsonPath("$.assignee.id").value(firstUserId.toString()))
.andExpect(jsonPath("$.status").value("WAITING"))
.andExpect(jsonPath("$.title").value("Dammsuga"))
.andExpect(jsonPath("$.description").value("Bottenvåningen"))
.andExpect(jsonPath("$.points").value(7));
updateAssignee(taskId, """
{"assigneeId": "%s"}
""".formatted(secondUserId))
.andExpect(status().isOk())
.andExpect(jsonPath("$.assignee.id").value(secondUserId.toString()));
updateAssignee(taskId, """
{"assigneeId": null}
""")
.andExpect(status().isOk())
.andExpect(jsonPath("$.assignee").value((Object) null))
.andExpect(jsonPath("$.status").value("WAITING"))
.andExpect(jsonPath("$.title").value("Dammsuga"))
.andExpect(jsonPath("$.description").value("Bottenvåningen"))
.andExpect(jsonPath("$.points").value(7));
}
@Test
void rejectsMissingAssigneeFieldAndInvalidUuid() throws Exception {
String taskId = createTask("Dammsuga", null, 1, null);
updateAssignee(taskId, "{}")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_ASSIGNMENT"));
updateAssignee(taskId, """
{"assigneeId": "inte-ett-uuid"}
""")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_ASSIGNMENT"));
updateAssignee("inte-ett-uuid", """
{"assigneeId": null}
""")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_ASSIGNMENT"));
}
@Test
void returnsNotFoundForUnknownTaskAndUnknownAssignee() throws Exception {
String taskId = createTask("Dammsuga", null, 1, null);
updateAssignee("00000000-0000-0000-0000-000000000099", """
{"assigneeId": null}
""")
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("TASK_NOT_FOUND"));
updateAssignee(taskId, """
{"assigneeId": "00000000-0000-0000-0000-000000000099"}
""")
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("USER_NOT_FOUND"));
}
private ResultActions createTaskWithPoints(int points) throws Exception {
return mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
@ -159,4 +293,50 @@ class TaskApiTest {
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK"));
}
private UUID createUser(String name) throws Exception {
String response = mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"name": "%s"}
""".formatted(name)))
.andExpect(status().isCreated())
.andReturn()
.getResponse()
.getContentAsString();
String id = com.jayway.jsonpath.JsonPath.read(response, "$.id");
return UUID.fromString(id);
}
private String createTask(
String title,
String description,
int points,
UUID assigneeId) throws Exception {
String descriptionJson = description == null ? "null" : "\"%s\"".formatted(description);
String assigneeJson = assigneeId == null ? "null" : "\"%s\"".formatted(assigneeId);
String response = mockMvc.perform(post("/api/tasks")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{
"title": "%s",
"description": %s,
"points": %d,
"assigneeId": %s
}
""".formatted(title, descriptionJson, points, assigneeJson)))
.andExpect(status().isCreated())
.andReturn()
.getResponse()
.getContentAsString();
return com.jayway.jsonpath.JsonPath.read(response, "$.id");
}
private ResultActions updateAssignee(String taskId, String body) throws Exception {
return mockMvc.perform(put("/api/tasks/{taskId}/assignee", taskId)
.contentType(MediaType.APPLICATION_JSON)
.content(body));
}
}

View File

@ -0,0 +1,128 @@
package se.rubble.hemhub.task;
import java.time.Instant;
import java.util.UUID;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.EnumSource;
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.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;
import se.rubble.hemhub.user.User;
import se.rubble.hemhub.user.UserRepository;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.delete;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@SpringBootTest
class TaskDeletionApiTest {
@Autowired
private WebApplicationContext context;
@Autowired
private TaskRepository taskRepository;
@Autowired
private UserRepository userRepository;
private MockMvc mockMvc;
@BeforeEach
void setUp() {
taskRepository.deleteAll();
userRepository.deleteAll();
mockMvc = MockMvcBuilders.webAppContextSetup(context).build();
}
@ParameterizedTest
@EnumSource(TaskStatus.class)
void deletesTaskInEveryStatus(TaskStatus statusValue) throws Exception {
User assignee = createUser();
Task task = saveTask(statusValue, assignee);
mockMvc.perform(delete("/api/tasks/{taskId}", task.getId()))
.andExpect(status().isNoContent())
.andExpect(content().string(""));
mockMvc.perform(get("/api/tasks"))
.andExpect(status().isOk())
.andExpect(jsonPath("$").isEmpty());
org.junit.jupiter.api.Assertions.assertTrue(userRepository.existsById(assignee.getId()));
}
@Test
void deletesOnlyRequestedTask() throws Exception {
User assignee = createUser();
Task deleted = saveTask(TaskStatus.WAITING, assignee);
Task remaining = saveTask(TaskStatus.COMPLETED, null);
mockMvc.perform(delete("/api/tasks/{taskId}", deleted.getId()))
.andExpect(status().isNoContent());
mockMvc.perform(get("/api/tasks"))
.andExpect(status().isOk())
.andExpect(jsonPath("$.length()").value(1))
.andExpect(jsonPath("$[0].id").value(remaining.getId().toString()))
.andExpect(jsonPath("$[0].status").value("COMPLETED"));
org.junit.jupiter.api.Assertions.assertTrue(userRepository.existsById(assignee.getId()));
}
@Test
void returnsNotFoundForUnknownAndAlreadyDeletedTask() throws Exception {
Task task = saveTask(TaskStatus.WAITING, null);
mockMvc.perform(delete("/api/tasks/{taskId}", task.getId()))
.andExpect(status().isNoContent());
mockMvc.perform(delete("/api/tasks/{taskId}", task.getId()))
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("TASK_NOT_FOUND"));
mockMvc.perform(delete(
"/api/tasks/{taskId}",
"00000000-0000-0000-0000-000000000099"))
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("TASK_NOT_FOUND"));
}
@Test
void keepsExistingBadRequestForInvalidUuid() throws Exception {
mockMvc.perform(delete("/api/tasks/{taskId}", "inte-ett-uuid"))
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_ASSIGNMENT"));
}
private User createUser() throws Exception {
String response = mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"name": "Urban"}
"""))
.andExpect(status().isCreated())
.andReturn()
.getResponse()
.getContentAsString();
String id = com.jayway.jsonpath.JsonPath.read(response, "$.id");
return userRepository.findById(UUID.fromString(id)).orElseThrow();
}
private Task saveTask(TaskStatus statusValue, User assignee) {
return taskRepository.save(new Task(
UUID.randomUUID(),
"Dammsuga",
"Bottenvåningen",
statusValue,
7,
assignee,
Instant.parse("2026-07-28T09:00:00Z")));
}
}

View File

@ -0,0 +1,255 @@
package se.rubble.hemhub.task;
import java.time.Instant;
import java.util.UUID;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
import org.junit.jupiter.params.provider.EnumSource;
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;
import se.rubble.hemhub.user.User;
import se.rubble.hemhub.user.UserRepository;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.put;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@SpringBootTest
class TaskStatusApiTest {
private static final Instant CREATED_AT = Instant.parse("2026-07-27T10:15:30Z");
@Autowired
private WebApplicationContext context;
@Autowired
private TaskRepository taskRepository;
@Autowired
private UserRepository userRepository;
private MockMvc mockMvc;
@BeforeEach
void setUp() {
taskRepository.deleteAll();
mockMvc = MockMvcBuilders.webAppContextSetup(context).build();
}
@ParameterizedTest
@CsvSource({
"WAITING, IN_PROGRESS",
"WAITING, COMPLETED",
"IN_PROGRESS, WAITING",
"IN_PROGRESS, COMPLETED",
"COMPLETED, WAITING",
"COMPLETED, IN_PROGRESS"
})
void allowsEveryDirectStatusTransition(TaskStatus initial, TaskStatus target)
throws Exception {
User assignee = createUser();
Task task = saveTask(initial, assignee);
updateStatus(task.getId(), target, assignee.getId())
.andExpect(status().isOk())
.andExpect(jsonPath("$.status").value(target.name()))
.andExpect(jsonPath("$.title").value("Dammsuga"))
.andExpect(jsonPath("$.description").value("Bottenvåningen"))
.andExpect(jsonPath("$.points").value(7))
.andExpect(jsonPath("$.createdAt").value(CREATED_AT.toString()))
.andExpect(jsonPath("$.assignee.id").value(assignee.getId().toString()));
}
@ParameterizedTest
@EnumSource(TaskStatus.class)
void acceptsCurrentStatusAsIdempotentTarget(TaskStatus statusValue) throws Exception {
User assignee = createUser();
Task task = saveTask(statusValue, assignee);
updateStatus(task.getId(), statusValue, null)
.andExpect(status().isOk())
.andExpect(jsonPath("$.status").value(statusValue.name()))
.andExpect(jsonPath("$.assignee.id").value(assignee.getId().toString()));
}
@Test
void automaticallyAssignsActiveUserWhenUnassignedTaskStarts() throws Exception {
User activeUser = createUser();
Task task = saveTask(TaskStatus.WAITING, null);
updateStatus(task.getId(), TaskStatus.IN_PROGRESS, activeUser.getId())
.andExpect(status().isOk())
.andExpect(jsonPath("$.status").value("IN_PROGRESS"))
.andExpect(jsonPath("$.assignee.id").value(activeUser.getId().toString()))
.andExpect(jsonPath("$.assignee.name").value(activeUser.getName()));
}
@Test
void keepsExistingAssigneeAndDoesNotResolveActiveUser() throws Exception {
User assignee = createUser();
Task task = saveTask(TaskStatus.WAITING, assignee);
updateStatus(
task.getId(),
TaskStatus.IN_PROGRESS,
UUID.fromString("00000000-0000-0000-0000-000000000099"))
.andExpect(status().isOk())
.andExpect(jsonPath("$.assignee.id").value(assignee.getId().toString()));
}
@Test
void requiresValidActiveUserWhenUnassignedTaskStarts() throws Exception {
Task task = saveTask(TaskStatus.COMPLETED, null);
updateStatus(task.getId(), TaskStatus.IN_PROGRESS, null)
.andExpect(status().isConflict())
.andExpect(jsonPath("$.code").value("TASK_REQUIRES_ASSIGNEE"));
updateStatus(
task.getId(),
TaskStatus.IN_PROGRESS,
UUID.fromString("00000000-0000-0000-0000-000000000099"))
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("USER_NOT_FOUND"));
}
@ParameterizedTest
@EnumSource(TaskStatus.class)
void allowsAssigningAndChangingAssigneeInEveryStatus(TaskStatus statusValue)
throws Exception {
User first = createUser();
User second = createUser();
Task task = saveTask(statusValue, first);
updateAssignee(task.getId(), second.getId())
.andExpect(status().isOk())
.andExpect(jsonPath("$.status").value(statusValue.name()))
.andExpect(jsonPath("$.assignee.id").value(second.getId().toString()));
}
@ParameterizedTest
@EnumSource(value = TaskStatus.class, names = {"WAITING", "COMPLETED"})
void allowsRemovingAssigneeOutsideInProgress(TaskStatus statusValue) throws Exception {
Task task = saveTask(statusValue, createUser());
removeAssignee(task.getId())
.andExpect(status().isOk())
.andExpect(jsonPath("$.status").value(statusValue.name()))
.andExpect(jsonPath("$.assignee").value((Object) null));
}
@Test
void rejectsRemovingAssigneeFromInProgressTask() throws Exception {
User assignee = createUser();
Task task = saveTask(TaskStatus.IN_PROGRESS, assignee);
removeAssignee(task.getId())
.andExpect(status().isConflict())
.andExpect(jsonPath("$.code").value("TASK_REQUIRES_ASSIGNEE"))
.andExpect(jsonPath("$.message")
.value("En pågående uppgift måste ha en ansvarig."));
}
@Test
void validatesStatusRequestAndTaskId() throws Exception {
Task task = saveTask(TaskStatus.WAITING, null);
rawStatusUpdate(task.getId().toString(), "{}")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_STATUS"));
rawStatusUpdate(task.getId().toString(), """
{"status": null}
""")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_STATUS"));
rawStatusUpdate(task.getId().toString(), """
{"status": "UNKNOWN"}
""")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_STATUS"));
rawStatusUpdate(task.getId().toString(), """
{"status": "IN_PROGRESS", "activeUserId": "inte-ett-uuid"}
""")
.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("INVALID_TASK_ASSIGNMENT"));
rawStatusUpdate(task.getId().toString(), "{")
.andExpect(status().isBadRequest());
rawStatusUpdate("00000000-0000-0000-0000-000000000099", """
{"status": "WAITING"}
""")
.andExpect(status().isNotFound())
.andExpect(jsonPath("$.code").value("TASK_NOT_FOUND"));
}
private User createUser() throws Exception {
String name = "U" + UUID.randomUUID();
String response = mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"name": "%s"}
""".formatted(name)))
.andExpect(status().isCreated())
.andReturn()
.getResponse()
.getContentAsString();
String id = com.jayway.jsonpath.JsonPath.read(response, "$.id");
return userRepository.findById(UUID.fromString(id)).orElseThrow();
}
private Task saveTask(TaskStatus statusValue, User assignee) {
return taskRepository.save(new Task(
UUID.randomUUID(),
"Dammsuga",
"Bottenvåningen",
statusValue,
7,
assignee,
CREATED_AT));
}
private ResultActions updateStatus(
UUID taskId,
TaskStatus target,
UUID activeUserId) throws Exception {
String activeUserJson = activeUserId == null
? ""
: ", \"activeUserId\": \"%s\"".formatted(activeUserId);
return rawStatusUpdate(
taskId.toString(),
"""
{"status": "%s"%s}
""".formatted(target.name(), activeUserJson));
}
private ResultActions rawStatusUpdate(String taskId, String body) throws Exception {
return mockMvc.perform(put("/api/tasks/{taskId}/status", taskId)
.contentType(MediaType.APPLICATION_JSON)
.content(body));
}
private ResultActions updateAssignee(UUID taskId, UUID assigneeId) throws Exception {
return mockMvc.perform(put("/api/tasks/{taskId}/assignee", taskId)
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"assigneeId": "%s"}
""".formatted(assigneeId)));
}
private ResultActions removeAssignee(UUID taskId) throws Exception {
return mockMvc.perform(put("/api/tasks/{taskId}/assignee", taskId)
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"assigneeId": null}
"""));
}
}

View File

@ -15,6 +15,20 @@ class TaskTest {
assertThrows(InvalidTaskException.class, () -> taskWithPoints(100));
}
@Test
void rejectsInProgressTaskWithoutAssignee() {
assertThrows(
TaskRequiresAssigneeException.class,
() -> new Task(
UUID.randomUUID(),
"Dammsuga",
null,
TaskStatus.IN_PROGRESS,
3,
null,
Instant.parse("2026-07-26T12:00:00Z")));
}
private Task taskWithPoints(int points) {
return new Task(
UUID.randomUUID(),
@ -22,6 +36,7 @@ class TaskTest {
null,
TaskStatus.WAITING,
points,
null,
Instant.parse("2026-07-26T12:00:00Z"));
}
}

View File

@ -23,12 +23,16 @@ byggprocess.
### Frontend
Frontend finns i `frontend/` och använder React 19, TypeScript, Vite och pnpm.
Den ansvarar för:
Frontend finns i `frontend/` och använder React 19, TypeScript, Vite, pnpm och
dnd-kit-ekosystemets aktuella React-adapter. Den ansvarar för:
- hämtning och presentation av användare och uppgifter;
- lokalt val av aktiv användare;
- formulär för att skapa användare och uppgifter;
- val och visning av ansvarig användare på uppgifter;
- serverbekräftade statusändringar genom knappar på uppgiftskorten;
- optimistiska statusflyttar genom drag-and-drop mellan brädans kolumner;
- bekräftad och serverbekräftad permanent radering av uppgifter;
- klientnära validering och begripliga felmeddelanden;
- uppgiftsbrädan med kolumnerna Väntande, Pågående och Klart.
@ -60,6 +64,9 @@ Aktuella endpoints:
- `POST /api/users`
- `GET /api/tasks`
- `POST /api/tasks`
- `PUT /api/tasks/{taskId}/assignee`
- `PUT /api/tasks/{taskId}/status`
- `DELETE /api/tasks/{taskId}`
### Databas och migreringar
@ -77,6 +84,7 @@ Flyway kör migreringarna:
- `V1__create_users.sql`
- `V2__create_tasks.sql`
- `V3__add_task_points.sql`
- `V4__add_task_assignee.sql`
Hibernate är konfigurerat med `ddl-auto=validate`; Flyway skapar schemat och
Hibernate validerar entiteterna mot det.
@ -104,12 +112,28 @@ En uppgift lagras i tabellen `task` med:
- `description`: valfri beskrivning, högst 500 tecken;
- `status`: `WAITING`, `IN_PROGRESS` eller `COMPLETED`;
- `points`: obligatoriskt heltal mellan 1 och 99;
- `assignee_id`: nullable främmande nyckel till `app_user`;
- `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`. 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.
databasconstraint. En uppgift kan vara otilldelad eller referera till exakt en
ansvarig användare. Relationen hämtas tillsammans med uppgifterna när de listas,
så API-responsen kan innehålla ansvarigs `id` och `name` utan separata
frontend-anrop. Alla aktiva användare ser samma uppgiftslista.
Ansvarig är valfri vid skapande. Tilldelnings-API:t kan tilldela eller byta
ansvarig i samtliga statusar. Ansvarig kan tas bort i `WAITING` och `COMPLETED`,
men inte i `IN_PROGRESS`. Tilldelning ändrar aldrig uppgiftens status.
Alla direkta statusövergångar är tillåtna och samma målstatus är idempotent.
`IN_PROGRESS` kräver en ansvarig. När en otilldelad uppgift påbörjas skickar
frontend aktiv användares id, och backend tilldelar användaren och ändrar status
i samma transaktion. En befintlig ansvarig byts aldrig av statusoperationen.
Uppgifter raderas fysiskt genom task-repositoryt. Det finns ingen
mjukraderingsflagga, papperskorg eller återställningsmodell. Radering av en
uppgift påverkar inte dess ansvariga användare.
### Aktiv användare
@ -124,12 +148,25 @@ lokalt per browser och utgör inte autentisering eller behörighetskontroll.
### Felhantering
Backend använder ett litet gemensamt JSON-format med `code` och `message`.
`ApiExceptionHandler` översätter kända valideringsfel till `400 Bad Request`
och dubbletter av användarnamn till `409 Conflict`.
`ApiExceptionHandler` översätter kända valideringsfel till `400 Bad Request`,
saknade uppgifter eller användare till `404 Not Found` och dubbletter eller
otillåtna tilldelningsändringar till `409 Conflict`.
Frontend skiljer mellan fel vid hämtning och skapande. Hämtfel kan
återförsökas. Formulärfel visas nära formuläret och inmatningen behålls vid
misslyckade API-anrop.
misslyckade API-anrop. Status- och tilldelningsfel visas lokalt på berört kort;
statusknappar och tilldelning uppdateras först med backendens bekräftade
respons. Drag-and-drop flyttar kortet optimistiskt men återställer hela den
tidigare uppgiften vid fel. Vid framgång ersätts alltid det lokala värdet med
backendens fullständiga respons. Status- och tilldelningsanrop delar låsning per
task-id, så det berörda kortet blockeras utan att resten av brädan låses.
Drag-and-drop återanvänder backendens befintliga status-API oförändrat.
Radering är serverbekräftad och använder samma låsning per task-id. Kortet och
bekräftelsedialogen ligger kvar tills backend svarar. Vid `204 No Content`
tas kortet bort lokalt. Ett `404`-svar tas endast som bekräftelse på att kortet
redan saknas när felkoden är `TASK_NOT_FOUND`; övriga fel behåller kortet och
dialogen för ett nytt försök.
### Teststrategi
@ -141,7 +178,9 @@ Backend har JUnit 5-tester:
Frontend använder Vitest, jsdom och React Testing Library. `fetch` och
`localStorage` ersätts i testerna, så frontendtesterna kräver inte en körande
backend. Produktionsbygget kör TypeScript-kompilering följt av Vite.
backend. Drag-and-drop-adaptern översätter bibliotekshändelser till task-id och
status, så stateflöden kan testas utan att simulera fysisk layout i jsdom.
Produktionsbygget kör TypeScript-kompilering följt av Vite.
### Produktionsdeployment

View File

@ -2,7 +2,7 @@
## Status
Pågående.
Färdig och mergad till `main`.
## Bakgrund
@ -343,7 +343,7 @@ Repositoryts faktiska arkitektur och dokumentation har företräde.
## Backendtester
Feature 3 ska minst verifiera att:
Backendtesterna verifierar att:
- en uppgift kan skapas med ett giltigt `points`;
- det skapade API-svaret innehåller samma `points`;
@ -356,12 +356,12 @@ Feature 3 ska minst verifiera att:
- 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.
Testerna följer den befintliga teststilen och utökar de tidigare
uppgifts-API-testerna.
## Frontendtester
Feature 3 ska minst verifiera att:
Frontendtesterna verifierar att:
- skapandedialogen öppnas med poängvärdet `1`;
- ett giltigt poängvärde skickas i create-anropet;
@ -373,11 +373,11 @@ Feature 3 ska minst verifiera att:
- 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.
Testerna är inte beroende av en viss pixelplacering eller detaljerad CSS.
## Manuell verifiering
Följande ska verifieras manuellt:
Följande verifierades manuellt:
1. Starta frontend och backend enligt projektets utvecklingsinstruktioner.
2. Skapa en uppgift utan att ändra poängfältet.
@ -436,3 +436,8 @@ Dokumentation, implementation och tester ska uppdateras tillsammans.
Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
instruktion.
## Relaterade commits
- `059d4da9214969ed3e28592178160da6de614b4d` `feat: add task points`
- `2e62261f49bb3142e28882483e41e0250ab11c5f` merge till `main`

View File

@ -0,0 +1,123 @@
# Feature 4 Tilldelning av uppgifter
## Status
Färdig och mergad till `main`.
## 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 genomfördes för 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
- `aaebe888f3bae43b3413e9fa3893fec90afac8b4` `feat: add task assignment`
- `d78611f5f77374228f1f69b66734931a988f8355` merge till `main`

View File

@ -0,0 +1,124 @@
# Feature 5 Statusändring och statusregler
## Status
Färdig och mergad till `main`.
## Bakgrund
Efter Feature 4 kan uppgifter vara otilldelade eller ha en ansvarig, men inget
API eller gränssnitt kan ändra status. Feature 5 inför ett enkelt knappflöde
före drag-and-drop och säkerställer statusreglerna i backend.
## Mål
- ändra status genom ett särskilt backend-API;
- tillåta direkta övergångar mellan `WAITING`, `IN_PROGRESS` och `COMPLETED`;
- kräva ansvarig för `IN_PROGRESS`;
- automatiskt tilldela aktiv browseranvändare när en otilldelad uppgift
påbörjas;
- tillåta statusberoende ändringar av ansvarig;
- använda serverbekräftade uppdateringar och vänteläge per kort.
## Status- och tilldelningsregler
Alla statusar får ändras direkt till varandra. Ett anrop med aktuell status som
mål är giltigt och idempotent. En uppgift behöver inte passera
`IN_PROGRESS` för att bli `COMPLETED`.
`WAITING` och `COMPLETED` får vara tilldelade eller otilldelade.
`IN_PROGRESS` måste alltid ha en ansvarig. Det befintliga tilldelnings-API:t
kan tilldela eller byta ansvarig i samtliga statusar och ta bort ansvarig i
`WAITING` och `COMPLETED`. Ett försök att ta bort ansvarig i `IN_PROGRESS`
avvisas med `409 TASK_REQUIRES_ASSIGNEE`. Tilldelning ändrar aldrig status.
När en otilldelad uppgift ändras till `IN_PROGRESS` skickar frontend aktiv
användares id. Backend verifierar användaren, tilldelar den och ändrar status i
samma transaktion. Om uppgiften redan har en ansvarig behålls den, och skickat
`activeUserId` används inte för att byta ansvarig.
## API-förändringar
Status ändras med:
```http
PUT /api/tasks/{taskId}/status
```
```json
{
"status": "IN_PROGRESS",
"activeUserId": "d56b54dd-31b0-4d71-8a10-82464be59a61"
}
```
`status` är obligatoriskt. `activeUserId` krävs endast när en otilldelad
uppgift ska bli `IN_PROGRESS`. Responsen använder samma fullständiga
task-format som övriga task-operationer.
Kända fel använder befintligt format med `code` och `message`:
- okänd uppgift: `404 TASK_NOT_FOUND`;
- saknad, null eller okänd status: `400 INVALID_TASK_STATUS`;
- okänd användare: `404 USER_NOT_FOUND`;
- otilldelad `IN_PROGRESS`: `409 TASK_REQUIRES_ASSIGNEE`;
- ogiltigt UUID-format: `400` med befintlig requestfelkod.
`USER_NOT_FOUND` och `INVALID_TASK_ASSIGNMENT` återanvänds från Feature 4 i
stället för att införa parallella felkoder för samma användar-id.
## Databasförändringar
Inga. Befintliga kolumner för status och ansvarig är tillräckliga.
## Frontendförändringar
Varje kort visar två statusknappar:
- `WAITING`: `Påbörja`, `Markera klar`;
- `IN_PROGRESS`: `Till Väntande`, `Markera klar`;
- `COMPLETED`: `Till Väntande`, `Påbörja igen`.
Tilldelningskontrollen är redigerbar i alla statusar. Alternativet `Ingen`
visas inte för `IN_PROGRESS`.
Status och tilldelning delar ett vänteläge per uppgift. Under ett anrop ligger
kortet kvar i sin kolumn och båda kontrollerna på kortet är inaktiverade.
Övriga kort är fortsatt interaktiva. Vid framgång ersätts uppgiften med
serverresponsen; vid fel behålls tidigare data och felet visas lokalt.
## Tester och verifiering
Backendtesterna omfattar samtliga direkta övergångar, idempotens, automatisk
tilldelning, bevarad ansvarig, statusvalidering, okända id:n, statusberoende
tilldelning och oförändrade uppgiftsfält.
Frontendtesterna omfattar knapparnas statusmappning, requestformat,
serverbekräftad flytt, automatisk tilldelning i responsen, lokalt vänteläge,
dubbelsubmitsskydd, fel utan optimistisk ändring och statusberoende
tilldelningsalternativ.
Manuell verifiering genomfördes genom ett sammanhängande flöde genom alla tre
statusar, automatisk tilldelning, byte och borttagning av ansvarig, omladdning
och centrala API-fel. Browserflödet verifierades i desktop- och mobilbredd utan
upptäckta problem.
## Avgränsningar
Ingen drag-and-drop, radering, generell redigering, sortering, deadline,
återkommande uppgift, status- eller poänghistorik, slutföranderegistrering,
statistik, användaradministration, autentisering eller behörighetskontroll
införs.
## Kända begränsningar
Aktiv användare är ett lokalt browserval och inte autentisering. Backend kan
verifiera att id:t finns, men inte vem som faktiskt använder browsern.
Statusknapparna är ett första gränssnitt före Feature 6. Det finns ingen
versionskontroll för konkurrerande uppdateringar utöver transaktioner och
aktuell serverlogik.
## Relaterade commits
- `65a6488c0b268f49b1361591f025bdea8d67f754` `feat: add task status transitions`

View File

@ -0,0 +1,551 @@
# Feature 6 Drag-and-drop
## Status
Färdig och mergad till main.
## Bakgrund
Feature 5 införde backendstyrda statusövergångar mellan `WAITING`,
`IN_PROGRESS` och `COMPLETED`, ett särskilt status-API samt ett första
knappbaserat gränssnitt för statusändring.
Feature 6 ska komplettera detta med drag-and-drop mellan brädans
statuskolumner. Featuren ska återanvända den befintliga statusmodellen,
status-API:t, tilldelningsreglerna och frontendens hantering av vänteläge och
lokala fel. Den ska inte skapa en parallell statusmekanism.
## Mål
Feature 6 ska:
- låta användaren dra uppgiftskort mellan statuskolumner;
- använda status-API:t från Feature 5;
- ge omedelbar visuell återkoppling genom optimistisk flytt;
- återställa kortet om backend avvisar statusändringen;
- hantera automatisk tilldelning när en otilldelad uppgift dras till Pågående;
- behålla befintliga statusknappar som ett tillfälligt alternativ;
- fungera med mus och på en rimlig nivå med touch;
- hålla dragmekanik, statuslogik och kortlayout tillräckligt separerade för
framtida ändringar.
## Omfattning
Feature 6 är primärt en frontendfeature.
Backendens befintliga endpoint används:
```http
PUT /api/tasks/{taskId}/status
```
Requesten innehåller målstatus och kan innehålla aktiv användares id:
```json
{
"status": "IN_PROGRESS",
"activeUserId": "d56b54dd-31b0-4d71-8a10-82464be59a61"
}
```
Backend ska endast ändras om granskning av den faktiska implementationen visar
att en mindre korrigering behövs för att det befintliga kontraktet ska kunna
återanvändas korrekt.
## Implementerad lösning
Frontend använder `@dnd-kit/react` 0.5.0 som aktuell React-adapter och
`@dnd-kit/dom` 0.5.0 för en konfigurerad pointer-sensor. Legacy-paketen
`@dnd-kit/core` och `@dnd-kit/sortable` används inte. Sortable-stöd behövs inte
eftersom kort inte ordnas inom kolumner.
`TaskDragAndDrop.tsx` avgränsar bibliotekskopplingen. Adaptern:
- registrerar uppgiftskort som draggable och statuskolumner som droppable;
- översätter ett lyckat drop-event till task-id och målstatus;
- ignorerar avbrutna dragningar och ogiltiga mål;
- använder sex pixlars aktiveringsavstånd för mus och penna;
- använder 250 millisekunders fördröjning med åtta pixlars tolerans för touch;
- behåller dnd-kits standardplugins och tangentbordssensor;
- förlitar sig på sensorns standardskydd mot dragstart från interaktiva
element.
Ingen särskild `touch-action`, collision detector eller drag-overlay har lagts
till. Den befintliga responsiva layouten är oförändrad.
`TaskBoard` har fortsatt en gemensam requestväg och låsning per task-id för
statusändringar. Ett presentationsval avgör beteendet:
- statusknappar använder `server-confirmed` och flyttar inte kortet före svar;
- drag-and-drop använder `optimistic`, sparar hela tidigare uppgiften och
flyttar kortet direkt;
- lyckade anrop ersätter uppgiften med hela serverresponsen;
- misslyckade optimistiska anrop återställer hela rollback-värdet och visar
felet lokalt.
När en otilldelad uppgift dras till `IN_PROGRESS` visar det optimistiska värdet
den aktiva användarens id och namn. En befintlig ansvarig behålls. Backendens
befintliga status-API och Feature 5-regler återanvänds utan backendändringar.
Frontendens 44 tester, TypeScript-kompilering, Vites produktionsbygge och
`git diff --check` passerar på feature-branchen. Manuell browserverifiering av
de centrala drag-, server- och rollbackflödena är genomförd.
## Avgränsningar
Feature 6 ska inte införa:
- en ny statusmodell;
- ett nytt eller parallellt status-API;
- manuell sortering inom en kolumn;
- persistent kortordning;
- generell redigering av uppgifter;
- radering;
- deadlines;
- återkommande uppgifter;
- status- eller poänghistorik;
- undo-funktion;
- flera ansvariga;
- autentisering eller behörigheter;
- realtidsuppdatering mellan browsers;
- en ny global state-lösning;
- horisontell scrollning som ett särskilt mobilkoncept;
- ett specialbyggt tangentbordsflöde för drag-and-drop.
Att flytta ett kort inom samma kolumn ska inte ändra någon ordning och ska inte
ge ett backend-anrop.
## Befintliga statusregler
Feature 6 ska behandla följande regler som redan beslutade:
- statusarna är `WAITING`, `IN_PROGRESS` och `COMPLETED`;
- alla direkta statusövergångar är tillåtna;
- samma målstatus är giltig och idempotent;
- `IN_PROGRESS` kräver ansvarig;
- `WAITING` och `COMPLETED` får vara otilldelade;
- när en otilldelad uppgift sätts till `IN_PROGRESS` skickar frontend aktiv
användares id;
- backend tilldelar då användaren och ändrar status atomärt;
- om uppgiften redan har en ansvarig behålls denna;
- statusoperationen byter aldrig en befintlig ansvarig;
- backend returnerar hela den uppdaterade uppgiften;
- serverns fullständiga task-respons är slutlig sanning.
## Uppdateringsstrategi
Drag-and-drop använder en kontrollerad optimistisk uppdatering.
När ett kort släpps i en annan statuskolumn ska frontend:
1. spara hela den nuvarande task-versionen som rollback-värde;
2. skapa ett optimistiskt lokalt task-läge;
3. visa kortet omedelbart i målkolumnen;
4. markera kortet som upptaget;
5. skicka statusanropet;
6. vid framgång ersätta den optimistiska uppgiften med serverns fullständiga
respons;
7. vid fel återställa hela den tidigare task-versionen;
8. visa felet lokalt på det återställda kortet.
Rollback ska återställa hela uppgiften, inte enbart statusfältet. Detta är
viktigt eftersom en optimistisk flytt till `IN_PROGRESS` även kan innehålla en
tillfällig antagen ansvarig.
Ingen generell infrastruktur för optimistiska uppdateringar ska införas.
Lösningen ska hållas lokal till uppgiftslistan och drag-and-drop-flödet.
Feature 5:s statusknappar ska fortsatt vara serverbekräftade: kortet ligger kvar
i sin aktuella kolumn tills backend svarar.
## Otilldelad uppgift till Pågående
När en otilldelad uppgift dras till `IN_PROGRESS` ska frontend:
- skicka målstatus `IN_PROGRESS`;
- skicka aktiv användares id;
- optimistiskt visa aktiv användare som ansvarig;
- låta backend tilldela användaren och ändra status i samma transaktion.
Om uppgiften redan har en ansvarig ska frontend inte optimistiskt ersätta denna
med den aktiva användaren. Serverresponsen ersätter alltid det optimistiska
antagandet.
Drag-and-drop ska inte visa ett nytt ansvarigval.
## Drag-and-drop-bibliotek
Feature 6 ska använda dnd-kit-ekosystemets aktuella stabila React-lösning.
Featuredokumentet låser inte exakta paket eller API:n. Codex ska vid
implementation verifiera den aktuella officiella dokumentationen, vilka paket
som är aktuella respektive legacy, kompatibilitet med repositoryts
React-version samt påverkan på Vitest/jsdom och React Testing Library.
Den valda lösningen ska stödja:
- draggable-kort;
- droppable-statuskolumner;
- pointer- och touchinteraktion;
- aktiveringsvillkor;
- avbruten dragning;
- identifiering av målkolumn.
Biblioteket ska inte användas för:
- sortering inom kolumner;
- persistent ordning;
- egen domänmodell;
- generell state-hantering;
- parallell statuslogik.
Dragbibliotekets händelser ska översättas till en gemensam,
bibliotekoberoende ingång till statusflödet.
## Statusknapparnas roll
Feature 5:s statusknappar behålls tills vidare som ett fullt fungerande
alternativ. De betraktas inte som en permanent del av målbilden. Den
ursprungliga visuella designen innehåller inte statusknappar, och de ska därför
enkelt kunna tas bort efter utvärdering.
Implementation ska följa dessa principer:
- drag-and-drop får inte byggas ovanpå knappkomponenterna;
- draglogik får inte placeras i knapparna;
- statuslogik får inte dupliceras mellan knappar och drag-and-drop;
- båda ska dela underliggande requestlogik, låsning per task-id, felhantering
och ersättning med serverrespons;
- drag-and-drop använder optimistisk visuell flytt, medan statusknapparna
förblir serverbekräftade och låter kortet ligga kvar tills backend svarar;
- den visuella presentationsstrategin får därför skilja sig mellan
interaktionerna;
- vänteläge, felhantering och serverrespons ska höra till uppgiften och det
delade statusflödet, inte dupliceras per kontroll;
- kortlayouten får inte strukturellt förutsätta att knapparna alltid finns.
Att ta bort statusknapparna senare ska inte kräva ändringar i status-API,
dragmekanik, rollback eller task-state. Statusarkitekturen får inte vara kopplad
till att knapparna finns kvar.
## Vänteläge
När statusanropet pågår ska det optimistiskt flyttade kortet tonas ned lätt.
Ingen text som `Flyttar…` och ingen spinner krävs i första versionen.
Under vänteläget ska just detta kort inte kunna:
- dras igen;
- initiera en ny statusändring;
- ändra ansvarig.
Övriga kort ska förbli interaktiva.
Flera olika kort får ha statusanrop pågående samtidigt. Låsning, nedtoning,
rollback och fel hanteras per task-id.
## Fel och återställning
Vid ett misslyckat statusanrop ska:
- hela den tidigare task-versionen återställas;
- kortet återgå till ursprungskolumnen;
- tidigare ansvarig återställas;
- nedtoningen tas bort;
- felet visas lokalt på kortet;
- målkolumnen inte behålla någon tillfällig markering.
Tidigare klientdata ska inte delvis blandas med det misslyckade optimistiska
tillståndet. Ett fel på ett kort ska inte blockera resten av brädan.
## Serverrespons
Vid lyckat statusanrop ska frontend alltid ersätta den optimistiska uppgiften
med hela serverresponsen.
Det gäller även om serverresponsen skiljer sig från frontendens antagande vad
gäller exempelvis:
- status;
- ansvarig;
- andra returnerade task-fält.
Servern är slutlig sanning.
## Dragyta
Kortets icke-interaktiva yta ska fungera som dragyta. Knappar, select och andra
interaktiva element ska inte initiera dragning.
Implementation får avgöra sensoruppsättning, aktiveringströskel samt avstånd,
fördröjning och tolerans. Vanliga klick och små fingerrörelser får inte
oavsiktligt starta dragning, och kortets interaktiva kontroller ska fungera
normalt.
Dragmekaniken ska implementeras så att ett separat draghandtag senare kan
införas utan att statusoperation, API-anrop, rollback eller task-state behöver
ändras. Det bör räcka att flytta bibliotekets draglisteners och tillhörande
attribut från kortets rot till handtaget.
## Målkolumner
Kolumnerna behöver ingen stark eller permanent drop-markering. Den kolumn som
kortet befinner sig över kan vid behov få en mycket diskret hover-effekt,
exempelvis:
- en svag bakgrundsförändring;
- en tunn kant;
- annan lågmäld visuell återkoppling.
Feature 6 ska inte införa stora färgade drop-zoner eller en generell redesign
av brädan. Om manuell verifiering visar att ingen markering behövs kan även den
diskreta hover-effekten utelämnas.
## Drop i samma kolumn
Om ett kort släpps i kolumnen som motsvarar dess nuvarande status ska
operationen vara no-op.
Det innebär:
- inget API-anrop;
- ingen statusändring;
- ingen ändring av ordning;
- inget vänteläge;
- inget felmeddelande.
## Avbruten dragning
Om en dragning avbryts eller avslutas utanför en giltig målkolumn ska
operationen vara no-op. Kortet ska återgå till sin normala position utan
API-anrop eller felindikering.
## Desktop och touch
Desktop är det primära användningsfallet för Feature 6.
Touch ska fungera på en rimlig grundnivå, men featuren ska inte införa en
särskild mobil Kanban-design. Brädans befintliga responsiva layout ska
behållas. Feature 6 ska inte införa horisontell scrollning. På smala skärmar
får kolumnerna fortsätta använda repositoryts nuvarande responsiva layout,
även om de staplas vertikalt.
Implementation får avgöra sensoruppsättning, aktiveringsvillkor, eventuell
`touch-action`, collision detection och drag-overlay. Valen måste bevara normal
vertikal scrollning på mobil och får inte göra interaktiva kortkontroller
svåranvända.
Draglogiken ska:
- identifiera mål genom status, inte genom en fast skärmposition;
- inte förutsätta att kolumnerna ligger horisontellt;
- hållas separerad från layout-CSS;
- kunna fortsätta fungera om kolumnlayouten senare ändras.
Om manuell verifiering visar att dragning mellan staplade kolumner fungerar
dåligt kan mobilbeteendet ändras senare utan att status- eller rollbacklogiken
görs om. Statusknapparna finns kvar som alternativ, särskilt där dragning är
opraktisk.
## Tangentbord och tillgänglighet
Tangentbordsstyrd drag-and-drop ingår inte som grundkrav i Feature 6.
Statusknapparna ska fortsatt ge en fungerande tangentbordsväg för
statusändring. Drag-and-drop får därför inte vara den enda möjliga vägen.
Feature 6 ska ändå uppfylla grundläggande tillgänglighetskrav:
- interaktiva kontroller ska fortsatt gå att nå med tangentbord;
- ett upptaget kort ska inte kunna aktiveras igen;
- fokus ska inte tappas oförklarligt efter lyckad operation eller rollback;
- begripliga etiketter ska bevaras;
- dragbibliotekets standard-ARIA får användas;
- ingen omfattande speciallösning för tangentbordsdragning ska byggas.
Förbättrat tangentbordsstöd för själva dragningen kan införas i en senare
uppdatering.
## Gemensamt statusflöde
Frontend ska ha ett gemensamt, kontrolloberoende statusflöde för den
underliggande statusändringen.
Det delade flödet ska ansvara för:
- kontroll av pågående operation för task-id;
- requestformat;
- aktiv användares id vid behov;
- per-kort-vänteläge;
- ersättning med serverrespons;
- lokalt statusfel.
Drag-and-drop-flödet ska därutöver beräkna den optimistiska task-versionen,
spara rollback-värdet och återställa hela den tidigare uppgiften vid fel.
Statusknapparna ska inte göra en optimistisk flytt.
Drag-and-drop och statusknappar är separata sätt att ange målstatus till det
delade flödet, men får använda olika visuell presentationsstrategi.
Tilldelningskontrollen ska återanvända samma per-kort-låsning så att status och
tilldelning inte kan ändras samtidigt på samma uppgift.
## Frontendtester
Frontendtesterna verifierar beteende och state utan att förutsätta fysisk
layout eller exakta pointer-koordinater i jsdom. Dragadaptern mockas i
brädtesterna, medan den bibliotekoberoende mappningen från draghändelse till
task-id och målstatus testas separat.
Testerna täcker bland annat:
- korrekt statusanrop och optimistisk flytt till en annan kolumn;
- låsning och nedtoning per task-id medan anropet pågår;
- att andra kort kan ha samtidiga operationer;
- automatisk optimistisk tilldelning till aktiv användare;
- att en befintlig ansvarig behålls;
- att hela serverresponsen ersätter det optimistiska värdet;
- fullständig rollback och lokalt fel vid misslyckande;
- no-op för samma status, avbruten dragning och ogiltigt mål;
- att statusknapparnas befintliga serverbekräftade beteende är bevarat.
Totalt passerar 44 frontendtester. TypeScript-kompileringen och Vites
produktionsbygge passerar också.
## Backendtester
Backend ändrades inte. Feature 5:s befintliga tester fortsätter därför att
utgöra verifiering av:
- direkta statusövergångar;
- idempotens;
- automatisk tilldelning;
- bevarad befintlig ansvarig;
- statusvalidering;
- statusberoende tilldelningsregler;
- oförändrade övriga task-fält.
## Manuell verifiering
Manuell browserverifiering är genomförd. Följande verifierades:
- drag-and-drop mellan statuskolumner fungerar;
- kortet flyttas optimistiskt och tonas ned under statusanropet;
- en otilldelad uppgift som flyttas till Pågående får aktiv användare som
ansvarig;
- en befintlig ansvarig behålls;
- serverns svar ersätter det optimistiska värdet;
- statusknapparna fungerar fortsatt;
- ett blockerat statusanrop visar
`Det gick inte att ändra status. Försök igen.`;
- kortet återställs till ursprungskolumnen vid fel;
- tidigare ansvarig återställs, nedtoningen försvinner och kortet blir
interaktivt igen;
- övriga kort förblir interaktiva under operationen.
## Dokumentation
Feature 6 ska dokumenteras i:
```text
docs/features/006-task-drag-and-drop.md
```
Vid implementation ska även följande uppdateras när det är relevant:
```text
README.md
docs/architecture.md
docs/roadmap.md
```
Roadmapen markerar Feature 6 som `Klar` efter verifiering och merge.
Ett nytt ADR behövs endast om biblioteksvalet bedöms vara ett övergripande,
långlivat frontendbeslut som påverkar fler delar av applikationen än Feature
6. Om `dnd-kit` endast används lokalt för denna feature bör beslutet normalt
dokumenteras i feature- och arkitekturdokumentationen.
## Acceptanskriterier
Feature 6 är klar när:
- kort kan dras mellan olika statuskolumner;
- dragningen använder Feature 5:s status-API;
- kortet flyttas optimistiskt till målkolumnen;
- kortet tonas ned under serveranropet;
- samma kort är låst för status, dragning och tilldelning under anropet;
- andra kort förblir interaktiva;
- otilldelad uppgift till Pågående använder aktiv användares id;
- befintlig ansvarig behålls;
- serverresponsen ersätter det optimistiska tillståndet;
- fel återställer hela tidigare task-versionen;
- kortet återgår till ursprungskolumnen vid fel;
- felet visas lokalt på kortet;
- drop i samma kolumn är no-op;
- avbruten dragning är no-op;
- ingen manuell eller persistent kortordning har införts;
- statusknapparna fungerar fortsatt men är arkitekturellt frikopplade;
- statusknapparna förblir serverbekräftade medan drag-and-drop är optimistisk;
- statusknapparna kan tas bort senare utan att drag- eller statuslogiken byggs
om;
- kortets icke-interaktiva yta fungerar som dragyta;
- interaktiva kortkontroller initierar inte dragning;
- ett senare draghandtag kan införas utan ändring av statusflödet;
- normal vertikal scrollning på mobil bevaras;
- ingen horisontell scrollning har införts;
- desktop fungerar väl;
- touch fungerar på rimlig grundnivå;
- tangentbordsdragning inte krävs;
- statusändring fortsatt är möjlig med tangentbord genom statusknapparna;
- frontendtesterna täcker centrala stateövergångar och felfall;
- manuell verifiering täcker dragkänsla, touch, layout och rollback;
- backend är oförändrad om inget konkret behov av justering hittas;
- relevant dokumentation är uppdaterad.
## Implementationsprinciper
Vid implementationen användes följande dokumentation som tekniskt underlag:
```text
AGENTS.md
README.md
docs/architecture.md
docs/development.md
docs/roadmap.md
docs/decisions/
docs/features/004-task-assignment.md
docs/features/005-task-status.md
```
Relevant frontendkod och tester granskades särskilt avseende:
- aktuell React-version;
- frontendens installerade beroenden;
- aktuell officiell dnd-kit-dokumentation;
- vilka dnd-kit-paket som är aktuella respektive legacy;
- dnd-kit-lösningens kompatibilitet med React-versionen;
- påverkan på Vitest/jsdom och React Testing Library;
- aktuell task-typ;
- brädans kolumnstruktur;
- uppgiftskortets komponentstruktur;
- befintliga statusknappar;
- statusanropets requestformat;
- hur aktiv användare representeras;
- hur tasks ersätts i state;
- det gemensamma vänteläget per kort;
- status- och tilldelningsfel;
- tilldelningskontrollens inaktiveringslogik;
- aktuell teststil;
- vilka pointer- och draghändelser testmiljön stödjer.
Repositoryts faktiska kod och dokumentation har företräde framför antaganden i
denna featurebeskrivning.
Kod, tester och relevant dokumentation ska uppdateras tillsammans.
Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
instruktion.
## Relaterade commits
- Feature-commit:
`c3c64482c062f144fd6cb6036e3c9db0afa5ec1e`
- Merge-commit till `main`:
`2696195e741c155a197ae9838d1938bdf2148cc2`

View File

@ -0,0 +1,442 @@
# Feature 7 Radera uppgift
## Status
Färdig och mergad till main.
## Bakgrund
HemHub stödjer skapande, visning, tilldelning, statusändring och drag-and-drop
av uppgifter. Det saknas möjlighet att ta bort uppgifter som inte längre är
relevanta eller som skapats av misstag.
Feature 7 inför permanent radering av en enskild uppgift. Radering hålls
separat från generell redigering så att det destruktiva flödet, dess
bekräftelse och felhantering kan implementeras och verifieras isolerat.
## Mål
Feature 7 ska:
- införa ett backend-API för permanent radering av en uppgift;
- låta användaren initiera radering från uppgiftskortet;
- kräva en tydlig bekräftelse före radering;
- ta bort kortet från brädan först efter serverbekräftelse;
- återanvända befintlig låsning och felhantering per task-id;
- fungera tillsammans med statusändring, tilldelning och drag-and-drop utan
parallella state- eller requestflöden.
## Omfattning
Feature 7 omfattar endast permanent radering av en befintlig uppgift.
En uppgift får raderas oavsett om dess status är `WAITING`, `IN_PROGRESS` eller
`COMPLETED`. Uppgiftens ansvariga användare och aktiv browseranvändare påverkar
inte möjligheten att radera. Det lokala användarvalet är inte autentisering
eller behörighetskontroll.
## Avgränsningar
Feature 7 ska inte införa:
- mjuk radering, papperskorg, återställning eller undo;
- arkivering, versions-, status- eller poänghistorik;
- generell redigering;
- batchradering eller markering av flera kort;
- radering av användare;
- behörigheter eller ägarskap;
- realtidsuppdatering mellan browsers;
- automatisk gallring;
- persistent kortordning;
- nya relationer till uppgifter;
- generell cascade-logik för framtida modeller.
## Permanent radering
Radering är permanent. När användaren har bekräftat raderingen tas uppgiften
bort ur databasen. Ingen `deleted`-flagga, `deletedAt`, dold arkiveringsmodell
eller annan form av mjuk radering införs.
HemHub är en liten familjeapplikation utan revisionslogg, papperskorg eller
återställningsflöde. En mjukraderingsmodell skulle därför öka komplexiteten
utan ett tydligt nuvarande produktvärde.
Om framtida features för återkommande uppgifter eller poänghistorik behöver
bevara information efter radering ska deras datamodeller och raderingsregler
beslutas i respektive feature.
## Tillåtna statusar
Samtliga uppgifter får raderas oavsett status. Det krävs inte att en
`IN_PROGRESS`-uppgift först flyttas till `WAITING`, och en `COMPLETED`-uppgift
behandlas inte annorlunda än övriga uppgifter.
Bekräftelseflödet är samma för alla statusar. Ingen extra varning eller
ytterligare bekräftelse införs för pågående uppgifter.
## Raderingskontroll
Raderingskontrollen ska visas som en diskret sopkorgsikon direkt på det
befintliga uppgiftskortet, uppe till höger i ett eget åtgärdsområde. Feature 7
inför inget kompakt eller expanderat kortläge.
Kontrollen ska:
- visas på befintliga uppgiftskort;
- ha en tillgänglig etikett som identifierar uppgiften, exempelvis
`Radera Töm diskmaskinen`;
- öppna bekräftelsedialogen;
- inte starta drag-and-drop;
- ha en rimlig klickyta för touch;
- ha neutral stil i normalläge och tydlig hover- och fokusmarkering;
- vara inaktiverad när samma uppgift har en pågående operation.
Sopkorgen implementeras som inline-SVG enligt projektets befintliga
ikonmönster. Feature 7 lägger inte till något ikonbibliotek.
Den destruktiva visuella betoningen ska primärt ligga i
bekräftelsedialogen. Kontrollen ska kunna flyttas till en framtida meny eller
detaljdialog utan att backend-API eller delete-flödet behöver göras om.
## Bekräftelsedialog
Radering bekräftas i en separat delete-modal. Den ska följa beteendemönstret i
`CreateTaskModal`, men Feature 7 inför ingen gemensam modalkomponent och gör
ingen bred modalrefaktorering. Dialogen ska visa:
- rubriken `Radera uppgift?`;
- uppgiftens titel;
- tydlig information om att raderingen är permanent;
- knappen `Avbryt`;
- den destruktivt utformade knappen `Radera`.
Exempel:
> Är du säker på att du vill radera **Töm diskmaskinen**? Uppgiften raderas
> permanent och kan inte återställas.
Delete-modalen har inget stängningskryss. Innan delete-anropet har startat ska
den kunna stängas med `Avbryt`, Escape eller klick på bakgrunden. Under
pågående delete-anrop blockeras samtliga stängningsvägar.
Dialogen ska följa projektets befintliga modalstruktur och fokusprinciper.
`Avbryt` får initialt fokus när dialogen öppnas; den destruktiva knappen
`Radera` får inte initialt fokus. Båda knapparna ska vara
tangentbordsåtkomliga.
## Backend-API
Radering sker genom:
```http
DELETE /api/tasks/{taskId}
```
### Lyckad radering
När uppgiften finns och raderas svarar backend med `204 No Content` utan body.
### Okänd uppgift
Om uppgiften inte finns svarar backend med `404 Not Found` och projektets
befintliga felformat:
```text
TASK_NOT_FOUND
```
Det gäller även om samma task-id tidigare har raderats. Ett andra delete-anrop
mot samma id ger därför `404 TASK_NOT_FOUND`.
### Ogiltigt task-id
Ett task-id som inte kan tolkas som UUID ger `400 Bad Request` med repositoryts
nuvarande requestfel och felformat. Den befintliga felkoden
`INVALID_TASK_ASSIGNMENT` ändras inte inom Feature 7. Feature 7 inför ingen
separat felmodell för UUID-fel.
### Konflikter och transaktion
Radering är tillåten för samtliga statusar och oavsett ansvarig. Feature 7 har
därför inget domänfall som ger `409 Conflict`.
Raderingen ska ske inom backendens normala transaktionsgräns och endast ta bort
den identifierade uppgiften. Den får inte ändra eller radera ansvarig
användare, andra användare eller andra uppgifter.
## Databas
Feature 7 raderar raden permanent ur tabellen `task`.
Nuvarande datamodell har inga dokumenterade beroendeentiteter som kräver en ny
migrering eller särskild cascade-policy. Den befintliga relationen från
`task.assignee_id` till `app_user.id` ska verifieras så att den inte hindrar
radering av uppgiften. Den ansvariga användaren ska finnas kvar.
Ingen databasmigrering ska skapas om det faktiska schemat redan stödjer
radering. Framtida relationer till uppgifter får definiera sin delete-policy
när de införs.
## Frontendens uppdateringsstrategi
Frontend använder serverbekräftad radering. När användaren bekräftar ska
frontend:
1. markera uppgiften som upptagen;
2. behålla kortet i dess nuvarande kolumn;
3. behålla bekräftelsedialogen öppen;
4. skicka delete-anropet;
5. vänta på serverns svar;
6. vid `204 No Content` ta bort uppgiften ur den lokala task-listan;
7. stänga dialogen;
8. frigöra låsningen för task-id.
Kortet ska inte tas bort optimistiskt. Ingen rollback-modell behövs eftersom
kortet ligger kvar under anropet.
## Vänteläge
När delete-anropet pågår ska:
- bekräftelsedialogen ligga kvar öppen;
- `Radera` och `Avbryt` vara inaktiverade;
- Escape och bakgrundsklick inte kunna stänga dialogen;
- kortet ligga kvar i sin kolumn och tonas ned lätt;
- alla interaktiva kontroller på samma kort vara inaktiverade.
Ingen spinner eller text som `Raderar…` krävs.
## Låsning och samspel med andra operationer
Delete ska återanvända den befintliga låsningen per task-id. När uppgiften har
en pågående status-, tilldelnings- eller dragoperation ska radering inte kunna
initieras.
När delete-anropet pågår ska samma uppgift inte kunna dras, ändra status, ändra
ansvarig, öppna en ny raderingsdialog eller skicka ytterligare delete-anrop.
Andra kort ska förbli interaktiva och kunna ha egna samtidiga operationer.
Feature 7 inför inget globalt vänteläge, separat delete-lås eller parallell
requestmodell.
## Felhantering
### Vanliga delete-fel
Vid nätverksfel, serverfel eller annat vanligt delete-fel ska:
- kortet ligga kvar oförändrat;
- dialogen ligga kvar öppen;
- vänteläget avslutas;
- kontrollerna aktiveras igen;
- felmeddelandet
`Det gick inte att radera uppgiften. Försök igen.` visas i dialogen;
- användaren kunna försöka igen eller avbryta.
Delete-felet ska inte blandas med status- eller tilldelningsfel på kortet.
### `404 TASK_NOT_FOUND`
Om backend svarar med `404 TASK_NOT_FOUND` betraktas kortet som inaktuellt.
Frontend ska då ta bort uppgiften ur den lokala task-listan, stänga dialogen
och frigöra låsningen utan att visa det generella delete-felet.
Frontendens generella `ApiError`-typ utökas med ett valfritt `code`. Delete-
flödet ska använda `code === "TASK_NOT_FOUND"` och status `404` för detta fall
och får inte tolka meddelandetexten.
Andra typer av `404` ska inte behandlas som en redan borttagen uppgift.
## Frontendtester
Frontendtesterna ska minst verifiera:
- att sopkorgsknappen visas direkt på det befintliga uppgiftskortet;
- att ikonen är inline-SVG och inte kräver ett ikonbibliotek;
- tillgänglig etikett och rätt uppgift i bekräftelsedialogen;
- information om permanent radering;
- initialt fokus på `Avbryt`, aldrig på `Radera`;
- att modalen saknar stängningskryss;
- stängning med `Avbryt`, Escape och bakgrundsklick före anrop;
- `DELETE /api/tasks/{taskId}` först efter bekräftelse;
- att kort och dialog ligger kvar under anropet;
- att dialogen inte kan stängas medan anropet pågår;
- gemensam låsning för status, tilldelning, drag och radering;
- att andra kort förblir interaktiva;
- blockering av dubbla delete-anrop;
- att `204 No Content` tar bort rätt kort och stänger dialogen;
- att vanliga fel behåller kort och dialog samt kan återförsökas;
- att `404 TASK_NOT_FOUND` tar bort det inaktuella kortet;
- att ett annat `404`-fel inte feltolkas som `TASK_NOT_FOUND`;
- att raderingskontrollen inte bryter drag-and-drop;
- grundläggande tangentbordsfokus och knappaktivering.
Testerna ska verifiera beteende och state, inte exakt ikonplacering, färg eller
pixelmått.
## Backendtester
Backendtesterna ska minst verifiera:
- radering i `WAITING`, `IN_PROGRESS` och `COMPLETED`;
- `204 No Content` utan body;
- att den raderade uppgiften inte längre finns i `GET /api/tasks`;
- att andra uppgifter och den ansvariga användaren finns kvar oförändrade;
- `404 TASK_NOT_FOUND` för okänt id och ett andra delete-anrop;
- projektets befintliga `400`-fel för ogiltigt UUID-format.
Testerna ska följa repositoryts befintliga integrationsteststil.
## Manuell verifiering
Följande ska verifieras manuellt:
1. Sopkorgsknappens placering uppe till höger i ett eget åtgärdsområde,
neutrala normalläge, touchyta, hover, fokus och tillgängliga etikett.
2. Radering av uppgifter i samtliga tre statusar.
3. Initialt fokus på `Avbryt`, inget stängningskryss samt avbrytande med knapp,
Escape och bakgrundsklick före anrop.
4. Rätt titel och information om permanent radering.
5. Titel nära maximal längd.
6. Blockering av dubbla delete-anrop.
7. Vänteläge för kort och dialog under fördröjt svar.
8. Låsning av drag, status, tilldelning och ny radering för samma kort.
9. Fortsatt interaktion med andra kort.
10. Vanligt serverfel, visat felmeddelande och nytt försök.
11. `404 TASK_NOT_FOUND` och lokal borttagning av inaktuellt kort.
12. Desktop- och mobilbredd samt tangentbordsaktivering.
13. Omladdning efter lyckad radering så att uppgiften inte återkommer.
## Dokumentation
Feature 7 dokumenteras i:
```text
docs/features/007-task-deletion.md
```
Vid implementation ska `README.md`, `docs/architecture.md` och
`docs/roadmap.md` uppdateras när det är relevant.
Roadmapen ska markera Feature 7 som `Klar` först efter implementation,
automatiska tester, manuell verifiering och merge.
Ett nytt ADR behövs inte för permanent radering. Beslutet gäller den nuvarande
task-livscykeln och etablerar inte en generell raderingspolicy för framtida
entiteter.
## Acceptanskriterier
Feature 7 är klar när:
- en uppgift kan raderas permanent med `DELETE /api/tasks/{taskId}`;
- lyckad radering ger `204 No Content`;
- okänd eller redan raderad uppgift ger `404 TASK_NOT_FOUND`;
- ogiltigt UUID-format följer befintlig felhantering;
- alla tre statusar kan raderas oavsett ansvarig eller aktiv användare;
- radering kräver en egen bekräftelsedialog;
- dialogen visar rätt titel och anger att raderingen inte kan återställas;
- `Avbryt` får initialt fokus och `Radera` får inte initialt fokus;
- modalen saknar stängningskryss och blockerar alla stängningsvägar under
anropet;
- en diskret inline-SVG-sopkorg visas direkt på befintliga uppgiftskort;
- raderingskontrollen startar inte drag;
- kortet tas bort först efter serverbekräftelse;
- samma task-id låses för status, tilldelning, drag och ny radering;
- andra kort förblir interaktiva;
- vanliga fel behåller kort och dialog och kan återförsökas;
- `404 TASK_NOT_FOUND` tar bort det inaktuella lokala kortet;
- ingen mjukradering, återställningsmodell eller onödig migrering införs;
- backend- och frontendtester täcker centrala flöden;
- manuell verifiering genomförs;
- relevant dokumentation uppdateras.
## Implementerad lösning
Backendens task-controller och task-service har utökats med fysisk radering via
`DELETE /api/tasks/{taskId}`. Servicen hämtar först uppgiften för att
återanvända `TaskNotFoundException` och raderar därefter entiteten inom en
transaktion. Ingen entitet, exception handler eller Flyway-migrering behövde
ändras.
Frontendens `TaskBoard` använder samma per-task-lås som status- och
tilldelningsoperationerna. Radering är serverbekräftad: kortet och dialogen
ligger kvar medan anropet pågår, och kortet tas bort först efter `204 No
Content`. Endast ett svar med både status `404` och felkoden
`TASK_NOT_FOUND` tar bort ett känt inaktuellt kort. Övriga fel behåller kortet
och dialogen så att användaren kan försöka igen.
`TaskCard` har inget kompakt eller expanderat läge. En neutral
inline-SVG-knapp ligger direkt i kortets övre högra åtgärdsområde och stoppar
pointer-händelsen innan den når dragytan. Den separata delete-modalen följer
`CreateTaskModal`-mönstret utan en gemensam modalabstraktion. `Avbryt` får
initialt fokus, modalen saknar stängningskryss och samtliga stängningsvägar
blockeras under delete-anropet.
Frontendens generella `ApiError` innehåller nu ett valfritt `code`. Den
befintliga backendhanteringen av felaktigt UUID är oförändrad och returnerar
fortsatt `400 INVALID_TASK_ASSIGNMENT`.
## Tester och verifiering
Automatiskt verifierat:
- backendens fullständiga testsvit: 47 tester passerade;
- frontendens fullständiga testsvit: 49 tester passerade;
- frontendens produktionsbygge och TypeScript-kompilering passerade;
- `git diff --check` passerade.
Backendtesterna ligger i den separata integrationstestklassen
`TaskDeletionApiTest`. Frontendens delete-flöden testas tillsammans med övriga
brädbeteenden i `App.test.tsx`.
Manuell browserverifiering genomfördes mot lokalt körande frontend och backend
i Chrome. Följande verifierades:
- permanent radering och kvarstående borttagning efter omladdning för
`WAITING`, `IN_PROGRESS` och `COMPLETED`;
- lång titel, radbrytning och korrekt uppgiftstitel i dialogen;
- initialt fokus på `Avbryt`, tabb-ordning till `Radera`, Escape och
bakgrundsklick före anrop samt avsaknad av stängningskryss;
- fördröjd delete-respons med kvarvarande och nedtonat kort, öppen låst modal
och inaktiverade stängningsvägar;
- gemensam låsning av drag, status, ansvarig och ny radering för samma kort,
samtidigt som andra kort förblev interaktiva;
- snabbt dubbelklick på `Radera` utan dubbla delete-anrop;
- vanligt serverfel där kort och modal låg kvar, felet visades och ett nytt
försök lyckades;
- `404 TASK_NOT_FOUND`, där det inaktuella kortet togs bort lokalt;
- neutral sopkorgsknapp med 40 × 40 pixlars klickyta, inline-SVG och
pointer-hantering som inte startade drag;
- desktopbredd 1440 × 1000 och mobilbredd 390 × 844 utan horisontell
scrollning.
Inga problem upptäcktes i Feature 7-flödena.
## Relaterade commits
- Feature-commit: `f296d15`
- Merge-commit: `5df0146`
## Implementationsprinciper
Före implementation ska Codex läsa:
```text
AGENTS.md
README.md
docs/architecture.md
docs/development.md
docs/roadmap.md
docs/decisions/
docs/features/005-task-status.md
docs/features/006-task-drag-and-drop.md
```
Codex ska även läsa relevant backendkod, frontendkod och befintliga tester.
Repositoryts faktiska kod, tester och dokumentation har företräde framför
antaganden i detta dokument.
Implementation, tester och relevant dokumentation ska uppdateras tillsammans.
Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
instruktion.

View File

@ -34,20 +34,28 @@ Följande statusvärden används:
## Nuvarande läge
Feature 02 är klara. Den aktuella applikationen har:
Feature 07 är klara och finns på `main`. 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, status och poäng;
- skapande och listning av uppgifter;
- valfri tilldelning av högst en ansvarig användare per uppgift;
- tilldelning och byte av ansvarig i samtliga statusar;
- borttagning av ansvarig i `WAITING` och `COMPLETED`;
- backendstyrda statusändringar mellan `WAITING`, `IN_PROGRESS` och `COMPLETED`;
- automatisk tilldelning till aktiv användare när en otilldelad uppgift påbörjas;
- drag-and-drop mellan statuskolumner med optimistisk flytt och rollback;
- serverbekräftad permanent radering med bekräftelsedialog;
- en bräda med Väntande, Pågående och Klart;
- nya uppgifter som alltid skapas med status `WAITING`.
Det finns ännu inga uppgiftstilldelningar, statusändringar, drag-and-drop,
redigeringar, raderingar, deadlines eller återkommande uppgifter.
Nuvarande användarval är inte autentisering.
Tilldelning och status är separata egenskaper; tilldelningsflödet ändrar inte
uppgiftens status. Alla direkta statusövergångar är tillåtna och
`IN_PROGRESS` kräver ansvarig. Det finns ännu ingen redigering, deadline eller
återkommande uppgift. Nuvarande användarval är inte autentisering.
**Feature 3 Uppgiftspoäng är pågående.**
**Feature 8 Redigera uppgift är nästa planerade produktfeature.**
## Featureöversikt
@ -56,11 +64,11 @@ 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 | 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 |
| 7 Radera uppgift | Planerad | 2 | Bekräftad radering |
| 3 Uppgiftspoäng | Klar | 2 | Poäng på uppgifter |
| 4 Tilldelning | Klar | 12 | Valfri ansvarig användare |
| 5 Statusändring | Klar | 4 | Backendstyrda statusövergångar |
| 6 Drag-and-drop | Klar | 5 | Kortflytt via status-API |
| 7 Radera uppgift | Klar | 2 | Bekräftad permanent radering |
| 8 Redigera uppgift | Planerad | 3 | Titel, beskrivning och poäng |
| 9 Deadline | Planerad | 2 | Valfri deadline och förseningsmarkering |
| 10 Sökning och filtrering | Planerad | 2; 4 för ansvarig; 9 för deadline | Sökning och filter på brädan |
@ -109,7 +117,7 @@ interaktiv brädhantering införs.
### Feature 3 Uppgiftspoäng
**Status:** Pågående
**Status:** Klar
**Beroenden:** Feature 2
@ -130,7 +138,7 @@ databasen har inget permanent defaultvärde.
### Feature 4 Tilldelning av uppgifter
**Status:** Planerad
**Status:** Klar
**Beroenden:** Feature 1 och Feature 2
@ -141,17 +149,14 @@ databasen har inget permanent defaultvärde.
- visa ansvarig på uppgiftskort;
- kunna ändra ansvarig på en befintlig uppgift.
En väntande uppgift får vara tilldelad eller otilldelad. Tilldelning införs före
statusändring eftersom en pågående uppgift senare måste ha en ansvarig.
**Öppna frågor:**
- om en uppgift ska ha endast en ansvarig;
- hur borttagna användare ska hanteras när användarradering införs.
En väntande uppgift får vara tilldelad eller otilldelad och har högst en
ansvarig. Tilldelning införs före statusändring eftersom en pågående uppgift
senare måste ha en ansvarig. Hur borttagna användare ska hanteras är fortsatt
öppet tills användarradering införs.
### Feature 5 Statusändring och statusregler
**Status:** Planerad
**Status:** Klar
**Beroenden:** Feature 4
@ -164,17 +169,17 @@ statusändring eftersom en pågående uppgift senare måste ha en ansvarig.
`IN_PROGRESS` kräver en ansvarig användare. Statusflödet införs före
drag-and-drop så att affärsregeln och API:t kan verifieras utan att samtidigt
bygga en komplex interaktion.
bygga en komplex interaktion. Feature 5 återanvänder Feature 4:s
tilldelningsmodell och särskilda API för ansvarig; statusändring sker i ett
separat statusflöde.
**Öppna frågor:**
- vad som sker när en otilldelad uppgift sätts till `IN_PROGRESS`;
- om aktiv användare ska föreslås automatiskt;
- vad som sker om ansvarig tas bort från en pågående uppgift.
En otilldelad uppgift som sätts till `IN_PROGRESS` tilldelas automatiskt den
aktiva browseranvändaren. En befintlig ansvarig behålls. Ansvarig kan bytas men
inte tas bort medan uppgiften är pågående.
### Feature 6 Drag-and-drop
**Status:** Planerad
**Status:** Klar
**Beroenden:** Feature 5
@ -188,10 +193,13 @@ bygga en komplex interaktion.
Drag-and-drop kommer efter det enklare statusflödet för att återanvända
verifierade backendregler.
**Öppna frågor:**
- optimistisk eller serverbekräftad uppdatering;
- exakt tilldelningsflöde vid flytt till Pågående.
Drag-and-drop använder en kontrollerad optimistisk flytt. Vid fel återställs
hela den tidigare task-versionen. En otilldelad uppgift som dras till Pågående
använder Feature 5:s befintliga automatiska tilldelning till aktiv användare.
Serverns fullständiga task-respons ersätter alltid det optimistiska värdet.
Statusknapparna förblir tills vidare serverbekräftade. Implementation och
automatisk samt manuell verifiering är genomförda, och featuren är mergad till
`main`.
## Fas 2 Hantering av uppgifter
@ -200,7 +208,7 @@ modellen och statusreglerna finns.
### Feature 7 Radera uppgift
**Status:** Planerad
**Status:** Klar
**Beroenden:** Feature 2
@ -213,9 +221,13 @@ modellen och statusreglerna finns.
Radering hålls separat från redigering så att databorttagning och dess
konsekvenser kan verifieras isolerat.
**Öppen fråga:**
- permanent radering eller mjuk radering.
Feature 7 använder permanent fysisk radering genom
`DELETE /api/tasks/{taskId}`. En bekräftelsemodal visas före anropet och
frontend behåller kortet tills backend har bekräftat raderingen. Operationen
använder samma låsning per task-id som status, tilldelning och drag-and-drop.
Ett `404 TASK_NOT_FOUND` tar bort ett känt inaktuellt lokalt kort.
Implementation samt automatisk och manuell verifiering är genomförda, och
featuren är mergad till `main`.
### Feature 8 Redigera uppgift
@ -421,7 +433,6 @@ Nuvarande aktiva användarval är uttryckligen inte autentisering.
## Öppna tvärgående frågor
- 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?
- Hur ska användare senare kunna redigeras eller raderas, särskilt när de är
@ -432,5 +443,16 @@ Nuvarande aktiva användarval är uttryckligen inte autentisering.
## Ändringshistorik
- 2026-07-27: Feature 7 verifierades och mergades. Permanent,
serverbekräftad radering infördes, och Feature 8 blev nästa planerade
produktfeature.
- 2026-07-27: Feature 6 verifierades och mergades. Optimistisk drag-and-drop
med full rollback infördes, och Feature 7 blev nästa planerade
produktfeature.
- 2026-07-27: Feature 5 verifierades och mergades. Backendstyrda
statusövergångar, automatisk tilldelning vid påbörjande och statusberoende
tilldelningsregler infördes. Feature 6 blev nästa planerade produktfeature.
- 2026-07-26: Feature 3 och Feature 4 markerades som klara efter verifiering och
merge. Feature 5 blev nästa planerade produktfeature.
- 2026-07-26: Roadmapen etablerades. Feature 02 markerades som klara, Feature
316 planerades och Feature 17 markerades som villkorad.

View File

@ -9,6 +9,8 @@
"test": "vitest run"
},
"dependencies": {
"@dnd-kit/dom": "0.5.0",
"@dnd-kit/react": "0.5.0",
"react": "19.2.8",
"react-dom": "19.2.8"
},

View File

@ -8,6 +8,12 @@ importers:
.:
dependencies:
'@dnd-kit/dom':
specifier: 0.5.0
version: 0.5.0
'@dnd-kit/react':
specifier: 0.5.0
version: 0.5.0(react-dom@19.2.8(react@19.2.8))(react@19.2.8)
react:
specifier: 19.2.8
version: 19.2.8
@ -115,6 +121,27 @@ packages:
resolution: {integrity: sha512-QxULHAm7cNu72w97JUNCBFODFaXpbDg+dP8b/oWFAZ2MTRppA3U00Y2L1HqaS4J6yBqxwa/Y3nMBaxVKbB/NsA==}
engines: {node: '>=20.19.0'}
'@dnd-kit/abstract@0.5.0':
resolution: {integrity: sha512-hi13iMJgjPX/KDYVKg5VeDIhmYiV6buc9bAX+tCLYf4QdyYjPbsXjn2sPo6m7fQ6SGJBEFgHJ2PemeKDUbwBaA==}
'@dnd-kit/collision@0.5.0':
resolution: {integrity: sha512-xUqRn3lS7oqLkT0AnnHS/STh/Czvwe1UapZFYiLbsUGxopMsQd4teaPCzPouOThoMdGEe+dHWjfqJl6t9iG4mQ==}
'@dnd-kit/dom@0.5.0':
resolution: {integrity: sha512-f2xFJp5SYQ8EW/Fbtaa8iBb66hpkWc7qa8vU826KW11/tb44sH+AisZnGtwOOTWTQ0GraqBDr5ixTErww+eKXw==}
'@dnd-kit/geometry@0.5.0':
resolution: {integrity: sha512-ubHQS1CiSDH8ssYH2xG5BnpwPSFP1tStXXjug7/Ba6qnQdu/EUH47l6QXKIksQnnanfVfDf0aGeevRxgZlj28A==}
'@dnd-kit/react@0.5.0':
resolution: {integrity: sha512-abQPLI8lmfVE+v/n+pqy5WFxrw6T2Yg0UQZsL78dp5DKci7dKTVDjvLWqvass+XTFtzJmsZEjk1NdqE6xG8Jiw==}
peerDependencies:
react: ^18.0.0 || ^19.0.0
react-dom: ^18.0.0 || ^19.0.0
'@dnd-kit/state@0.5.0':
resolution: {integrity: sha512-y7XbabQqjF58Lk8YmDQuR8l6QjN+Kh4qlGEjUvHuIeasLk1QP+9L5diXS98VMxQIivyMmUtX2//f+3N7qPJX4w==}
'@emnapi/core@1.11.1':
resolution: {integrity: sha512-RSvbQmHzdKzNsLYa/wHrbc3KN4sYLKAdPZxqiM2HATqv/SBk2/ENSHpvXGaLOMcsAyz0poEGqkmmKYG3OWiJEQ==}
@ -145,6 +172,9 @@ packages:
'@oxc-project/types@0.139.0':
resolution: {integrity: sha512-r9gHphtCs+1M7J0pw6Sn/hh/Wpa/iQrOOkrNAlVLF/gHq+/CJmHIWKKUUhdWjcD6CIa8idarspCsASiXCXvFUw==}
'@preact/signals-core@1.14.4':
resolution: {integrity: sha512-HNB6HYeYKhQbJ1aKl+YRjrS4+QWHLKX6qKoUsfS/m0vqzsVaEBiZiaKbG/e+NKk2ch5ALQr/ihWaMHxiCuuWHA==}
'@rolldown/binding-android-arm64@1.1.5':
resolution: {integrity: sha512-lZg8fqIv2v7FF237bwMgzGZEJvGL79/s5knJ/i6FmsGF4XXlzccZ4jb+TrFIxtSSxFtIpdsgrPZeMk1I9AFcyQ==}
engines: {node: ^20.19.0 || >=22.12.0}
@ -961,6 +991,45 @@ snapshots:
'@csstools/css-tokenizer@4.0.0': {}
'@dnd-kit/abstract@0.5.0':
dependencies:
'@dnd-kit/geometry': 0.5.0
'@dnd-kit/state': 0.5.0
tslib: 2.8.1
'@dnd-kit/collision@0.5.0':
dependencies:
'@dnd-kit/abstract': 0.5.0
'@dnd-kit/geometry': 0.5.0
tslib: 2.8.1
'@dnd-kit/dom@0.5.0':
dependencies:
'@dnd-kit/abstract': 0.5.0
'@dnd-kit/collision': 0.5.0
'@dnd-kit/geometry': 0.5.0
'@dnd-kit/state': 0.5.0
tslib: 2.8.1
'@dnd-kit/geometry@0.5.0':
dependencies:
'@dnd-kit/state': 0.5.0
tslib: 2.8.1
'@dnd-kit/react@0.5.0(react-dom@19.2.8(react@19.2.8))(react@19.2.8)':
dependencies:
'@dnd-kit/abstract': 0.5.0
'@dnd-kit/dom': 0.5.0
'@dnd-kit/state': 0.5.0
react: 19.2.8
react-dom: 19.2.8(react@19.2.8)
tslib: 2.8.1
'@dnd-kit/state@0.5.0':
dependencies:
'@preact/signals-core': 1.14.4
tslib: 2.8.1
'@emnapi/core@1.11.1':
dependencies:
'@emnapi/wasi-threads': 1.2.2
@ -990,6 +1059,8 @@ snapshots:
'@oxc-project/types@0.139.0': {}
'@preact/signals-core@1.14.4': {}
'@rolldown/binding-android-arm64@1.1.5':
optional: true
@ -1476,8 +1547,7 @@ snapshots:
dependencies:
punycode: 2.3.1
tslib@2.8.1:
optional: true
tslib@2.8.1: {}
typescript@7.0.2:
optionalDependencies:

View File

@ -1,7 +1,42 @@
import { cleanup, fireEvent, render, screen, waitFor, within } from '@testing-library/react'
import type { ReactNode } from 'react'
import { act, cleanup, fireEvent, render, screen, waitFor, within } from '@testing-library/react'
import { afterEach, beforeEach, expect, test, vi } from 'vitest'
import App from './App'
const dragAndDrop = vi.hoisted(() => ({
onTaskDrop: null as ((taskId: string, status: string) => void) | null,
disabledTaskIds: new Set<string>(),
}))
vi.mock('./TaskDragAndDrop', () => ({
TaskDragDropProvider: ({
children,
onTaskDrop,
}: {
children: ReactNode
onTaskDrop: (taskId: string, status: string) => void
}) => {
dragAndDrop.onTaskDrop = onTaskDrop
return children
},
useTaskDraggable: (taskId: string, disabled: boolean) => {
if (disabled) {
dragAndDrop.disabledTaskIds.add(taskId)
} else {
dragAndDrop.disabledTaskIds.delete(taskId)
}
return {
ref: () => {},
isDragging: false,
}
},
useTaskColumnDropTarget: () => ({
ref: () => {},
isDropTarget: false,
}),
}))
const users = [
{
id: 'd56b54dd-31b0-4d71-8a10-82464be59a61',
@ -22,6 +57,7 @@ const tasks = [
description: 'Bottenvåningen',
status: 'WAITING',
points: 7,
assignee: null,
createdAt: '2026-07-24T10:00:00Z',
},
{
@ -30,6 +66,7 @@ const tasks = [
description: null,
status: 'IN_PROGRESS',
points: 3,
assignee: { id: users[1].id, name: users[1].name },
createdAt: '2026-07-24T10:01:00Z',
},
{
@ -38,12 +75,15 @@ const tasks = [
description: null,
status: 'COMPLETED',
points: 5,
assignee: null,
createdAt: '2026-07-24T10:02:00Z',
},
]
beforeEach(() => {
window.localStorage.clear()
dragAndDrop.onTaskDrop = null
dragAndDrop.disabledTaskIds.clear()
})
afterEach(() => {
@ -171,7 +211,7 @@ test('brädan visar tre kolumner och grupperar hämtade uppgifter', async () =>
render(<App />)
await screen.findByText('Dammsuga')
const waiting = screen.getByRole('region', { name: 'Väntande' })
const waiting = await screen.findByRole('region', { name: 'Väntande' })
const inProgress = screen.getByRole('region', { name: 'Pågående' })
const completed = screen.getByRole('region', { name: 'Klart' })
@ -193,6 +233,13 @@ 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)
expect(screen.getByLabelText('Tilldela')).toHaveValue('')
expect(within(screen.getByLabelText('Tilldela')).getByRole('option', { name: 'Ingen' }))
.toBeInTheDocument()
expect(within(screen.getByLabelText('Tilldela')).getByRole('option', { name: 'Urban' }))
.toBeInTheDocument()
expect(within(screen.getByLabelText('Tilldela')).getByRole('option', { name: 'Anna' }))
.toBeInTheDocument()
})
test.each([
@ -246,6 +293,7 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
description: 'Köket',
status: 'WAITING',
points: 7,
assignee: { id: users[1].id, name: users[1].name },
createdAt: '2026-07-24T10:03:00Z',
}
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
@ -263,24 +311,675 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
target: { value: ' Köket ' },
})
fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: '7' } })
fireEvent.change(screen.getByLabelText('Tilldela'), { target: { value: users[1].id } })
fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
await waitFor(() =>
expect(screen.queryByRole('dialog', { name: 'Skapa ny uppgift' })).not.toBeInTheDocument(),
)
const waiting = screen.getByRole('region', { name: 'Väntande' })
expect(within(waiting).getAllByRole('article').map((card) => card.textContent)).toEqual([
'Dammsuga7 pBottenvåningen',
'Putsa fönster7 pKöket',
])
const waiting = await screen.findByRole('region', { name: 'Väntande' })
expect(
within(waiting)
.getAllByRole('article')
.map((card) => within(card).getByRole('heading').textContent),
).toEqual(['Dammsuga', 'Putsa fönster'])
expect(fetchMock).toHaveBeenLastCalledWith('/api/tasks', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ title: 'Putsa fönster', description: 'Köket', points: 7 }),
body: JSON.stringify({
title: 'Putsa fönster',
description: 'Köket',
points: 7,
assigneeId: users[1].id,
}),
})
fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
expect(screen.getByLabelText('Poäng')).toHaveValue(1)
expect(screen.getByLabelText('Tilldela')).toHaveValue('')
})
test('Ingen skickas som null när en uppgift skapas', async () => {
const createdTask = {
...tasks[0],
id: '00000000-0000-0000-0000-000000000010',
title: 'Torka bordet',
}
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([]))
fetchMock.mockResolvedValueOnce(jsonResponse(createdTask, 201))
render(<App />)
await waitFor(() => expect(fetchMock).toHaveBeenCalledTimes(2))
fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
fireEvent.change(screen.getByLabelText('Titel'), { target: { value: 'Torka bordet' } })
fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
await waitFor(() => expect(fetchMock).toHaveBeenCalledTimes(3))
expect(fetchMock).toHaveBeenLastCalledWith('/api/tasks', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
title: 'Torka bordet',
description: null,
points: 1,
assigneeId: null,
}),
})
})
test('statusanrop byter inte en befintlig ansvarig', async () => {
const assignedWaiting = {
...tasks[0],
assignee: { id: users[1].id, name: users[1].name },
}
const updatedTask = { ...assignedWaiting, status: 'IN_PROGRESS' }
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([assignedWaiting]))
fetchMock.mockResolvedValueOnce(jsonResponse(updatedTask))
render(<App />)
const card = (await screen.findByText('Dammsuga')).closest('article')!
fireEvent.click(within(card).getByRole('button', { name: 'Påbörja' }))
const inProgress = screen.getByRole('region', { name: 'Pågående' })
expect(await within(inProgress).findByText('Anna')).toBeInTheDocument()
expect(within(inProgress).queryByText('Urban')).not.toBeInTheDocument()
})
test('alla statusar har redigerbar tilldelning med statusberoende alternativ', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
mockUsersAndTasks(users, tasks)
render(<App />)
const waitingCard = (await screen.findByText('Dammsuga')).closest('article')
const inProgressCard = screen.getByText('Diska').closest('article')
const completedCard = screen.getByText('Vattna blommor').closest('article')
expect(waitingCard).not.toBeNull()
expect(inProgressCard).not.toBeNull()
expect(completedCard).not.toBeNull()
expect(within(waitingCard!).getByRole('button', { name: 'Ändra ansvarig för Dammsuga' }))
.toHaveTextContent('Ta uppgift')
expect(within(inProgressCard!).getByText('Anna')).toBeInTheDocument()
expect(within(completedCard!).getByText('Otilldelad')).toBeInTheDocument()
fireEvent.click(
within(inProgressCard!).getByRole('button', { name: 'Ändra ansvarig för Diska' }),
)
expect(
within(inProgressCard!).queryByRole('option', { name: 'Ingen' }),
).not.toBeInTheDocument()
fireEvent.click(
within(completedCard!).getByRole('button', {
name: 'Ändra ansvarig för Vattna blommor',
}),
)
expect(within(completedCard!).getByRole('option', { name: 'Ingen' })).toBeInTheDocument()
})
test('visar rätt statusknappar för varje kolumn', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
mockUsersAndTasks(users, tasks)
render(<App />)
const waitingCard = (await screen.findByText('Dammsuga')).closest('article')!
const inProgressCard = screen.getByText('Diska').closest('article')!
const completedCard = screen.getByText('Vattna blommor').closest('article')!
expect(within(waitingCard).getByRole('button', { name: 'Påbörja' })).toBeInTheDocument()
expect(within(waitingCard).getByRole('button', { name: 'Markera klar' })).toBeInTheDocument()
expect(within(inProgressCard).getByRole('button', { name: 'Till Väntande' }))
.toBeInTheDocument()
expect(within(inProgressCard).getByRole('button', { name: 'Markera klar' }))
.toBeInTheDocument()
expect(within(completedCard).getByRole('button', { name: 'Till Väntande' }))
.toBeInTheDocument()
expect(within(completedCard).getByRole('button', { name: 'Påbörja igen' }))
.toBeInTheDocument()
})
test.each([
{ task: tasks[0], button: 'Påbörja', target: 'IN_PROGRESS' },
{ task: tasks[0], button: 'Markera klar', target: 'COMPLETED' },
{ task: tasks[1], button: 'Till Väntande', target: 'WAITING' },
{ task: tasks[1], button: 'Markera klar', target: 'COMPLETED' },
{ task: tasks[2], button: 'Till Väntande', target: 'WAITING' },
{ task: tasks[2], button: 'Påbörja igen', target: 'IN_PROGRESS' },
])('$button skickar status $target', async ({ task, button, target }) => {
const updatedTask = {
...task,
status: target,
assignee:
target === 'IN_PROGRESS' && !task.assignee
? { id: users[0].id, name: users[0].name }
: task.assignee,
}
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([task]))
fetchMock.mockResolvedValueOnce(jsonResponse(updatedTask))
render(<App />)
const card = (await screen.findByText(task.title)).closest('article')!
fireEvent.click(within(card).getByRole('button', { name: button }))
await waitFor(() => expect(fetchMock).toHaveBeenCalledTimes(3))
expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${task.id}/status`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
status: target,
...(target === 'IN_PROGRESS' ? { activeUserId: users[0].id } : {}),
}),
})
})
test('status uppdateras först efter serversvar och låser endast berört kort', async () => {
const otherTask = {
...tasks[0],
id: '00000000-0000-0000-0000-000000000010',
title: 'Putsa fönster',
}
const updatedTask = {
...tasks[0],
status: 'IN_PROGRESS',
assignee: { id: users[0].id, name: users[0].name },
}
let resolveStatus!: (response: Response) => void
const statusResponse = new Promise<Response>((resolve) => {
resolveStatus = resolve
})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0], otherTask]))
fetchMock.mockReturnValueOnce(statusResponse)
render(<App />)
const waiting = await screen.findByRole('region', { name: 'Väntande' })
const card = (await within(waiting).findByText('Dammsuga')).closest('article')!
const otherCard = within(waiting).getByText('Putsa fönster').closest('article')!
const startButton = within(card).getByRole('button', { name: 'Påbörja' })
fireEvent.click(startButton)
fireEvent.click(startButton)
expect(within(waiting).getByText('Dammsuga')).toBeInTheDocument()
expect(startButton).toBeDisabled()
expect(within(card).getByRole('button', { name: 'Ändra ansvarig för Dammsuga' }))
.toBeDisabled()
expect(within(otherCard).getByRole('button', { name: 'Påbörja' })).toBeEnabled()
expect(fetchMock).toHaveBeenCalledTimes(3)
resolveStatus(jsonResponse(updatedTask))
const inProgress = screen.getByRole('region', { name: 'Pågående' })
expect(await within(inProgress).findByText('Dammsuga')).toBeInTheDocument()
expect(within(inProgress).getByText('Urban')).toBeInTheDocument()
})
test('statusfel behåller tidigare status och ansvarig och visas på kortet', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0]]))
fetchMock.mockResolvedValueOnce(
jsonResponse(
{
code: 'TASK_REQUIRES_ASSIGNEE',
message: 'En pågående uppgift måste ha en ansvarig.',
},
409,
),
)
render(<App />)
const waiting = await screen.findByRole('region', { name: 'Väntande' })
const card = (await within(waiting).findByText('Dammsuga')).closest('article')!
fireEvent.click(within(card).getByRole('button', { name: 'Påbörja' }))
expect(await within(card).findByRole('alert')).toHaveTextContent(
'En pågående uppgift måste ha en ansvarig.',
)
expect(within(waiting).getByText('Dammsuga')).toBeInTheDocument()
expect(within(card).getByText('Ta uppgift')).toBeInTheDocument()
})
test('sopkorgsknappen öppnar delete-modal med Avbryt i fokus och utan delete-anrop', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = mockUsersAndTasks(users, [tasks[0]])
render(<App />)
const deleteButton = await screen.findByRole('button', { name: 'Radera Dammsuga' })
expect(deleteButton.querySelector('svg')).toBeInTheDocument()
fireEvent.pointerDown(deleteButton)
fireEvent.click(deleteButton)
const dialog = screen.getByRole('dialog', { name: 'Radera uppgift?' })
expect(within(dialog).getByText('Dammsuga')).toBeInTheDocument()
expect(within(dialog).getByText(/raderas permanent och kan inte återställas/i))
.toBeInTheDocument()
expect(within(dialog).getByRole('button', { name: 'Avbryt' })).toHaveFocus()
expect(within(dialog).getByRole('button', { name: 'Radera' })).not.toHaveFocus()
expect(within(dialog).queryByRole('button', { name: 'Stäng' })).not.toBeInTheDocument()
expect(fetchMock).toHaveBeenCalledTimes(2)
})
test('delete-modal kan stängas med Avbryt, Escape och bakgrundsklick före anrop', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = mockUsersAndTasks(users, [tasks[0]])
const { container } = render(<App />)
const deleteButton = await screen.findByRole('button', { name: 'Radera Dammsuga' })
fireEvent.click(deleteButton)
fireEvent.click(screen.getByRole('button', { name: 'Avbryt' }))
expect(screen.queryByRole('dialog', { name: 'Radera uppgift?' })).not.toBeInTheDocument()
fireEvent.click(deleteButton)
fireEvent.keyDown(window, { key: 'Escape' })
expect(screen.queryByRole('dialog', { name: 'Radera uppgift?' })).not.toBeInTheDocument()
fireEvent.click(deleteButton)
fireEvent.mouseDown(container.querySelector('.modal-backdrop')!)
expect(screen.queryByRole('dialog', { name: 'Radera uppgift?' })).not.toBeInTheDocument()
expect(fetchMock).toHaveBeenCalledTimes(2)
})
test('delete är serverbekräftad och låser bara det berörda kortet och modalen', async () => {
const otherTask = {
...tasks[0],
id: '00000000-0000-0000-0000-000000000010',
title: 'Putsa fönster',
}
let resolveDelete!: (response: Response) => void
const deleteResponse = new Promise<Response>((resolve) => {
resolveDelete = resolve
})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0], otherTask]))
fetchMock.mockReturnValueOnce(deleteResponse)
const { container } = render(<App />)
const deleteButton = await screen.findByRole('button', { name: 'Radera Dammsuga' })
fireEvent.click(deleteButton)
const dialog = screen.getByRole('dialog', { name: 'Radera uppgift?' })
const confirm = within(dialog).getByRole('button', { name: 'Radera' })
fireEvent.click(confirm)
fireEvent.click(confirm)
const card = screen.getByRole('button', { name: 'Radera Dammsuga' }).closest('article')!
const otherCard = screen.getByText('Putsa fönster').closest('article')!
expect(card).toBeInTheDocument()
expect(card).toHaveAttribute('aria-busy', 'true')
expect(within(card).getByRole('button', { name: 'Radera Dammsuga' })).toBeDisabled()
expect(dragAndDrop.disabledTaskIds.has(tasks[0].id)).toBe(true)
expect(dragAndDrop.disabledTaskIds.has(otherTask.id)).toBe(false)
expect(within(card).getByRole('button', { name: 'Påbörja' })).toBeDisabled()
expect(
within(card).getByRole('button', { name: 'Ändra ansvarig för Dammsuga' }),
).toBeDisabled()
expect(within(otherCard).getByRole('button', { name: 'Påbörja' })).toBeEnabled()
expect(within(otherCard).getByRole('button', { name: 'Radera Putsa fönster' })).toBeEnabled()
expect(within(dialog).getByRole('button', { name: 'Avbryt' })).toBeDisabled()
expect(confirm).toBeDisabled()
expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${tasks[0].id}`, {
method: 'DELETE',
})
expect(fetchMock).toHaveBeenCalledTimes(3)
fireEvent.keyDown(window, { key: 'Escape' })
fireEvent.mouseDown(container.querySelector('.modal-backdrop')!)
expect(screen.getByRole('dialog', { name: 'Radera uppgift?' })).toBeInTheDocument()
await act(async () => resolveDelete(emptyResponse(204)))
expect(screen.queryByRole('button', { name: 'Radera Dammsuga' })).not.toBeInTheDocument()
expect(screen.queryByRole('dialog', { name: 'Radera uppgift?' })).not.toBeInTheDocument()
expect(screen.getByText('Putsa fönster')).toBeInTheDocument()
})
test('vanligt delete-fel behåller kort och dialog och kan återförsökas', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0]]))
fetchMock.mockResolvedValueOnce(jsonResponse({ message: 'Serverfel' }, 500))
fetchMock.mockResolvedValueOnce(emptyResponse(204))
render(<App />)
fireEvent.click(await screen.findByRole('button', { name: 'Radera Dammsuga' }))
fireEvent.click(screen.getByRole('button', { name: 'Radera' }))
const dialog = await screen.findByRole('dialog', { name: 'Radera uppgift?' })
expect(await within(dialog).findByRole('alert')).toHaveTextContent(
'Det gick inte att radera uppgiften. Försök igen.',
)
expect(screen.getByRole('button', { name: 'Radera Dammsuga' })).toBeInTheDocument()
expect(within(dialog).getByRole('button', { name: 'Avbryt' })).toBeEnabled()
fireEvent.click(within(dialog).getByRole('button', { name: 'Radera' }))
await waitFor(() =>
expect(screen.queryByRole('button', { name: 'Radera Dammsuga' })).not.toBeInTheDocument(),
)
expect(fetchMock).toHaveBeenCalledTimes(4)
})
test('404 TASK_NOT_FOUND tar bort inaktuellt kort men andra 404-fel gör det inte', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0]]))
fetchMock.mockResolvedValueOnce(
jsonResponse({ code: 'OTHER_NOT_FOUND', message: 'Annat fel' }, 404),
)
fetchMock.mockResolvedValueOnce(
jsonResponse({ code: 'TASK_NOT_FOUND', message: 'Uppgiften finns inte.' }, 404),
)
render(<App />)
fireEvent.click(await screen.findByRole('button', { name: 'Radera Dammsuga' }))
fireEvent.click(screen.getByRole('button', { name: 'Radera' }))
expect(await screen.findByRole('alert')).toHaveTextContent(
'Det gick inte att radera uppgiften. Försök igen.',
)
expect(screen.getByRole('button', { name: 'Radera Dammsuga' })).toBeInTheDocument()
fireEvent.click(screen.getByRole('button', { name: 'Radera' }))
await waitFor(() =>
expect(screen.queryByRole('button', { name: 'Radera Dammsuga' })).not.toBeInTheDocument(),
)
expect(screen.queryByRole('dialog', { name: 'Radera uppgift?' })).not.toBeInTheDocument()
})
test('drag flyttar optimistiskt, låser kortet och använder hela serverresponsen', async () => {
const otherTask = {
...tasks[0],
id: '00000000-0000-0000-0000-000000000010',
title: 'Putsa fönster',
}
const serverTask = {
...tasks[0],
status: 'COMPLETED',
assignee: { id: users[1].id, name: users[1].name },
}
let resolveStatus!: (response: Response) => void
const statusResponse = new Promise<Response>((resolve) => {
resolveStatus = resolve
})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0], otherTask]))
fetchMock.mockReturnValueOnce(statusResponse)
render(<App />)
await screen.findByText('Dammsuga')
act(() => dropTask(tasks[0].id, 'IN_PROGRESS'))
const inProgress = screen.getByRole('region', { name: 'Pågående' })
const optimisticCard = (await within(inProgress).findByText('Dammsuga')).closest('article')!
const waiting = screen.getByRole('region', { name: 'Väntande' })
const otherCard = within(waiting).getByText('Putsa fönster').closest('article')!
expect(within(optimisticCard).getByText('Urban')).toBeInTheDocument()
expect(optimisticCard).toHaveAttribute('aria-busy', 'true')
expect(optimisticCard).toHaveClass('task-card-pending')
expect(within(optimisticCard).getByRole('button', { name: 'Markera klar' })).toBeDisabled()
expect(
within(optimisticCard).getByRole('button', { name: 'Ändra ansvarig för Dammsuga' }),
).toBeDisabled()
expect(within(otherCard).getByRole('button', { name: 'Påbörja' })).toBeEnabled()
expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${tasks[0].id}/status`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
status: 'IN_PROGRESS',
activeUserId: users[0].id,
}),
})
act(() => dropTask(tasks[0].id, 'COMPLETED'))
expect(fetchMock).toHaveBeenCalledTimes(3)
await act(async () => resolveStatus(jsonResponse(serverTask)))
const completed = screen.getByRole('region', { name: 'Klart' })
const confirmedCard = (await within(completed).findByText('Dammsuga')).closest('article')!
expect(within(confirmedCard).getByText('Anna')).toBeInTheDocument()
expect(confirmedCard).not.toHaveAttribute('aria-busy')
})
test('dragfel återställer hela uppgiften och visar lokalt fel', async () => {
let resolveStatus!: (response: Response) => void
const statusResponse = new Promise<Response>((resolve) => {
resolveStatus = resolve
})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0]]))
fetchMock.mockReturnValueOnce(statusResponse)
render(<App />)
await screen.findByText('Dammsuga')
act(() => dropTask(tasks[0].id, 'IN_PROGRESS'))
const inProgress = screen.getByRole('region', { name: 'Pågående' })
expect(await within(inProgress).findByText('Urban')).toBeInTheDocument()
await act(async () =>
resolveStatus(
jsonResponse(
{
code: 'TASK_REQUIRES_ASSIGNEE',
message: 'En pågående uppgift måste ha en ansvarig.',
},
409,
),
),
)
const waiting = screen.getByRole('region', { name: 'Väntande' })
const restoredCard = (await within(waiting).findByText('Dammsuga')).closest('article')!
expect(within(restoredCard).getByText('Ta uppgift')).toBeInTheDocument()
expect(within(restoredCard).queryByText('Urban')).not.toBeInTheDocument()
expect(await within(restoredCard).findByRole('alert')).toHaveTextContent(
'En pågående uppgift måste ha en ansvarig.',
)
expect(restoredCard).not.toHaveAttribute('aria-busy')
})
test('drag till Pågående behåller en befintlig ansvarig optimistiskt', async () => {
const assignedTask = {
...tasks[0],
assignee: { id: users[1].id, name: users[1].name },
}
let resolveStatus!: (response: Response) => void
const statusResponse = new Promise<Response>((resolve) => {
resolveStatus = resolve
})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([assignedTask]))
fetchMock.mockReturnValueOnce(statusResponse)
render(<App />)
await screen.findByText('Dammsuga')
act(() => dropTask(assignedTask.id, 'IN_PROGRESS'))
const inProgress = screen.getByRole('region', { name: 'Pågående' })
expect(await within(inProgress).findByText('Anna')).toBeInTheDocument()
expect(within(inProgress).queryByText('Urban')).not.toBeInTheDocument()
await act(async () =>
resolveStatus(jsonResponse({ ...assignedTask, status: 'IN_PROGRESS' })),
)
})
test('drop i samma kolumn är no-op', async () => {
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = mockUsersAndTasks(users, [tasks[0]])
render(<App />)
await screen.findByText('Dammsuga')
act(() => dropTask(tasks[0].id, 'WAITING'))
expect(fetchMock).toHaveBeenCalledTimes(2)
expect(screen.getByText('Dammsuga').closest('article')).not.toHaveAttribute('aria-busy')
})
test('olika kort kan ha samtidiga optimistiska statusanrop', async () => {
const otherTask = {
...tasks[0],
id: '00000000-0000-0000-0000-000000000010',
title: 'Putsa fönster',
}
const firstResponse = new Promise<Response>(() => {})
const secondResponse = new Promise<Response>(() => {})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0], otherTask]))
fetchMock.mockReturnValueOnce(firstResponse)
fetchMock.mockReturnValueOnce(secondResponse)
render(<App />)
await screen.findByText('Dammsuga')
act(() => {
dropTask(tasks[0].id, 'IN_PROGRESS')
dropTask(otherTask.id, 'COMPLETED')
})
expect(screen.getByText('Dammsuga').closest('article')).toHaveAttribute('aria-busy', 'true')
expect(screen.getByText('Putsa fönster').closest('article')).toHaveAttribute(
'aria-busy',
'true',
)
expect(fetchMock).toHaveBeenCalledTimes(4)
})
test('ansvarig kan bytas i Pågående och tas bort i Klart', async () => {
const changedInProgress = { ...tasks[1], assignee: { id: users[0].id, name: users[0].name } }
const unassignedCompleted = { ...tasks[2], assignee: null }
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[1], { ...tasks[2], assignee: tasks[1].assignee }]))
fetchMock.mockResolvedValueOnce(jsonResponse(changedInProgress))
fetchMock.mockResolvedValueOnce(jsonResponse(unassignedCompleted))
render(<App />)
const inProgressCard = (await screen.findByText('Diska')).closest('article')!
fireEvent.click(
within(inProgressCard).getByRole('button', { name: 'Ändra ansvarig för Diska' }),
)
fireEvent.change(within(inProgressCard).getByRole('combobox'), {
target: { value: users[0].id },
})
await waitFor(() =>
expect(within(inProgressCard).getByRole('button', { name: 'Ändra ansvarig för Diska' }))
.toHaveTextContent('Urban'),
)
const completedCard = screen.getByText('Vattna blommor').closest('article')!
fireEvent.click(
within(completedCard).getByRole('button', {
name: 'Ändra ansvarig för Vattna blommor',
}),
)
fireEvent.change(within(completedCard).getByRole('combobox'), { target: { value: '' } })
await waitFor(() =>
expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${tasks[2].id}/assignee`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ assigneeId: null }),
}),
)
})
test('val av ansvarig anropar endpointen och uppdaterar kortet efter svar', async () => {
const updatedTask = { ...tasks[0], assignee: { id: users[1].id, name: users[1].name } }
let resolveAssignment!: (response: Response) => void
const assignmentResponse = new Promise<Response>((resolve) => {
resolveAssignment = resolve
})
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0]]))
fetchMock.mockReturnValueOnce(assignmentResponse)
render(<App />)
fireEvent.click(await screen.findByRole('button', { name: 'Ändra ansvarig för Dammsuga' }))
const select = screen.getByRole('combobox', { name: 'Ansvarig för Dammsuga' })
fireEvent.change(select, { target: { value: users[1].id } })
expect(select).toBeDisabled()
expect(within(select.closest('article')!).getByRole('button', { name: 'Påbörja' }))
.toBeDisabled()
expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${tasks[0].id}/assignee`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ assigneeId: users[1].id }),
})
resolveAssignment(jsonResponse(updatedTask))
await waitFor(() =>
expect(screen.getByRole('button', { name: 'Ändra ansvarig för Dammsuga' }))
.toHaveTextContent('Anna'),
)
expect(screen.queryByRole('combobox', { name: 'Ansvarig för Dammsuga' })).not.toBeInTheDocument()
})
test('val av Ingen av-tilldelar en väntande uppgift', async () => {
const assignedTask = { ...tasks[0], assignee: { id: users[1].id, name: users[1].name } }
const unassignedTask = { ...assignedTask, assignee: null }
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([assignedTask]))
fetchMock.mockResolvedValueOnce(jsonResponse(unassignedTask))
render(<App />)
fireEvent.click(await screen.findByRole('button', { name: 'Ändra ansvarig för Dammsuga' }))
fireEvent.change(screen.getByRole('combobox', { name: 'Ansvarig för Dammsuga' }), {
target: { value: '' },
})
await screen.findByText('Ta uppgift')
expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${tasks[0].id}/assignee`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ assigneeId: null }),
})
})
test('misslyckad tilldelning behåller ansvarig och visar fel', async () => {
const assignedTask = { ...tasks[0], assignee: { id: users[1].id, name: users[1].name } }
window.localStorage.setItem('hemhub.activeUserId', users[0].id)
const fetchMock = vi.spyOn(globalThis, 'fetch')
fetchMock.mockResolvedValueOnce(jsonResponse(users))
fetchMock.mockResolvedValueOnce(jsonResponse([assignedTask]))
fetchMock.mockResolvedValueOnce(
jsonResponse({ code: 'USER_NOT_FOUND', message: 'Användaren finns inte.' }, 404),
)
render(<App />)
fireEvent.click(await screen.findByRole('button', { name: 'Ändra ansvarig för Dammsuga' }))
fireEvent.change(screen.getByRole('combobox', { name: 'Ansvarig för Dammsuga' }), {
target: { value: users[0].id },
})
expect(await screen.findByRole('alert')).toHaveTextContent('Användaren finns inte.')
expect(screen.getByRole('combobox', { name: 'Ansvarig för Dammsuga' })).toHaveValue(users[1].id)
})
test.each([
@ -321,9 +1020,11 @@ test('formulärdata bevaras när skapande av uppgift misslyckas', async () => {
const title = screen.getByLabelText('Titel')
const description = screen.getByLabelText('Beskrivning (valfri)')
const points = screen.getByLabelText('Poäng')
const assignee = screen.getByLabelText('Tilldela')
fireEvent.change(title, { target: { value: 'Dammsuga' } })
fireEvent.change(description, { target: { value: 'Bottenvåningen' } })
fireEvent.change(points, { target: { value: '7' } })
fireEvent.change(assignee, { target: { value: users[1].id } })
fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
expect(await screen.findByRole('alert')).toHaveTextContent('Uppgiften är ogiltig.')
@ -331,6 +1032,7 @@ test('formulärdata bevaras när skapande av uppgift misslyckas', async () => {
expect(title).toHaveValue('Dammsuga')
expect(description).toHaveValue('Bottenvåningen')
expect(points).toHaveValue(7)
expect(assignee).toHaveValue(users[1].id)
})
function mockUsersAndTasks(userResponse: unknown, taskResponse: unknown) {
@ -340,6 +1042,14 @@ function mockUsersAndTasks(userResponse: unknown, taskResponse: unknown) {
return fetchMock
}
function dropTask(taskId: string, status: string) {
if (!dragAndDrop.onTaskDrop) {
throw new Error('Drag-and-drop-providern är inte monterad')
}
dragAndDrop.onTaskDrop(taskId, status)
}
function mockJsonResponse(body: unknown, status = 200) {
return vi.spyOn(globalThis, 'fetch').mockResolvedValue(jsonResponse(body, status))
}
@ -350,3 +1060,7 @@ function jsonResponse(body: unknown, status = 200) {
headers: { 'Content-Type': 'application/json' },
})
}
function emptyResponse(status: number) {
return new Response(null, { status })
}

View File

@ -79,7 +79,14 @@ function App() {
}
if (activeUser) {
return <TaskBoard activeUserName={activeUser.name} onLogOut={logOut} />
return (
<TaskBoard
activeUserId={activeUser.id}
activeUserName={activeUser.name}
users={users}
onLogOut={logOut}
/>
)
}
if (showCreateUser) {

View File

@ -1,6 +1,17 @@
import { FormEvent, MouseEvent, useEffect, useRef, useState } from 'react'
import {
TaskDragDropProvider,
TaskStatus,
useTaskColumnDropTarget,
useTaskDraggable,
} from './TaskDragAndDrop'
type TaskStatus = 'WAITING' | 'IN_PROGRESS' | 'COMPLETED'
type UserSummary = {
id: string
name: string
}
type Assignee = UserSummary
type Task = {
id: string
@ -8,15 +19,19 @@ type Task = {
description: string | null
status: TaskStatus
points: number
assignee: Assignee | null
createdAt: string
}
type ApiError = {
code?: string
message?: string
}
type TaskBoardProps = {
activeUserId: string
activeUserName: string
users: UserSummary[]
onLogOut: () => void
}
@ -26,10 +41,16 @@ const columns: { status: TaskStatus; title: string }[] = [
{ status: 'COMPLETED', title: 'Klart' },
]
function TaskBoard({ activeUserName, onLogOut }: TaskBoardProps) {
function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardProps) {
const [tasks, setTasks] = useState<Task[]>([])
const [loadState, setLoadState] = useState<'loading' | 'ready' | 'error'>('loading')
const [showCreateTask, setShowCreateTask] = useState(false)
const [deletingTask, setDeletingTask] = useState<Task | null>(null)
const [deleteError, setDeleteError] = useState('')
const [editingAssigneeTaskId, setEditingAssigneeTaskId] = useState<string | null>(null)
const [pendingTaskIds, setPendingTaskIds] = useState<Set<string>>(new Set())
const [taskErrors, setTaskErrors] = useState<Record<string, string>>({})
const pendingTaskIdsRef = useRef(new Set<string>())
const loadTasks = async () => {
setLoadState('loading')
@ -52,6 +73,179 @@ function TaskBoard({ activeUserName, onLogOut }: TaskBoardProps) {
void loadTasks()
}, [])
const beginTaskRequest = (taskId: string) => {
if (pendingTaskIdsRef.current.has(taskId)) {
return false
}
pendingTaskIdsRef.current.add(taskId)
setPendingTaskIds(new Set(pendingTaskIdsRef.current))
setTaskErrors((current) => ({ ...current, [taskId]: '' }))
return true
}
const finishTaskRequest = (taskId: string) => {
pendingTaskIdsRef.current.delete(taskId)
setPendingTaskIds(new Set(pendingTaskIdsRef.current))
}
const replaceTask = (updatedTask: Task) => {
setTasks((current) =>
current.map((task) => (task.id === updatedTask.id ? updatedTask : task)),
)
}
const updateAssignee = async (task: Task, assigneeId: string) => {
if (!beginTaskRequest(task.id)) {
return
}
try {
const response = await fetch(`/api/tasks/${task.id}/assignee`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ assigneeId: assigneeId || null }),
})
if (!response.ok) {
const apiError = (await response.json().catch(() => ({}))) as ApiError
setTaskErrors((current) => ({
...current,
[task.id]: apiError.message ?? 'Det gick inte att ändra ansvarig. Försök igen.',
}))
return
}
const updatedTask = (await response.json()) as Task
replaceTask(updatedTask)
setEditingAssigneeTaskId(null)
} catch {
setTaskErrors((current) => ({
...current,
[task.id]: 'Det gick inte att ändra ansvarig. Försök igen.',
}))
} finally {
finishTaskRequest(task.id)
}
}
const updateStatus = async (
task: Task,
status: TaskStatus,
presentation: 'server-confirmed' | 'optimistic',
) => {
if (!beginTaskRequest(task.id)) {
return
}
const previousTask = task
if (presentation === 'optimistic') {
replaceTask({
...task,
status,
assignee:
status === 'IN_PROGRESS' && !task.assignee
? { id: activeUserId, name: activeUserName }
: task.assignee,
})
}
try {
const response = await fetch(`/api/tasks/${task.id}/status`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
status,
...(status === 'IN_PROGRESS' ? { activeUserId } : {}),
}),
})
if (!response.ok) {
const apiError = (await response.json().catch(() => ({}))) as ApiError
if (presentation === 'optimistic') {
replaceTask(previousTask)
}
setTaskErrors((current) => ({
...current,
[task.id]: apiError.message ?? 'Det gick inte att ändra status. Försök igen.',
}))
return
}
replaceTask((await response.json()) as Task)
setEditingAssigneeTaskId(null)
} catch {
if (presentation === 'optimistic') {
replaceTask(previousTask)
}
setTaskErrors((current) => ({
...current,
[task.id]: 'Det gick inte att ändra status. Försök igen.',
}))
} finally {
finishTaskRequest(task.id)
}
}
const dropTask = (taskId: string, status: TaskStatus) => {
const task = tasks.find((candidate) => candidate.id === taskId)
if (!task || task.status === status) {
return
}
void updateStatus(task, status, 'optimistic')
}
const openDeleteTask = (task: Task) => {
if (pendingTaskIdsRef.current.has(task.id)) {
return
}
setDeleteError('')
setDeletingTask(task)
}
const closeDeleteTask = () => {
if (deletingTask && pendingTaskIdsRef.current.has(deletingTask.id)) {
return
}
setDeleteError('')
setDeletingTask(null)
}
const deleteTask = async (task: Task) => {
if (!beginTaskRequest(task.id)) {
return
}
setDeleteError('')
try {
const response = await fetch(`/api/tasks/${task.id}`, { method: 'DELETE' })
if (response.status === 204) {
setTasks((current) => current.filter((candidate) => candidate.id !== task.id))
setDeletingTask(null)
return
}
const apiError = (await response.json().catch(() => ({}))) as ApiError
if (response.status === 404 && apiError.code === 'TASK_NOT_FOUND') {
setTasks((current) => current.filter((candidate) => candidate.id !== task.id))
setDeletingTask(null)
return
}
setDeleteError('Det gick inte att radera uppgiften. Försök igen.')
} catch {
setDeleteError('Det gick inte att radera uppgiften. Försök igen.')
} finally {
finishTaskRequest(task.id)
}
}
return (
<main className="task-app">
<header className="app-header">
@ -84,29 +278,30 @@ function TaskBoard({ activeUserName, onLogOut }: TaskBoardProps) {
</button>
</div>
<TaskDragDropProvider onTaskDrop={dropTask}>
<section className="board" aria-label="Uppgiftsbräda">
{columns.map((column) => (
<section className="board-column" key={column.status} aria-labelledby={column.status}>
<h2 id={column.status}>{column.title}</h2>
<div className="task-list">
{tasks
.filter((task) => task.status === column.status)
.map((task) => (
<article className="task-card" key={task.id}>
<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>
))}
</div>
</section>
<TaskColumn
column={column}
tasks={tasks.filter((task) => task.status === column.status)}
users={users}
editingAssigneeTaskId={editingAssigneeTaskId}
pendingTaskIds={pendingTaskIds}
taskErrors={taskErrors}
onEditAssignee={setEditingAssigneeTaskId}
onChangeAssignee={(task, assigneeId) => void updateAssignee(task, assigneeId)}
onChangeStatus={(task, status) =>
void updateStatus(task, status, 'server-confirmed')
}
onDelete={openDeleteTask}
/>
))}
</section>
</TaskDragDropProvider>
{showCreateTask && (
<CreateTaskModal
users={users}
onClose={() => setShowCreateTask(false)}
onCreated={(task) => {
setTasks((currentTasks) => [...currentTasks, task])
@ -114,19 +309,368 @@ function TaskBoard({ activeUserName, onLogOut }: TaskBoardProps) {
}}
/>
)}
{deletingTask && (
<DeleteTaskModal
task={deletingTask}
pending={pendingTaskIds.has(deletingTask.id)}
error={deleteError}
onClose={closeDeleteTask}
onConfirm={() => void deleteTask(deletingTask)}
/>
)}
</main>
)
}
type TaskColumnProps = {
column: { status: TaskStatus; title: string }
tasks: Task[]
users: UserSummary[]
editingAssigneeTaskId: string | null
pendingTaskIds: Set<string>
taskErrors: Record<string, string>
onEditAssignee: (taskId: string) => void
onChangeAssignee: (task: Task, assigneeId: string) => void
onChangeStatus: (task: Task, status: TaskStatus) => void
onDelete: (task: Task) => void
}
function TaskColumn({
column,
tasks,
users,
editingAssigneeTaskId,
pendingTaskIds,
taskErrors,
onEditAssignee,
onChangeAssignee,
onChangeStatus,
onDelete,
}: TaskColumnProps) {
const { ref, isDropTarget } = useTaskColumnDropTarget(column.status)
return (
<section
ref={ref}
className={`board-column${isDropTarget ? ' board-column-drop-target' : ''}`}
aria-labelledby={column.status}
>
<h2 id={column.status}>{column.title}</h2>
<div className="task-list">
{tasks.map((task) => (
<TaskCard
key={task.id}
task={task}
users={users}
editingAssignee={editingAssigneeTaskId === task.id}
pending={pendingTaskIds.has(task.id)}
error={taskErrors[task.id]}
onEditAssignee={() => onEditAssignee(task.id)}
onChangeAssignee={(assigneeId) => onChangeAssignee(task, assigneeId)}
onChangeStatus={(status) => onChangeStatus(task, status)}
onDelete={() => onDelete(task)}
/>
))}
</div>
</section>
)
}
type TaskCardProps = {
task: Task
users: UserSummary[]
editingAssignee: boolean
pending: boolean
error?: string
onEditAssignee: () => void
onChangeAssignee: (assigneeId: string) => void
onChangeStatus: (status: TaskStatus) => void
onDelete: () => void
}
function TaskCard({
task,
users,
editingAssignee,
pending,
error,
onEditAssignee,
onChangeAssignee,
onChangeStatus,
onDelete,
}: TaskCardProps) {
const { ref, isDragging } = useTaskDraggable(task.id, pending)
return (
<article
ref={ref}
role="article"
className={`task-card${pending ? ' task-card-pending' : ''}${
isDragging ? ' task-card-dragging' : ''
}`}
aria-busy={pending || undefined}
>
<div className="task-card-header">
<h3>{task.title}</h3>
<div className="task-card-actions">
<span className="points-badge">{task.points} p</span>
<button
type="button"
className="task-delete-button"
aria-label={`Radera ${task.title}`}
disabled={pending}
onPointerDown={(event) => event.stopPropagation()}
onClick={onDelete}
>
<TrashIcon />
</button>
</div>
</div>
{task.description && <p>{task.description}</p>}
<AssigneeControl
task={task}
users={users}
editing={editingAssignee}
pending={pending}
onEdit={onEditAssignee}
onChange={onChangeAssignee}
/>
<TaskStatusControls task={task} disabled={pending} onChange={onChangeStatus} />
{error && (
<p className="task-error error" role="alert">
{error}
</p>
)}
</article>
)
}
function TrashIcon() {
return (
<svg
viewBox="0 0 24 24"
width="19"
height="19"
aria-hidden="true"
focusable="false"
>
<path
d="M4 7h16M9 7V4h6v3m-8 0 1 13h8l1-13M10 11v5m4-5v5"
fill="none"
stroke="currentColor"
strokeWidth="1.8"
strokeLinecap="round"
strokeLinejoin="round"
/>
</svg>
)
}
type DeleteTaskModalProps = {
task: Task
pending: boolean
error: string
onClose: () => void
onConfirm: () => void
}
function DeleteTaskModal({
task,
pending,
error,
onClose,
onConfirm,
}: DeleteTaskModalProps) {
useEffect(() => {
const closeOnEscape = (event: KeyboardEvent) => {
if (event.key === 'Escape' && !pending) {
onClose()
}
}
window.addEventListener('keydown', closeOnEscape)
return () => window.removeEventListener('keydown', closeOnEscape)
}, [onClose, pending])
const closeFromBackdrop = (event: MouseEvent<HTMLDivElement>) => {
if (event.target === event.currentTarget && !pending) {
onClose()
}
}
return (
<div className="modal-backdrop" onMouseDown={closeFromBackdrop}>
<section
className="modal delete-task-modal"
role="dialog"
aria-modal="true"
aria-labelledby="delete-task-title"
>
<div className="modal-header">
<h2 id="delete-task-title">Radera uppgift?</h2>
</div>
<p>
Är du säker att du vill radera <strong>{task.title}</strong>? Uppgiften
raderas permanent och kan inte återställas.
</p>
{error && (
<p className="error" role="alert">
{error}
</p>
)}
<div className="delete-task-actions">
<button
type="button"
className="secondary compact"
autoFocus
disabled={pending}
onClick={onClose}
>
Avbryt
</button>
<button
type="button"
className="danger"
disabled={pending}
onClick={onConfirm}
>
Radera
</button>
</div>
</section>
</div>
)
}
type AssigneeControlProps = {
task: Task
users: UserSummary[]
editing: boolean
pending: boolean
onEdit: () => void
onChange: (assigneeId: string) => void
}
function UserIcon() {
return (
<svg
className="user-icon"
viewBox="0 0 24 24"
width="18"
height="18"
aria-hidden="true"
>
<circle cx="12" cy="8" r="3.5" fill="none" stroke="currentColor" strokeWidth="1.8" />
<path
d="M5 20c.5-4 3-6 7-6s6.5 2 7 6"
fill="none"
stroke="currentColor"
strokeWidth="1.8"
strokeLinecap="round"
/>
</svg>
)
}
function AssigneeControl({
task,
users,
editing,
pending,
onEdit,
onChange,
}: AssigneeControlProps) {
const displayName =
task.assignee?.name ?? (task.status === 'WAITING' ? 'Ta uppgift' : 'Otilldelad')
return (
<div className="task-assignment">
{editing ? (
<label className="assignee-select-label">
<span className="visually-hidden">Ansvarig för {task.title}</span>
<UserIcon />
<select
aria-label={`Ansvarig för ${task.title}`}
value={task.assignee?.id ?? ''}
disabled={pending}
autoFocus
onChange={(event) => onChange(event.target.value)}
>
{task.status !== 'IN_PROGRESS' && <option value="">Ingen</option>}
{users.map((user) => (
<option key={user.id} value={user.id}>
{user.name}
</option>
))}
</select>
</label>
) : (
<button
type="button"
className="task-assignee task-assignee-button"
disabled={pending}
onClick={onEdit}
aria-label={`Ändra ansvarig för ${task.title}`}
>
<UserIcon />
<span>{displayName}</span>
</button>
)}
</div>
)
}
type TaskStatusControlsProps = {
task: Task
disabled: boolean
onChange: (status: TaskStatus) => void
}
const statusActions: Record<TaskStatus, { label: string; target: TaskStatus }[]> = {
WAITING: [
{ label: 'Påbörja', target: 'IN_PROGRESS' },
{ label: 'Markera klar', target: 'COMPLETED' },
],
IN_PROGRESS: [
{ label: 'Till Väntande', target: 'WAITING' },
{ label: 'Markera klar', target: 'COMPLETED' },
],
COMPLETED: [
{ label: 'Till Väntande', target: 'WAITING' },
{ label: 'Påbörja igen', target: 'IN_PROGRESS' },
],
}
function TaskStatusControls({ task, disabled, onChange }: TaskStatusControlsProps) {
return (
<div className="task-status-actions" aria-label={`Ändra status för ${task.title}`}>
{statusActions[task.status].map((action) => (
<button
type="button"
className="status-button"
key={action.target}
disabled={disabled}
onClick={() => onChange(action.target)}
>
{action.label}
</button>
))}
</div>
)
}
type CreateTaskModalProps = {
users: UserSummary[]
onClose: () => void
onCreated: (task: Task) => void
}
function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
function CreateTaskModal({ users, onClose, onCreated }: CreateTaskModalProps) {
const [title, setTitle] = useState('')
const [description, setDescription] = useState('')
const [points, setPoints] = useState('1')
const [assigneeId, setAssigneeId] = useState('')
const [error, setError] = useState('')
const [isSubmitting, setIsSubmitting] = useState(false)
const isSubmittingRef = useRef(false)
@ -191,6 +735,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
title: trimmedTitle,
description: trimmedDescription || null,
points: numericPoints,
assigneeId: assigneeId || null,
}),
})
@ -264,6 +809,23 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
199 poäng beroende hur tidskrävande, besvärlig eller viktig uppgiften är.
</p>
<label className="field-label-uppercase" htmlFor="task-assignee">
Tilldela
</label>
<select
id="task-assignee"
value={assigneeId}
disabled={isSubmitting}
onChange={(event) => setAssigneeId(event.target.value)}
>
<option value="">Ingen</option>
{users.map((user) => (
<option key={user.id} value={user.id}>
{user.name}
</option>
))}
</select>
{error && (
<p className="error" role="alert">
{error}

View File

@ -0,0 +1,18 @@
import { expect, test } from 'vitest'
import { resolveTaskDrop } from './TaskDragAndDrop'
test.each(['WAITING', 'IN_PROGRESS', 'COMPLETED'] as const)(
'mappar målkolumnen %s till motsvarande status',
(status) => {
expect(resolveTaskDrop('task-1', status, false)).toEqual({
taskId: 'task-1',
targetStatus: status,
})
},
)
test('avbruten dragning och ogiltig målkolumn är no-op', () => {
expect(resolveTaskDrop('task-1', 'WAITING', true)).toBeNull()
expect(resolveTaskDrop('task-1', undefined, false)).toBeNull()
expect(resolveTaskDrop('task-1', 'UNKNOWN', false)).toBeNull()
})

View File

@ -0,0 +1,90 @@
import { ReactNode } from 'react'
import { DragDropProvider, useDraggable, useDroppable } from '@dnd-kit/react'
import { PointerActivationConstraints, PointerSensor } from '@dnd-kit/dom'
export type TaskStatus = 'WAITING' | 'IN_PROGRESS' | 'COMPLETED'
type TaskDragDropProviderProps = {
children: ReactNode
onTaskDrop: (taskId: string, targetStatus: TaskStatus) => void
}
const taskStatuses = new Set<TaskStatus>(['WAITING', 'IN_PROGRESS', 'COMPLETED'])
const pointerSensor = PointerSensor.configure({
activationConstraints(event) {
if (event.pointerType === 'touch') {
return [new PointerActivationConstraints.Delay({ value: 250, tolerance: 8 })]
}
return [new PointerActivationConstraints.Distance({ value: 6 })]
},
})
export function resolveTaskDrop(
sourceId: string | number | undefined,
targetId: string | number | undefined,
canceled: boolean,
) {
if (
canceled ||
sourceId === undefined ||
typeof targetId !== 'string' ||
!taskStatuses.has(targetId as TaskStatus)
) {
return null
}
return {
taskId: String(sourceId),
targetStatus: targetId as TaskStatus,
}
}
export function TaskDragDropProvider({
children,
onTaskDrop,
}: TaskDragDropProviderProps) {
return (
<DragDropProvider
sensors={(defaults) => [
...defaults.filter((sensor) => sensor !== PointerSensor),
pointerSensor,
]}
onDragEnd={(event) => {
const drop = resolveTaskDrop(
event.operation.source?.id,
event.operation.target?.id,
event.canceled,
)
if (!drop) {
return
}
onTaskDrop(drop.taskId, drop.targetStatus)
}}
>
{children}
</DragDropProvider>
)
}
export function useTaskDraggable(taskId: string, disabled: boolean) {
const { ref, isDragging } = useDraggable({
id: taskId,
type: 'task',
disabled,
})
return { ref, isDragging }
}
export function useTaskColumnDropTarget(status: TaskStatus) {
const { ref, isDropTarget } = useDroppable({
id: status,
accept: 'task',
})
return { ref, isDropTarget }
}

View File

@ -23,6 +23,7 @@ h1 {
button,
input,
select,
textarea {
font: inherit;
}
@ -38,6 +39,7 @@ button {
button:disabled,
input:disabled,
select:disabled,
textarea:disabled {
cursor: not-allowed;
opacity: 0.65;
@ -70,6 +72,15 @@ input {
border-radius: 0.4rem;
}
select {
box-sizing: border-box;
width: 100%;
padding: 0.6rem;
border: 1px solid #9ca3af;
border-radius: 0.4rem;
background: white;
}
textarea {
box-sizing: border-box;
width: 100%;
@ -147,8 +158,15 @@ textarea {
.board-column {
min-height: 20rem;
padding: 1rem;
border: 1px solid transparent;
border-radius: 0.75rem;
background: #e5e7eb;
transition: border-color 120ms ease, background-color 120ms ease;
}
.board-column-drop-target {
border-color: #93c5fd;
background: #e0e7ff;
}
.board-column h2 {
@ -169,11 +187,72 @@ textarea {
box-shadow: 0 0.125rem 0.4rem rgb(0 0 0 / 8%);
}
.task-card-pending {
opacity: 0.65;
}
.task-card-dragging {
cursor: grabbing;
}
.task-card h3,
.task-card p {
margin: 0;
}
.task-assignment {
margin-top: 0.9rem;
}
.task-assignee {
display: inline-flex;
align-items: center;
gap: 0.4rem;
color: #475569;
font-size: 0.9rem;
}
.task-assignee-button {
padding: 0.25rem 0;
color: #2563eb;
background: transparent;
}
.user-icon {
flex: 0 0 auto;
}
.assignee-select-label {
display: flex;
align-items: center;
gap: 0.4rem;
}
.assignee-select-label select {
width: auto;
min-width: 9rem;
}
.field-label-uppercase {
color: #64748b;
font-size: 0.8rem;
font-weight: 700;
letter-spacing: 0.08em;
text-transform: uppercase;
}
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
.task-card-header {
display: flex;
align-items: flex-start;
@ -181,6 +260,34 @@ textarea {
gap: 0.75rem;
}
.task-card-actions {
display: flex;
flex: 0 0 auto;
align-items: center;
gap: 0.35rem;
}
.task-delete-button {
display: inline-grid;
width: 2.5rem;
height: 2.5rem;
padding: 0;
place-items: center;
color: #64748b;
background: transparent;
}
.task-delete-button:hover,
.task-delete-button:focus-visible {
color: #991b1b;
background: #fee2e2;
}
.task-delete-button:focus-visible {
outline: 2px solid #dc2626;
outline-offset: 2px;
}
.points-badge {
flex: 0 0 auto;
padding: 0.2rem 0.5rem;
@ -198,6 +305,25 @@ textarea {
white-space: pre-wrap;
}
.task-status-actions {
display: flex;
flex-wrap: wrap;
gap: 0.5rem;
margin-top: 0.9rem;
}
.status-button {
padding: 0.4rem 0.65rem;
color: #1e3a8a;
background: #dbeafe;
font-size: 0.85rem;
}
.task-error {
margin-top: 0.6rem;
font-size: 0.85rem;
}
.field-help {
margin: -0.25rem 0 0;
color: #64748b;
@ -229,6 +355,29 @@ textarea {
margin: 0;
}
.delete-task-modal p {
margin: 0 0 1rem;
}
.delete-task-actions {
display: flex;
justify-content: flex-end;
gap: 0.75rem;
}
.delete-task-actions .secondary {
margin-top: 0;
}
.danger {
background: #b91c1c;
}
.danger:hover,
.danger:focus-visible {
background: #991b1b;
}
.close-button {
padding: 0.2rem 0.55rem;
color: #475569;

View File

@ -1,5 +1,15 @@
import '@testing-library/jest-dom/vitest'
class ResizeObserverStub implements ResizeObserver {
observe() {}
unobserve() {}
disconnect() {}
}
globalThis.ResizeObserver = ResizeObserverStub
const storedValues = new Map<string, string>()
Object.defineProperty(window, 'localStorage', {