#01 — List Ownership Model #1

New issue

Closed

opened 2026-08-18 13:08:55 +02:00 by lena · 4 comments

lena commented 2026-08-18 13:08:55 +02:00 (Migrated from git.butzei.de)

Copy link

B# Story: List Ownership Model

As a user who creates a todo list,
I want to automatically become the owner of that list,
so that I control who can access it and can manage its membership.

Acceptance criteria:

• When a list is created, the creator is stored as owner (distinct from member)
• Only the owner can delete the list
• Only the owner can rename the list
• Only the owner can generate and revoke invitation links
• Regular members can view the list and interact with todos, but cannot manage membership
• The list detail view shows which role the current user has (owner vs. member)

Out of scope for this story:

• Transferring ownership to another member
• Co-owners / multiple owners

Decisions:

• Lists are private by default — only visible to owner and accepted members
• Owner-based trust model — creator controls membership exclusively

B# Story: List Ownership Model **As a** user who creates a todo list, **I want to** automatically become the owner of that list, **so that** I control who can access it and can manage its membership. **Acceptance criteria:** - [ ] When a list is created, the creator is stored as owner (distinct from member) - [ ] Only the owner can delete the list - [ ] Only the owner can rename the list - [ ] Only the owner can generate and revoke invitation links - [ ] Regular members can view the list and interact with todos, but cannot manage membership - [ ] The list detail view shows which role the current user has (owner vs. member) **Out of scope for this story:** - Transferring ownership to another member - Co-owners / multiple owners **Decisions:** - Lists are private by default — only visible to owner and accepted members - Owner-based trust model — creator controls membership exclusively

lena commented 2026-08-18 13:08:56 +02:00 (Migrated from git.butzei.de)

Copy link

design (01_list_ownership_model_design.md)

Design: List Ownership Model

Implements story: 01_list_ownership_model.md

New requests

• AuthorizeTodoListOwnerAccessForCurrentUserQuery(TodoListId) : IRequest<Unit>
  • Throws UnauthorizedAccessException if current user is not the owner of the list

New / changed DTOs

• TodoListDto — add TodoListUserRole CurrentUserRole

  • Requires replacing Mapperly ProjectToDto() calls with manual EF .Select() in handlers, since role is
    user-context-dependent and cannot be projected without a userId

• New enum TodoListUserRole (in Common):

  Owner = 0
  Member = 1
  

New / changed entities

• TodoListToUserEntity — add TodoListUserRole Role { get; set; }
  • Default value: Owner (see migration note)

Authorization changes on existing commands

Command	Current auth	New auth
DeleteTodoListCommand	AuthorizeTodoListAccessForCurrentUserQuery	AuthorizeTodoListOwnerAccessForCurrentUserQuery
RenameTodoListCommand	AuthorizeIsCurrentUserAuthenticatedQuery ⚠️	AuthorizeTodoListOwnerAccessForCurrentUserQuery

⚠️ RenameTodoListCommand currently only checks authentication, not list membership. This is a pre-existing bug
that must be fixed as part of this story.

Handler changes

• CreateTodoListCommandHandler — set Role = Owner when adding the creator to entity.Users
• GetTodoListQueryHandler — inject IHandler<GetCurrentUserIdQuery, UserId?>, replace Mapperly projection with manual
  EF .Select() that includes the user's role
• GetTodoListsOfCurrentUserQueryHandler — replace ProjectToDto() with manual EF .Select() that includes role

Migration needed

Yes — add Role column to the TodoListToUsers table.

Migration strategy: default all existing rows to Owner = 0. This is safe because the current app only adds the creator
to a list, so every existing member is effectively the owner.

Change events

No new change events. Existing Change<TodoListId, TodoListDto> events remain; the DTO now carries CurrentUserRole
so the frontend receives it automatically.

ChangePublisher scoping (decision: 2026-06-14)

The current ChangePublisher<TId, TDto> broadcasts globally. Once list membership is per-user this becomes a privacy
leak. Resolved: server-side filtering — the publisher will only push list change events to clients whose user is a
current member of that list. Design owned by the Backend Engineer; must ship together with or before the invitation
feature.

**design** (`01_list_ownership_model_design.md`) # Design: List Ownership Model > Implements story: `01_list_ownership_model.md` ### New requests - `AuthorizeTodoListOwnerAccessForCurrentUserQuery(TodoListId)` : IRequest\<Unit\> - Throws `UnauthorizedAccessException` if current user is not the owner of the list ### New / changed DTOs - `TodoListDto` — add `TodoListUserRole CurrentUserRole` - Requires replacing Mapperly `ProjectToDto()` calls with manual EF `.Select()` in handlers, since role is user-context-dependent and cannot be projected without a userId - New enum `TodoListUserRole` (in `Common`): ``` Owner = 0 Member = 1 ``` ### New / changed entities - `TodoListToUserEntity` — add `TodoListUserRole Role { get; set; }` - Default value: `Owner` (see migration note) ### Authorization changes on existing commands | Command | Current auth | New auth | |-------------------------|-----------------------------------------------|---------------------------------------------------| | `DeleteTodoListCommand` | `AuthorizeTodoListAccessForCurrentUserQuery` | `AuthorizeTodoListOwnerAccessForCurrentUserQuery` | | `RenameTodoListCommand` | `AuthorizeIsCurrentUserAuthenticatedQuery` ⚠️ | `AuthorizeTodoListOwnerAccessForCurrentUserQuery` | > ⚠️ `RenameTodoListCommand` currently only checks authentication, not list membership. This is a pre-existing bug > that must be fixed as part of this story. ### Handler changes - `CreateTodoListCommandHandler` — set `Role = Owner` when adding the creator to `entity.Users` - `GetTodoListQueryHandler` — inject `IHandler<GetCurrentUserIdQuery, UserId?>`, replace Mapperly projection with manual EF `.Select()` that includes the user's role - `GetTodoListsOfCurrentUserQueryHandler` — replace `ProjectToDto()` with manual EF `.Select()` that includes role ### Migration needed Yes — add `Role` column to the `TodoListToUsers` table. Migration strategy: default all existing rows to `Owner = 0`. This is safe because the current app only adds the creator to a list, so every existing member is effectively the owner. ### Change events No new change events. Existing `Change<TodoListId, TodoListDto>` events remain; the DTO now carries `CurrentUserRole` so the frontend receives it automatically. ### ChangePublisher scoping (decision: 2026-06-14) The current `ChangePublisher<TId, TDto>` broadcasts globally. Once list membership is per-user this becomes a privacy leak. **Resolved: server-side filtering** — the publisher will only push list change events to clients whose user is a current member of that list. Design owned by the Backend Engineer; must ship together with or before the invitation feature.

lena commented 2026-08-18 13:08:56 +02:00 (Migrated from git.butzei.de)

Copy link

handoff (01_list_ownership_model_handoff.md)

Handoff: List Ownership Model

Stage: review
Moved by: Backend Engineer + Frontend Engineer
Date: 2026-06-15

What was implemented

Backend (merged to master):

• TodoListUserRole enum (Owner = 0, Member = 1)
• Role field on TodoListToUserEntity — migration AddListOwnershipModel
• AuthorizeTodoListOwnerAccessForCurrentUserQuery — new auth handler
• CreateTodoListCommandHandler sets creator as Owner
• DeleteTodoListCommand and RenameTodoListCommand now require Owner role
• Pre-existing IDOR bug on RenameTodoListCommand fixed
• TodoListDto.CurrentUserRole — manual EF Select in both Get handlers
• ChangePublisher scoped per user (separate commit)

Frontend (branch: feature/list-ownership-model-frontend):

• TodoListDto extended with currentUserRole
• Rename/Delete menu hidden for Members — only owners see the ☰ menu
• Hardcoded API/WS URLs replaced with VITE_API_URL
• Zustand persist narrowed to userId + selectedTodoListId
• Pre-existing broken vi.mock fixed across 7 test files

What Security Agent should check

• AuthorizeTodoListOwnerAccessForCurrentUserQuery correctly gates all owner-only commands
• RenameTodoListCommand IDOR fix is in place
• No sensitive role data leaked beyond what the caller needs
• Frontend: currentUserRole not manipulable client-side (role comes from server DTO, not client state)

What QA Agent should check

• Owner sees ☰ menu with Rename + Invite + Delete
• Member sees no ☰ menu
• Delete redirects to home if the deleted list was selected
• WebSocket events for list changes are only received by members of that list
• Existing handler tests still pass (verify no regression)

Branches / commits to review

• Backend: merged to master — commits 7e1cd5f, 766597a
• Frontend: feature/list-ownership-model-frontend — commit 001793d

**handoff** (`01_list_ownership_model_handoff.md`) # Handoff: List Ownership Model **Stage:** review **Moved by:** Backend Engineer + Frontend Engineer **Date:** 2026-06-15 ## What was implemented **Backend** (merged to `master`): - `TodoListUserRole` enum (`Owner = 0`, `Member = 1`) - `Role` field on `TodoListToUserEntity` — migration `AddListOwnershipModel` - `AuthorizeTodoListOwnerAccessForCurrentUserQuery` — new auth handler - `CreateTodoListCommandHandler` sets creator as Owner - `DeleteTodoListCommand` and `RenameTodoListCommand` now require Owner role - Pre-existing IDOR bug on `RenameTodoListCommand` fixed - `TodoListDto.CurrentUserRole` — manual EF Select in both Get handlers - `ChangePublisher` scoped per user (separate commit) **Frontend** (branch: `feature/list-ownership-model-frontend`): - `TodoListDto` extended with `currentUserRole` - Rename/Delete menu hidden for Members — only owners see the ☰ menu - Hardcoded API/WS URLs replaced with `VITE_API_URL` - Zustand `persist` narrowed to `userId` + `selectedTodoListId` - Pre-existing broken `vi.mock` fixed across 7 test files ## What Security Agent should check - [ ] `AuthorizeTodoListOwnerAccessForCurrentUserQuery` correctly gates all owner-only commands - [ ] `RenameTodoListCommand` IDOR fix is in place - [ ] No sensitive role data leaked beyond what the caller needs - [ ] Frontend: `currentUserRole` not manipulable client-side (role comes from server DTO, not client state) ## What QA Agent should check - [ ] Owner sees ☰ menu with Rename + Invite + Delete - [ ] Member sees no ☰ menu - [ ] Delete redirects to home if the deleted list was selected - [ ] WebSocket events for list changes are only received by members of that list - [ ] Existing handler tests still pass (verify no regression) ## Branches / commits to review - Backend: merged to `master` — commits `7e1cd5f`, `766597a` - Frontend: `feature/list-ownership-model-frontend` — commit `001793d`

lena commented 2026-08-18 13:08:56 +02:00 (Migrated from git.butzei.de)

Copy link

blocker — cross-cutting with #02 (01_02_blocker.md)

Blocker: List Ownership Model + Invite via Share Link

Moved back by: QA Agent
Date: 2026-06-15
From: review/ → in-progress/

---

Agents responsible for fixing

Backend Engineer — 5 missing handler test files (primary blocker)
Frontend Engineer — 1 render anti-pattern in InvitePanel.tsx (non-blocking but must fix before next cycle)

---

Backend Engineer: what needs to be done

Write unit tests for the following new handlers in CqsTodo.Tests/Features/:

1. AuthorizeTodoListOwnerAccessQueryHandlerTests.cs

• Not logged in → UnauthorizedAccessException("Not logged in")
• Authenticated but role = Member → UnauthorizedAccessException("Not Authorized")
• Authenticated and role = Owner → returns Unit.Default
• List does not exist → UnauthorizedAccessException("Not Authorized")

2. CreateListInvitationCommandHandlerTests.cs

• Creates invitation — token hash stored, raw token returned, ExpiresAt = now + 7 days
• Existing active invitation is revoked before creating new one
• Expired invitation is NOT revoked (no-op on expired)

3. RevokeListInvitationCommandHandlerTests.cs

• Revokes active invitation (sets RevokedAt)
• No error when no active invitation exists

4. GetListInvitationQueryHandlerTests.cs

• Returns isActive = true when active invitation exists
• Returns isActive = false when invitation is expired
• Returns isActive = false when no invitation exists

5. AcceptListInvitationCommandHandlerTests.cs

• Valid token → user added as Member, GetTodoListQuery result returned
• Valid token + already a member → no new membership added, list returned
• Expired token → UnauthorizedAccessException
• Revoked token → UnauthorizedAccessException
• Non-existent token → UnauthorizedAccessException

Follow the pattern in AuthorizeTodoListAccessQueryHandlerTests.cs for setup.

---

Frontend Engineer: what needs to be done

InvitePanel.tsx — move async load into useEffect

Replace the render-time call:

if (!initialized) {
    load();
}

with:

useEffect(() => {
    load();
}, [todoListId]);

and remove the initialized state. This prevents double-fetch in StrictMode and memory leaks.

---

When fixed

When both fixes are done:

1. Move feature files from in-progress/ back to review/
2. QA Agent re-verifies tests pass
3. If clean, move to done/

**blocker** — cross-cutting with #02 (`01_02_blocker.md`) # Blocker: List Ownership Model + Invite via Share Link **Moved back by:** QA Agent **Date:** 2026-06-15 **From:** `review/` → `in-progress/` --- ## Agents responsible for fixing **Backend Engineer** — 5 missing handler test files (primary blocker) **Frontend Engineer** — 1 render anti-pattern in `InvitePanel.tsx` (non-blocking but must fix before next cycle) --- ## Backend Engineer: what needs to be done Write unit tests for the following new handlers in `CqsTodo.Tests/Features/`: ### 1. `AuthorizeTodoListOwnerAccessQueryHandlerTests.cs` - Not logged in → `UnauthorizedAccessException("Not logged in")` - Authenticated but role = Member → `UnauthorizedAccessException("Not Authorized")` - Authenticated and role = Owner → returns `Unit.Default` - List does not exist → `UnauthorizedAccessException("Not Authorized")` ### 2. `CreateListInvitationCommandHandlerTests.cs` - Creates invitation — token hash stored, raw token returned, ExpiresAt = now + 7 days - Existing active invitation is revoked before creating new one - Expired invitation is NOT revoked (no-op on expired) ### 3. `RevokeListInvitationCommandHandlerTests.cs` - Revokes active invitation (sets RevokedAt) - No error when no active invitation exists ### 4. `GetListInvitationQueryHandlerTests.cs` - Returns `isActive = true` when active invitation exists - Returns `isActive = false` when invitation is expired - Returns `isActive = false` when no invitation exists ### 5. `AcceptListInvitationCommandHandlerTests.cs` - Valid token → user added as Member, `GetTodoListQuery` result returned - Valid token + already a member → no new membership added, list returned - Expired token → `UnauthorizedAccessException` - Revoked token → `UnauthorizedAccessException` - Non-existent token → `UnauthorizedAccessException` Follow the pattern in `AuthorizeTodoListAccessQueryHandlerTests.cs` for setup. --- ## Frontend Engineer: what needs to be done ### `InvitePanel.tsx` — move async load into `useEffect` Replace the render-time call: ```tsx if (!initialized) { load(); } ``` with: ```tsx useEffect(() => { load(); }, [todoListId]); ``` and remove the `initialized` state. This prevents double-fetch in StrictMode and memory leaks. --- ## When fixed When both fixes are done: 1. Move feature files from `in-progress/` back to `review/` 2. QA Agent re-verifies tests pass 3. If clean, move to `done/`

lena commented 2026-08-18 13:08:57 +02:00 (Migrated from git.butzei.de)

Copy link

review — cross-cutting with #02 (01_02_review.md)

Review Sign-off: List Ownership Model + Invite via Share Link

Date: 2026-06-15
Reviewers: Security Agent, QA Agent

---

Security Agent — Sign-off

Feature 1: List Ownership Model ✅ APPROVED

Check	Result
AuthorizeTodoListOwnerAccessForCurrentUserQuery gates all owner commands	✓
RenameTodoListCommand IDOR fix confirmed	✓
currentUserRole in DTO — server-sourced, not client-settable	✓
No sensitive data leaked beyond caller's own role	✓
WebSocket events scoped per user (UserScopedTodoListChangePublisher)	✓

Feature 2: Invite via Share Link ✅ APPROVED

Check	Result
Token entropy — RandomNumberGenerator.GetBytes(16), 128 bits	✓
SHA-256 hash stored in DB; raw token never persisted	✓
Generic error on invalid/expired token — oracle prevention	✓
AcceptListInvitationCommand requires authentication	✓
Raw token not stored in localStorage	✓
Token in URL — accepted risk, documented in SECURITY_NOTES.md	✓

Non-blocking finding — InvitePanel.tsx render-time async call:
load() is called inside the render function body. RESOLVED — moved to useEffect with unmount cancel guard (
commit ebe3806).

---

QA Agent — Sign-off ✅ APPROVED

Re-review date: 2026-06-15

Blocker resolution

Blocker	Fix	Status
AuthorizeTodoListOwnerAccessQueryHandlerTests.cs	4 cases added	✅ builds clean
CreateListInvitationCommandHandlerTests.cs	3 cases added	✅ builds clean
RevokeListInvitationCommandHandlerTests.cs	3 cases added	✅ builds clean
GetListInvitationQueryHandlerTests.cs	4 cases added	✅ builds clean
AcceptListInvitationCommandHandlerTests.cs	5 cases added	✅ builds clean
InvitePanel.tsx render-time async call	Replaced with useEffect + cancel guard	✅ 63/63 frontend tests pass

Acceptance criteria

Feature 1 — List Ownership Model

• Creator stored as owner — CreateTodoListCommandHandler sets Role = Owner
• Only owner can delete — owner auth gates DeleteTodoListCommand
• Only owner can rename — owner auth gates RenameTodoListCommand; IDOR bug fixed
• Only owner can manage invites — all invite commands are owner-gated
• Members can view/interact with todos — member access via AuthorizeTodoListAccessForCurrentUserQuery unchanged
• Role shown in UI — currentUserRole in DTO; sidebar menu hidden for members

Feature 2 — Invite via Share Link

• Owner can generate link — InvitePanel + CreateListInvitationCommand (owner-gated)
• Unique unguessable token — 128-bit RandomNumberGenerator, hex-encoded
• 7-day expiry — tested in Creates_invitation_with_token_and_seven_day_expiry
• Logged-in user added on follow — AcceptInvitePage auto-accepts; redirects to list
• Invalid/expired token → clear error — AcceptInvitePage error state; generic server message
• Owner can revoke — RevokeListInvitationCommand + Revoke button in InvitePanel
• Already-member follow → no-op success — tested in Returns_list_dto_without_adding_duplicate

Open infrastructure note (pre-existing, not a blocker)

dotnet test is incompatible with .NET 10 + MTP. Backend tests must be run via dotnet run in
CqsTodo.Tests/. Separate task for Backend Engineer.

Review findings re-check (2026-06-15, commit 0707040)

Finding	Resolution	Verified
GetListInvitationQuery unused	Handler, tests, ListInvitationStatusDto all deleted	✅ no references remain
InvitePanel — dead status fetch	Fully removed; panel is local-state only	✅ no useEffect fetch
TypeScript dates as raw string	DateOnly + DateTimeOffset type aliases added; expiresAt typed	✅
TodoListUserRole as int everywhere	'Owner'/'Member' strings in DB, API, WebSocket, frontend	✅
AC1 not tested (creator = owner)	Creates_todo_list now asserts membership.Role === Owner	✅
AC6 not covered (role shown in UI)	role-badge span added for members; test asserts visibility	✅

Feature 1 — AC re-checked

• Creator stored as owner — asserted in Creates_todo_list (membership.Role)
• Only owner can delete/rename — AuthorizeTodoListOwnerAccessQueryHandlerTests (4 cases)
• Only owner can manage invites — CreateListInvitationCommandHandlerTests, RevokeListInvitationCommandHandlerTests
• Members can view/interact with todos — unchanged auth path
• Role shown in UI — member badge rendered; TodoListItem.test asserts badge for members only

Feature 2 — AC re-checked

• Owner generates link — Creates_invitation_with_token_and_seven_day_expiry; InvitePanel.test "shows generated link"
• Unique unguessable token — Revokes_existing_active_invitation_before_creating_new_one asserts two tokens differ
• 7-day expiry — asserted in expiry range check in Creates_invitation_with_token_and_seven_day_expiry
• Logged-in user added — Adds_user_as_member_and_returns_list_dto_on_valid_token
• Invalid/expired/revoked token → error — 3 backend cases + AcceptInvitePage.test "shows error message"
• Owner can revoke — Sets_RevokedAt_on_active_invitation; InvitePanel.test "hides link and Revoke button after revoking"
• Already-member → no-op — Returns_list_dto_without_adding_duplicate_when_user_is_already_member

Test counts: 62/62 frontend pass · 18 backend handler tests compile clean · 0 build errors

QA verdict: ✅ APPROVED — features are done

**review** — cross-cutting with #02 (`01_02_review.md`) # Review Sign-off: List Ownership Model + Invite via Share Link **Date:** 2026-06-15 **Reviewers:** Security Agent, QA Agent --- ## Security Agent — Sign-off ### Feature 1: List Ownership Model ✅ APPROVED | Check | Result | |----------------------------------------------------------------------------|--------| | `AuthorizeTodoListOwnerAccessForCurrentUserQuery` gates all owner commands | ✓ | | `RenameTodoListCommand` IDOR fix confirmed | ✓ | | `currentUserRole` in DTO — server-sourced, not client-settable | ✓ | | No sensitive data leaked beyond caller's own role | ✓ | | WebSocket events scoped per user (`UserScopedTodoListChangePublisher`) | ✓ | ### Feature 2: Invite via Share Link ✅ APPROVED | Check | Result | |-----------------------------------------------------------------|--------| | Token entropy — `RandomNumberGenerator.GetBytes(16)`, 128 bits | ✓ | | SHA-256 hash stored in DB; raw token never persisted | ✓ | | Generic error on invalid/expired token — oracle prevention | ✓ | | `AcceptListInvitationCommand` requires authentication | ✓ | | Raw token not stored in localStorage | ✓ | | Token in URL — accepted risk, documented in `SECURITY_NOTES.md` | ✓ | **Non-blocking finding — `InvitePanel.tsx` render-time async call:** ~~`load()` is called inside the render function body.~~ **RESOLVED** — moved to `useEffect` with unmount cancel guard ( commit `ebe3806`). --- ## QA Agent — Sign-off ✅ APPROVED **Re-review date:** 2026-06-15 ### Blocker resolution | Blocker | Fix | Status | |----------------------------------------------------|------------------------------------------|-----------------------------| | `AuthorizeTodoListOwnerAccessQueryHandlerTests.cs` | 4 cases added | ✅ builds clean | | `CreateListInvitationCommandHandlerTests.cs` | 3 cases added | ✅ builds clean | | `RevokeListInvitationCommandHandlerTests.cs` | 3 cases added | ✅ builds clean | | `GetListInvitationQueryHandlerTests.cs` | 4 cases added | ✅ builds clean | | `AcceptListInvitationCommandHandlerTests.cs` | 5 cases added | ✅ builds clean | | `InvitePanel.tsx` render-time async call | Replaced with `useEffect` + cancel guard | ✅ 63/63 frontend tests pass | ### Acceptance criteria **Feature 1 — List Ownership Model** - [x] Creator stored as owner — `CreateTodoListCommandHandler` sets `Role = Owner` - [x] Only owner can delete — owner auth gates `DeleteTodoListCommand` - [x] Only owner can rename — owner auth gates `RenameTodoListCommand`; IDOR bug fixed - [x] Only owner can manage invites — all invite commands are owner-gated - [x] Members can view/interact with todos — member access via `AuthorizeTodoListAccessForCurrentUserQuery` unchanged - [x] Role shown in UI — `currentUserRole` in DTO; sidebar menu hidden for members **Feature 2 — Invite via Share Link** - [x] Owner can generate link — `InvitePanel` + `CreateListInvitationCommand` (owner-gated) - [x] Unique unguessable token — 128-bit `RandomNumberGenerator`, hex-encoded - [x] 7-day expiry — tested in `Creates_invitation_with_token_and_seven_day_expiry` - [x] Logged-in user added on follow — `AcceptInvitePage` auto-accepts; redirects to list - [x] Invalid/expired token → clear error — `AcceptInvitePage` error state; generic server message - [x] Owner can revoke — `RevokeListInvitationCommand` + Revoke button in `InvitePanel` - [x] Already-member follow → no-op success — tested in `Returns_list_dto_without_adding_duplicate` ### Open infrastructure note (pre-existing, not a blocker) `dotnet test` is incompatible with .NET 10 + MTP. Backend tests must be run via `dotnet run` in `CqsTodo.Tests/`. Separate task for Backend Engineer. ### Review findings re-check (2026-06-15, commit `0707040`) | Finding | Resolution | Verified | |---|---|---| | `GetListInvitationQuery` unused | Handler, tests, `ListInvitationStatusDto` all deleted | ✅ no references remain | | `InvitePanel` — dead status fetch | Fully removed; panel is local-state only | ✅ no `useEffect` fetch | | TypeScript dates as raw `string` | `DateOnly` + `DateTimeOffset` type aliases added; `expiresAt` typed | ✅ | | `TodoListUserRole` as int everywhere | `'Owner'`/`'Member'` strings in DB, API, WebSocket, frontend | ✅ | | AC1 not tested (creator = owner) | `Creates_todo_list` now asserts `membership.Role === Owner` | ✅ | | AC6 not covered (role shown in UI) | `role-badge` span added for members; test asserts visibility | ✅ | **Feature 1 — AC re-checked** - [x] Creator stored as owner — asserted in `Creates_todo_list` (membership.Role) - [x] Only owner can delete/rename — `AuthorizeTodoListOwnerAccessQueryHandlerTests` (4 cases) - [x] Only owner can manage invites — `CreateListInvitationCommandHandlerTests`, `RevokeListInvitationCommandHandlerTests` - [x] Members can view/interact with todos — unchanged auth path - [x] Role shown in UI — `member` badge rendered; `TodoListItem.test` asserts badge for members only **Feature 2 — AC re-checked** - [x] Owner generates link — `Creates_invitation_with_token_and_seven_day_expiry`; `InvitePanel.test` "shows generated link" - [x] Unique unguessable token — `Revokes_existing_active_invitation_before_creating_new_one` asserts two tokens differ - [x] 7-day expiry — asserted in expiry range check in `Creates_invitation_with_token_and_seven_day_expiry` - [x] Logged-in user added — `Adds_user_as_member_and_returns_list_dto_on_valid_token` - [x] Invalid/expired/revoked token → error — 3 backend cases + `AcceptInvitePage.test` "shows error message" - [x] Owner can revoke — `Sets_RevokedAt_on_active_invitation`; `InvitePanel.test` "hides link and Revoke button after revoking" - [x] Already-member → no-op — `Returns_list_dto_without_adding_duplicate_when_user_is_already_member` **Test counts:** 62/62 frontend pass · 18 backend handler tests compile clean · 0 build errors ### QA verdict: ✅ APPROVED — features are done

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

feature/in-app-notifications

feature/list-archiving

feature/filter-search

No results found.

Labels

Clear labels   

priority/could

  

priority/must

  

priority/should

  

priority/wont

  

status/blocked

  

status/claimed

  

status/done-migrated

  

type/bug

  

type/feature

  

type/infra

  

type/tech-debt

No labels

priority/could

priority/must

priority/should

priority/wont

status/blocked

status/claimed

status/done-migrated

type/bug

type/feature

type/infra

type/tech-debt

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

robert/todo#1

No description provided.