761: Adds PATCH hook to read tagged comment notifications

[DarrellRoberts]

Description

Creates a PATCH hook for tagged comment notifications. When the user clicks on the notification, it triggers this request and writes the readAt property, reducing the number of notifications for tagged comments

Related Issues

Closes #761

Changes

• Creates usePatchTaggedComments hook
• Adds a noToast property to useMutation hook, as I didn't want a toast notification everytime a user clicks on an unread notificaiton (if it is needed then it's also no problem)
• Adds a scrollTo sideeffect to Profile Layout if it has parameter scrollTo with setTimeout. This was so when the user clicks on the notification, the scrollbar navigates to the Coordinator Comments
• Background-color of tagged-notification depends on whether the notification has been read

Screenshots / Demos

Checklist

• WITHIN THE SCOPE OF AN ISSUE; No unnecessary files included
• Tests added/updated
• Documentation updated
• CI passes

[nadavosa]

Review

Adds a usePatchTaggedComments hook that marks a tagged comment as read when clicked, updates notification badge/row styling, and adds scroll-to-comment behavior.

Findings (most severe first):

1. src/components/Dashboard/Home/TaggedNotification.tsx:26-29 — await updateReadTagComment({ read_at: new Date() }) awaits react-query's mutate (fire-and-forget, returns void), not mutateAsync. The await is a no-op — the click navigates away before the PATCH/invalidation actually completes. Should use mutateAsync.

2. src/components/Dashboard/Home/NewestTaggedComments.tsx:22-24 — handleIsRead treats "no matching tag found" as read (undefined !== null → true). While useCurrentUser() is loading, personId defaults to -1, so the tag lookup finds nothing, the notification renders as already-read, and the mark-as-read PATCH gets silently skipped on click for that render.

3. src/components/Layout/DashboardLayout/NotificationBadge.tsx:30-32 — Unread count flattens all tagged persons per comment (tagComments?.flatMap(c => c.taggedPersons)?.filter(c => !c.readAt)), not just the current user's entry. A comment tagging both User A and User B, where only B hasn't read it, still increments A's badge — count is contaminated by other users' read state.

4. SDK-contract gap — src/hooks/usePatchTaggedComments.ts:5-15 — Invents PATCH ${apiPathComment}/${commentId}/read with a snake_case read_at body field that doesn't exist in the published need4deed-sdk (v0.0.118) — no endpoint, and every other field/hook in the codebase uses camelCase readAt (e.g. useUpdateComment.ts PATCHes ${apiPathComment}/${commentId} directly, camelCase body). Per .claude/shared-rules.md, API-surface changes should go through the SDK contract first rather than being guessed locally in fe.

5. Reuse nit — useUpdateComment.ts already PATCHes the same comment resource; this adds a near-duplicate one-off hook for a sibling sub-resource instead of extending that existing path.

Findings 1-3 are concrete correctness bugs with reproducible failure scenarios; 4-5 are rule/process concerns rather than crashes.

[DarrellRoberts]

thanks @nadavosa for reviewing! All good points, especially point 3. which I completely missed (needed to test with multiple tags).
I disagree only with point 5. as useUpdateComment is a completely different hook which edits a comment with a different endpoint so should be separate.

I've now pushed my changes

[nadavosa]

Claude went through this:
Likely bug — TaggedNotification.tsx handleReadTag:

const handleReadTag = async (e: React.MouseEvent) => {
  if (isRead) return;
  e.preventDefault();
  await updateReadTagComment({ id: personId, readAt: new Date() });
};

Since this cancels the wrapped <Link>'s navigation via preventDefault(), and there's no navigation call after the mutation resolves, the first click on an unread notification only marks it read — it doesn't take the user anywhere. They'd need to click the same notification a second time (once isRead flips to true and the early-return skips preventDefault) to actually navigate to the comment. Given the PR description says clicking should scroll to Coordinator Comments, this seems like it should either not call preventDefault at all (fire-and-forget the mark-as-read alongside normal navigation), or navigate programmatically after the mutation resolves.

Minor — NewestTaggedComments.tsx handleIsRead:

return taggedComment?.readAt !== null;

If taggedComment isn't found in taggedPersons (shouldn't normally happen, but there's no guard), undefined !== null evaluates to true, silently treating "not found" as "read". Probably safer as !!taggedComment?.readAt.

Good catch (no action needed): I double-checked the scrollTo: "coordinator-comments" unification against the old per-entity-type hash targets (opportunity-volunteers-container, communication-tracker-container) — those actually pointed at unrelated sections (volunteer matching / communication log), not the comments section. The new approach correctly targets the shared EntityComments container used by all three entity types, so this is an improvement over the previous behavior.

[DarrellRoberts]

thanks @nadavosa , have pushed my changes