langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-08-27 03:01:54 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #26501] fix: conversation opener feature state persistence and display #31460

New Issue
Closed
opened 2026-02-21 20:49:30 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:49:30 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/26501

State: closed
Merged: No

Summary

Fixes #26500

This PR addresses the issue where the conversation opener feature doesn't preserve its enabled state and doesn't work correctly in Chatflow applications.

Root Cause

The frontend was determining the feature's enabled state by checking only if opening_statement had content (!!features.opening_statement). This caused two problems:

  1. When a feature was enabled but had no opening statement, it appeared disabled on reload
  2. The save logic was clearing content when disabled, making it indistinguishable from "enabled with no content"

Changes

  1. Updated feature initialization logic (workflow-app/index.tsx): Now checks for both opening_statement and suggested_questions when determining if the feature is enabled
  2. Simplified save logic (use-nodes-sync-draft.ts): Always sends the actual content instead of conditionally clearing it based on enabled state
  3. Added automatic modal opening (conversation-opener/index.tsx): When user toggles feature on without content, automatically opens the configuration modal
  4. Auto-manage enabled state: The enabled state is now automatically set based on content presence when saving
  5. Handle modal cancellation: If user cancels the modal without adding content, the feature is automatically disabled

Benefits

  • ✅ The feature's enabled state correctly persists across page refreshes
  • ✅ Users must add content (opening statement or suggested questions) to enable the feature
  • ✅ Better UX: toggling the feature on automatically prompts for configuration
  • ✅ Consistent behavior between enabled/disabled states
  • ✅ Works with both opening statements and suggested questions

Test plan

  • Run pnpm lint - passes with no new errors
  • Run type checking - passes with no errors
  • Manual testing:
    • Go to Studio → Chatflow → Orchestrate → Features
    • Enable "Conversation Opener"
    • Verify modal opens automatically
    • Add an opening statement and/or suggested questions
    • Click Save and Publish
    • Refresh the browser
    • Go back to Features
    • Verify "Conversation Opener" is still enabled
    • Preview or Run App
    • Verify the conversation opener displays in the chat
**Original Pull Request:** https://github.com/langgenius/dify/pull/26501 **State:** closed **Merged:** No --- ## Summary Fixes #26500 This PR addresses the issue where the conversation opener feature doesn't preserve its enabled state and doesn't work correctly in Chatflow applications. ### Root Cause The frontend was determining the feature's enabled state by checking only if `opening_statement` had content (`!!features.opening_statement`). This caused two problems: 1. When a feature was enabled but had no opening statement, it appeared disabled on reload 2. The save logic was clearing content when disabled, making it indistinguishable from "enabled with no content" ### Changes 1. **Updated feature initialization logic** (`workflow-app/index.tsx`): Now checks for both `opening_statement` and `suggested_questions` when determining if the feature is enabled 2. **Simplified save logic** (`use-nodes-sync-draft.ts`): Always sends the actual content instead of conditionally clearing it based on enabled state 3. **Added automatic modal opening** (`conversation-opener/index.tsx`): When user toggles feature on without content, automatically opens the configuration modal 4. **Auto-manage enabled state**: The enabled state is now automatically set based on content presence when saving 5. **Handle modal cancellation**: If user cancels the modal without adding content, the feature is automatically disabled ### Benefits - ✅ The feature's enabled state correctly persists across page refreshes - ✅ Users must add content (opening statement or suggested questions) to enable the feature - ✅ Better UX: toggling the feature on automatically prompts for configuration - ✅ Consistent behavior between enabled/disabled states - ✅ Works with both opening statements and suggested questions ## Test plan - [x] Run `pnpm lint` - passes with no new errors - [x] Run type checking - passes with no errors - [ ] Manual testing: - [ ] Go to Studio → Chatflow → Orchestrate → Features - [ ] Enable "Conversation Opener" - [ ] Verify modal opens automatically - [ ] Add an opening statement and/or suggested questions - [ ] Click Save and Publish - [ ] Refresh the browser - [ ] Go back to Features - [ ] Verify "Conversation Opener" is still enabled - [ ] Preview or Run App - [ ] Verify the conversation opener displays in the chat
yindo added the pull-request label 2026-02-21 20:49:30 -05:00
yindo closed this issue 2026-02-21 20:49:30 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#31460
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?