Skip to content
This repository was archived by the owner on Mar 26, 2026. It is now read-only.

fix(ui): operator messages show in Agent Conversations instead of Your Conversations#292

Merged
jsell-rh merged 4 commits intomainfrom
fix/operator-messages-conversations-view
Mar 24, 2026
Merged

fix(ui): operator messages show in Agent Conversations instead of Your Conversations#292
jsell-rh merged 4 commits intomainfrom
fix/operator-messages-conversations-view

Conversation

@jsell-rh
Copy link
Copy Markdown
Owner

Root Cause

Both 'boss' (legacy) and 'operator' agents have agent_type='human' in the DB. The operatorName computed returned whichever was found first via Object.entries, which follows insertion order. In spaces where 'boss' was created first, operatorName='boss'.

Bug consequences when operatorName='boss' but messages carry sender 'operator':

  • Conversations with 'operator' as participant appear under Agent Conversations (not Your Conversations)
  • composeRecipient is null for those conversations → no compose box shown → operator cannot send messages
  • Unread acknowledgement uses wrong recipient name

Fix

Collect ALL agent_type='human' agents into a humanAgentNames Set (instead of picking just one). Use that Set consistently:

Usage Before After
isOperatorConversation participants.includes(operatorName) participants.some(p => humanAgentNames.has(p))
composeRecipient !participants.includes(operatorName) !participants.some(p => humanAgentNames.has(p))
unreadCount recipient === operatorName humanAgentNames.has(recipient)
ackOperatorMessages hard-coded operatorName as ack target ack per msg.recipient
operatorName itself first human found prefer 'operator'; fall back to first human then 'operator'

Test Plan

  • Open Conversations view in a space that has both boss and operator agents
  • Verify messages sent by operator appear under Your Conversations
  • Verify compose box appears for all human↔agent threads
  • Verify unread badges and ack work for messages in operator inbox

Frontend TypeScript build: ✓ clean (vue-tsc -b + vite build)

🤖 Generated with Claude Code

jsell-rh and others added 4 commits March 23, 2026 15:26
…-setup.sh

Aligns scripts with CLAUDE.md docs (PR #290). MCP server name changed from
boss-dev to odis-dev in the generated JSON config, allowed tools list, and
output messages. BOSS_API_TOKEN/BOSS_MCP_URL env vars kept as fallbacks for
backward compatibility (prefer ODIS_API_TOKEN/ODIS_MCP_URL going forward).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…our Conversations

Root cause: both 'boss' (legacy) and 'operator' agents have agent_type='human' in the
DB. operatorName computed returned whichever was found first via Object.entries, which
is insertion-order. In spaces where 'boss' was created first, operatorName='boss'.

Consequences when operatorName='boss' but messages use 'operator':
- Conversations with 'operator' participant went to Agent Conversations section
- composeRecipient was null for those conversations (no compose box shown)
- Unread acks used wrong agent name

Fix: collect ALL human agents into humanAgentNames Set. Use it for:
- isOperatorConversation: any participant that is a human agent
- composeRecipient: any participant that is NOT a human agent
- unreadCount / ackOperatorMessages: any human-agent recipient
- operatorName: prefer 'operator' (canonical) over legacy 'boss'

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…tion threads

When agents use different capitalizations (e.g. "CEO" vs "ceo"), messages were stored
with the raw sender name, creating separate conversation threads in the UI for what
should be a single conversation.

Both handleAgentMessage (HTTP) and send_message (MCP tool) now call resolveAgentName
on the sender after the space is loaded, mapping to the canonical stored name if the
sender is a known agent. Unknown senders keep their original name unchanged.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@jsell-rh jsell-rh merged commit c02d720 into main Mar 24, 2026
3 checks passed
@jsell-rh jsell-rh deleted the fix/operator-messages-conversations-view branch March 24, 2026 14:35
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant