Skip to content

fix the talk to human bugs #1307

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 30, 2025
Merged

fix the talk to human bugs #1307

merged 2 commits into from
Mar 30, 2025

Conversation

panwaranuj01
Copy link
Contributor

@panwaranuj01 panwaranuj01 commented Mar 28, 2025

What do you want to achieve?

  • fix the talk to human bugs

PR Checklist

  • I have tested it locally and all functionalities are working fine.
  • I have compared it with mocks and all design elements are the same.
  • I have tested it in IE Browser.

How was the code tested?

What new thing you came across while writing this code?

In case you fixed a bug then please describe the root cause of it?

Screenshot

NOTE: Make sure you're comparing your branch with the correct base branch

Summary by CodeRabbit

  • New Features
    • Enhanced the chat interface by refining when typing indicators appear, ensuring a smoother experience when human assistance is engaged.
    • Improved conversation management by better handling waiting states and adjusting action button visibility based on the conversation context.
    • Streamlined transitions, including adjustments during conversation transfers and when specific user interactions occur.

Copy link

github-actions bot commented Mar 28, 2025

Warnings
⚠️ Please add the JIRA issue key to the PR title (e.g. FW-123)
Messages
📖 New Files in this PR: - 0

Generated by 🚫 dangerJS against 57c7487

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 19b1672 and 6fb274a.

📒 Files selected for processing (3)
  • webplugin/js/app/components/typing-service.js (3 hunks)
  • webplugin/js/app/kommunicate-ui.js (1 hunks)
  • webplugin/js/app/mck-sidebox-1.0.js (5 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
webplugin/js/app/mck-sidebox-1.0.js (1)
webplugin/js/app/components/typing-service.js (1)
  • typingService (180-180)
🔇 Additional comments (9)
webplugin/js/app/mck-sidebox-1.0.js (6)

4539-4539: Properly initializing waiting queue state.

The addition of CURRENT_GROUP_DATA.isWaitingQueue = false here ensures the waiting queue state is properly reset when transitioning out of a waiting queue scenario.


5123-5123: Initializing waiting queue flag during conversation setup.

Setting isWaitingQueue to false during conversation initialization is appropriate to ensure consistent behavior across different entry points to conversation threads.


5610-5613: Correctly handling talk-to-human metadata.

This addition properly detects when a message contains the TALK_TO_HUMAN metadata and informs the typing service to adjust its behavior accordingly. This is crucial for the bug fix described in the PR objectives.


6867-6867: Consistent initialization of waiting queue state.

Setting isWaitingQueue to false during group data initialization ensures consistent behavior in the application.


7928-7928: Resetting talk-to-human flag at message processing start.

This change effectively prevents the typing indicator state from being carried over between messages, which is important for ensuring the correct display of typing indicators.


5614-5616:

❓ Verification inconclusive

Verify bot-specific typing indicator behavior.

Make sure this condition appropriately handles all edge cases, especially transitions between bot and human agents when "talk to human" is triggered.


🏁 Script executed:

#!/bin/bash
# Check for any other conditions where typing indicators might be shown or hidden
rg -A 5 -B 5 "showTypingIndicator" webplugin/js/

Length of output: 4166


Action: Verify Bot Typing Indicator Behavior

After reviewing the code and the search results:

  • The condition in webplugin/js/app/mck-sidebox-1.0.js (lines 5614–5616) calls typingService.showTypingIndicator() only when KommunicateUtils.isCurrentAssigneeBot() is true. This suggests that bot sessions are the target for displaying the typing indicator.
  • Within webplugin/js/app/components/typing-service.js, the showTypingIndicator() method already checks for cases where a "talk to human" action is in process (via this.isKmTalkToHumanMsg or CURRENT_GROUP_DATA.isWaitingQueue) to prevent showing the indicator. This appears to help handle transitions between bot and human agents.
  • There are additional invocations of typingService.showTypingIndicator() in the file. Please double-check that these do not conflict with the intended behavior during transitions and that there are no duplicated calls resulting in inconsistent UI states.

Please verify manually (or via integration tests) that the logic properly handles all edge cases, especially when a user triggers the "talk to human" option and the session transitions from a bot to a human agent.

webplugin/js/app/components/typing-service.js (2)

12-12: Good addition of the isKmTalkToHumanMsg property.

The new property is properly initialized as false in the constructor and will be used to control typing indicator visibility.


24-26: Well implemented setter method for isKmTalkToHumanMsg.

This method follows a good pattern for modifying the property state.

webplugin/js/app/kommunicate-ui.js (1)

1578-1586: Good UI enhancement for waiting queue state.

The modifications correctly show the "talk to human" and "restart conversation" buttons when in a waiting queue. Setting the isWaitingQueue flag enables the typing indicator to be suppressed in this scenario as implemented in the typing-service.js file.

One suggestion: consider adding a comment explaining the purpose of setting CURRENT_GROUP_DATA.isWaitingQueue = true to make the code more maintainable.

@panwaranuj01 panwaranuj01 requested a review from Copilot March 28, 2025 12:38
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR aims to fix bugs in the talk-to-human interaction by adjusting state management for the waiting queue and updating the corresponding UI and typing indicator behavior.

  • Removes redundant or misaligned resets of the waiting queue flag in the sidebox.
  • Updates the UI to correctly mark the waiting queue state for talk-to-human interactions.
  • Enhances the typing service logic to conditionally suppress the typing indicator when in talk-to-human mode.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File Description
webplugin/js/app/mck-sidebox-1.0.js Adjusts the CURRENT_GROUP_DATA.isWaitingQueue flag and toggles messaging based on state
webplugin/js/app/kommunicate-ui.js Modifies UI elements and sets the waiting queue flag for talk-to-human options
webplugin/js/app/components/typing-service.js Introduces and uses a talk-to-human flag to conditionally suppress the typing indicator
Comments suppressed due to low confidence (3)

webplugin/js/app/mck-sidebox-1.0.js:4539

  • [nitpick] The waiting queue flag is reset here; please ensure that this reset does not conflict with its expected state in other modules, and consider centralizing its management for clarity.
CURRENT_GROUP_DATA.isWaitingQueue = false;

webplugin/js/app/kommunicate-ui.js:1586

  • [nitpick] Setting the waiting queue flag to true at this point should be reviewed alongside the resets in other parts of the code to avoid any state inconsistencies during the talk-to-human workflow.
CURRENT_GROUP_DATA.isWaitingQueue = true;

webplugin/js/app/components/typing-service.js:64

  • [nitpick] Verify that using an OR condition for both the talk-to-human flag and the waiting queue state correctly reflects the intended behavior for suppressing the typing indicator.
if (this.isKmTalkToHumanMsg || CURRENT_GROUP_DATA.isWaitingQueue) return; // don't show loader when user clicking on the talk to human button

AashishBhatt5
AashishBhatt5 previously approved these changes Mar 28, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
webplugin/js/app/kommunicate-client.js (1)

68-68: Initialization added for waiting queue state

This line initializes the waiting queue state to false when creating a conversation, which is a good addition to ensure consistent initial state for the "talk to human" functionality.

Consider improving the code in two ways:

  1. Add a more descriptive comment explaining the purpose (e.g., "Initialize waiting queue state to prevent showing loading indicator initially")
  2. Add a safety check to ensure CURRENT_GROUP_DATA exists before setting the property
- CURRENT_GROUP_DATA.isWaitingQueue = false; // for showing the loader in screen
+ // Initialize waiting queue state to prevent showing loading indicator initially
+ if (CURRENT_GROUP_DATA) {
+   CURRENT_GROUP_DATA.isWaitingQueue = false;
+ }
webplugin/js/app/mck-sidebox-1.0.js (2)

5608-5614: Set talk to human message flag when message contains TALK_TO_HUMAN metadata

This code correctly identifies when a "Talk to Human" request is made by checking for the 'TALK_TO_HUMAN' property in the message metadata and updates the typing service accordingly.

However, I recommend checking if messagePxy.metadata exists before accessing its properties to prevent potential errors.

-if (messagePxy.metadata.hasOwnProperty('TALK_TO_HUMAN')) {
+if (messagePxy.metadata && messagePxy.metadata.hasOwnProperty('TALK_TO_HUMAN')) {
    typingService.setTalkToHumanMsg(true);
}

7173-7184: Prevent CTA setup when contact list is present

Good addition that prevents setting up the primary CTA when the contact list is present, avoiding potential UI conflicts.

The commented-out code on line 7184 should either be removed or uncommented if it's needed.

-// kommunicateCommons.modifyClassList({ id: ['km-header-cta'] }, '', 'n-vis');
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro (Legacy)

📥 Commits

Reviewing files that changed from the base of the PR and between 19b1672 and 57c7487.

📒 Files selected for processing (4)
  • webplugin/js/app/components/typing-service.js (3 hunks)
  • webplugin/js/app/kommunicate-client.js (1 hunks)
  • webplugin/js/app/kommunicate-ui.js (1 hunks)
  • webplugin/js/app/mck-sidebox-1.0.js (7 hunks)
🧰 Additional context used
🧠 Learnings (1)
webplugin/js/app/components/typing-service.js (1)
Learnt from: panwaranuj01
PR: Kommunicate-io/Kommunicate-Web-SDK#1307
File: webplugin/js/app/components/typing-service.js:64-65
Timestamp: 2025-03-28T12:35:47.893Z
Learning: In the Kommunicate-Web-SDK codebase, CURRENT_GROUP_DATA is guaranteed to be present when the showTypingIndicator method in typing-service.js is called, so null checks are not required when accessing its properties.
🧬 Code Definitions (1)
webplugin/js/app/mck-sidebox-1.0.js (1)
webplugin/js/app/components/typing-service.js (1)
  • typingService (180-180)
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: Chat-Widget-Test (km-dev-434106)
🔇 Additional comments (9)
webplugin/js/app/mck-sidebox-1.0.js (5)

671-675: Conditionally hide the "Talk to Human" button when no group feeds exist

Good addition that prevents the "Talk to Human" button from displaying when there are no group feeds. The use of optional chaining helps prevent errors if data is undefined.


4537-4540: Reset waiting queue state when conversation is transferred

This change correctly resets the waiting queue state when a conversation is transferred. This aligns with initialization logic in other parts of the code.


5121-5124: Initialize waiting queue state

Proper initialization of the waiting queue state, which helps prevent issues with typing indicators and UI elements that depend on this flag.


6865-6868: Initialize waiting queue state during group creation

Properly initializes the waiting queue state when setting up group data, ensuring consistent state management.


7928-7931: Reset talk to human message flag when processing new messages

The addition correctly resets the "Talk to Human" message flag at the beginning of what appears to be a message processing function, ensuring proper state management.

webplugin/js/app/kommunicate-ui.js (1)

1578-1586: Good implementation for handling waiting queue UI elements.

The modifications to show the "Talk to Human" and "Restart Conversation" buttons when in waiting queue state are well-implemented. Setting CURRENT_GROUP_DATA.isWaitingQueue = true provides a useful flag that other components can use to adjust their behavior accordingly.

webplugin/js/app/components/typing-service.js (3)

12-12: Properly initialized the new flag for talk to human message state.

The new property initializes correctly with a default value, following the existing pattern in the class constructor.


24-26: Well-implemented setter method for the new flag.

The arrow function syntax is appropriate here as it preserves the this context, and the method follows a clean, simple implementation pattern.


64-65: Effectively prevents typing indicator in talk-to-human scenarios.

This condition correctly prevents the typing indicator from displaying when either:

  1. The user is clicking on the talk to human button (isKmTalkToHumanMsg is true)
  2. The conversation is in waiting queue state (CURRENT_GROUP_DATA.isWaitingQueue is true)

The comment clarifies the purpose of this check, which is helpful for future maintenance.

@AashishBhatt5 AashishBhatt5 merged commit 79fbb21 into development Mar 30, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants