From 8253ec0659fca952dc962657f2c7633001d70f99 Mon Sep 17 00:00:00 2001 From: moojttaba Date: Thu, 4 Jun 2026 00:23:24 +0330 Subject: [PATCH] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20chat=20par?= =?UTF-8?q?ticipant=20fix=20revert=20(v2.8.73)=20+=20template=20validation?= =?UTF-8?q?=20(frontend=20v2.8.80)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- 09 - Audits/Activity Log.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md index c839db9..d532389 100644 --- a/09 - Audits/Activity Log.md +++ b/09 - Audits/Activity Log.md @@ -1104,4 +1104,23 @@ template fields can now be left empty end-to-end. --- +### 2026-06-04 — backend v2.8.72→v2.8.73 (chat participant fix reverted) + frontend v2.8.80 (template validation visibility) + +**Backend chat — attempted + reverted.** v2.8.72 tried to canonicalize chat +participant ids (userRepo.findById) so a buyer (marketplace uuid for the seller) +and seller (legacy ObjectId session) would share one direct thread. It backfired: +findById returns an id format (Mongo ObjectId / PG uuid) that no longer matches +the session JWT id, so the membership check rejected everyone ("User is not a +participant"). v2.8.73 reverts to storing ids as passed (restores chat access). +**Open issue:** buyer↔seller messages still don't cross — they land in separate +direct conversations because the seller is referenced by a uuid while the session +id is a legacy ObjectId (users in Mongo, chats in Postgres). Needs a correct +uuid→legacyObjectId resolution (via marketplace id_map), not the session-breaking +findById path. Deferred for a careful fix. +**Frontend v2.8.80:** template-form onInvalid now expands all collapsed accordion +sections and toasts the actual nested error messages, so validation errors are +visible under their fields instead of only in the console. + +--- +