- Shipped
- September 17, 2026 at 5:42 PM UTC
- Author
- Kamo
- Commit
- ef8f9d2
A head's id is its window's id (`chat-3`), and the menu read it as the member it was a chat with. So it fetched /api/security/members/chat-3 — a 404 — and with no member there was no Email row and no Call row at all; it asked presence about `chat-3`, which is nobody, so every chat head read "Offline"; and View Member Account opened /settings/member/chat-3. The people are read from the conversation behind the window, the same way the meeting invite now does: the session roster, falling back to the member the window was opened for. One other person means a direct chat and the per-person rows apply; a group has nobody in particular, so they are left off rather than pointed at an arbitrary member. The engine no longer sends a member id it does not have. The profile mapping was wrong as well, so even a correct lookup would have left the menu with no name and no Call row: SecurityService serves nameFirst / nameLast and phoneWorkExtension (the work extension the Interaction Center's call button dials), not `name` and `extension`. memberDetailFrom reads the payload that endpoint really returns, and still accepts the roster shape.