feat(frontend): adjust Dify bot configuration layout for better PC experience #197
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit integrates Dify as a third agent runtime alongside ClaudeCode and Agno, following the CRD-based architecture pattern. Changes: - Implemented DifyAgent class with full Dify API integration - Supports streaming API responses from Dify chat-messages endpoint - Manages conversation IDs for multi-turn dialogues - Parses bot_prompt JSON for dynamic app ID and parameter configuration - Validates required configuration (API key, base URL, app ID) - Registered DifyAgent in AgentFactory for runtime selection - Added Dify Shell configuration to public shells initialization data - Implemented Team validation constraint: Dify teams must have exactly one bot - Added validation in TeamKindsService._validate_bots method - Checks shell runtime and enforces single-bot rule for Dify - Created comprehensive unit tests - test_dify_agent.py: Tests for DifyAgent functionality including initialization, configuration validation, API calls, and conversation management - Updated test_factory.py: Added Dify agent creation tests Technical highlights: - Follows existing agent architecture patterns (base.Agent inheritance) - Configuration extracted from Model.env (DIFY_API_KEY, DIFY_BASE_URL, DIFY_APP_ID) - Supports dynamic app ID override via Team.members[].prompt JSON - Handles Dify API streaming responses with proper error handling - Maintains conversation context across multiple task executions
This commit implements the frontend components and API integration for Dify agent support, completing Phase 2 of the Dify integration.
Backend Changes:
- Created /api/v1/dify/apps endpoint to fetch user's Dify applications
- Created /api/v1/dify/apps/{app_id}/parameters endpoint for app parameter schemas
- Registered Dify router in main API configuration
- Fetches apps using user's configured DIFY_API_KEY and DIFY_BASE_URL from Model
Frontend Changes:
- Added DifyApp, DifyBotPrompt, DifyParameterField, DifyParametersSchema types
- Created DifyAppSelector component:
- Fetches and displays available Dify applications
- Auto-detects Dify teams based on bot_prompt structure
- Provides dropdown selector for switching between apps
- Displays app icon, name, and mode (chat/workflow/agent/chatflow)
- Created DifyParamsForm component:
- Provides JSON editor for Dify application parameters
- Includes quick edit interface for individual parameters
- Persists parameters to localStorage per team (dify_params_team_{team_id})
- Collapsible accordion UI for clean integration
- Auto-loads cached parameters on team selection
- Created dify.ts API client with getDifyApps() and getDifyAppParameters() functions
Technical Highlights:
- Components auto-detect Dify teams by checking bot_prompt JSON structure
- Parameters are cached in localStorage for persistence across sessions
- Clean UI integration using existing design system components
- Type-safe API calls with proper TypeScript interfaces
- Error handling with user-friendly messages
Integration Notes:
- DifyAppSelector can be integrated into ChatArea or Workbench header
- DifyParamsForm should be placed near ChatInput or in a sidebar
- Components automatically show/hide based on selected team runtime
- Ready for final integration into main chat interface
Introduced shellType field to distinguish between local execution engines and external API services. This architectural improvement provides better separation of concerns and enables runtime optimization. Key changes: Backend: - Added shellType field to Shell schema (local_engine | external_api) - Updated all Shell configurations with explicit type classification - Refactored Team validation to use generic shellType instead of hardcoded runtime checks - Created shell_utils.py with utility functions for shell type detection Executor: - Added AGENT_TYPE constant to DifyAgent for type classification - Implemented optimized pre_execute method for external API agents (skips code download) - Enhanced AgentFactory with type classification methods (is_external_api_agent, get_agent_type) Frontend: - Added Shell TypeScript interface with shell_type field Benefits: - Clearer architectural boundaries between local engines and external APIs - Performance optimization for external API agents (skip unnecessary operations) - Extensible design for future agent types - Improved code maintainability and readability
Redesigned bot edit page to provide specialized UI for Dify mode, hiding irrelevant configuration options. Key changes: Frontend - DifyBotConfig Component: - Created dedicated DifyBotConfig component for Dify-specific settings - Provides user-friendly interface for Dify API credentials (API key, base URL) - Integrated Dify app selector with real-time app fetching - Added informational banner explaining Dify external API mode - Includes configuration preview for transparency Frontend - BotEdit Component: - Added isDifyAgent detection based on selected agent type - Implemented conditional rendering: Dify mode vs standard mode - Dify mode shows only: Bot name, Agent selection, Dify configuration - Standard mode shows: Bot name, Agent selection, Model config, MCP config, System prompt - Updated save logic to skip system_prompt and MCP config for Dify bots - Enhanced validation to handle Dify configuration requirements User Experience: - Cleaner, focused UI when editing Dify bots - No confusing options like system prompt or MCP for external API agents - Clear visual distinction between local engines and external API services - Guided workflow with helpful documentation links Benefits: - Reduced cognitive load - only show relevant fields - Prevents configuration errors from invalid field combinations - Aligns UI with architectural distinction between agent types - Improved usability for Dify integration
- Remove unused DifyBotPromptData interface - Remove unused difyParams and setDifyParams state variables These were leftover from initial development and are not needed in the final implementation.
Fixed the auto-loading issue that caused errors when switching to Dify mode. Changes: - Changed from auto-loading to manual loading with button trigger - Added 'Load Applications' button with loading state - Improved empty state with helpful guidance - Added success toast when apps are loaded - Added better error messages with actionable descriptions - Prevents unnecessary API calls before credentials are entered User experience improvements: - No more automatic error messages on mode switch - Clear guidance on what to do next - Manual control over when to fetch apps - Better feedback on loading and success states Fixes the 'bot.errors.fetch_dify_apps_failed' error that appeared when switching to Dify mode before entering API credentials.
Backend changes:
- Replace non-existent GET /dify/apps endpoint with POST /dify/app/info
- Replace GET /dify/apps/{id}/parameters with POST /dify/app/parameters
- Use official Dify /v1/info and /v1/parameters endpoints
- Accept api_key and base_url in request body for validation
Frontend changes:
- Remove app selector UI (Dify uses per-app API keys, no listing available)
- Implement validation-based workflow with "Validate API Key" button
- Call POST /dify/app/info to validate credentials and fetch app info
- Display app details (name, mode, description) after successful validation
- Simplify agent_config to only store DIFY_API_KEY and DIFY_BASE_URL
- Reset validation state when credentials change
This aligns with Dify's actual API architecture where each application
has its own API key rather than workspace-level listing capability.
- Add English translations for Dify API key, base URL, validation messages - Add Chinese translations for all Dify-related UI text - Include error messages for validation failures - Add hints and descriptions for better UX
- Change from team_members to bot key (matches actual task_data structure) - Add default base_url (https://api.dify.ai) when not specified - Remove DIFY_APP_ID validation requirement (each API key corresponds to one app) - Add detailed comments explaining data structure expectations This fixes the 'DIFY_API_KEY is not configured' error during task execution.
- Add _get_app_mode() to detect app type via /v1/info endpoint - Implement separate API call methods for different modes: * _call_chat_api() for chat/chatflow/agent-chat modes * _call_workflow_api() for workflow mode - Route requests to correct endpoint based on app_mode - Chat modes use /v1/chat-messages with conversation_id support - Workflow mode uses /v1/workflows/run with inputs parameter - Add auto_generate_name for better conversation UX - Only maintain conversation_id for chat-based modes - Format workflow outputs as JSON for display This allows DifyAgent to work with all Dify application types seamlessly.
Added support for configurable Dify application parameters and automatic mode detection: Frontend Changes: - Added collapsible Accordion parameter form in DifyBotConfig - Auto-save DIFY_APP_MODE when validating API key - Support multiple parameter types (text, select, paragraph) - Extract and restore parameters from agent_config - Added i18n translations for parameter form UI Backend Changes: - Extract DIFY_PARAMS from agent_config in DifyAgent - Merge parameters from agent_config with bot_prompt params - Config params take priority over bot_prompt params This allows users to configure workflow/chatflow apps that require input parameters, and enables frontend to show different UIs based on the saved application mode.
Changed parameter fetching strategy to retrieve the latest parameter definitions from Dify API on each validation, instead of relying on cached data. Changes: - Call both /dify/app/info and /dify/app/parameters in parallel - Merge responses to get complete app information - Add fallback handling for parameters endpoint - Ensures parameter form reflects current Dify app configuration This addresses the issue that Dify app parameters may change on the Dify platform, and the UI should always show the latest definitions.
Implemented a generic, architecture-compliant solution for task-level parameter configuration for external API bots (like Dify), without exposing implementation details to the frontend.
Key principles:
- Frontend only communicates through team_id, no direct external API calls
- Backend handles all external API interactions
- Generic "external_api" type instead of specific implementations
- Parameters embedded in message content to avoid backend schema changes
Backend changes:
- Added GET /teams/{team_id}/input-parameters endpoint to fetch parameters
- team_kinds_service.get_team_input_parameters() checks for external_api bots
- Automatically fetches parameter schema from external API (server-side)
- DifyAgent extracts parameters from [EXTERNAL_API_PARAMS] markers
- Parameter priority: prompt params > agent config > bot prompt
Frontend changes:
- Created generic ExternalApiParamsInput component (no vendor-specific naming)
- Fetches parameters through teamApis.getTeamInputParameters(teamId)
- Integrated into ChatArea for new task creation
- Parameters embedded in message using [EXTERNAL_API_PARAMS]{json}[/EXTERNAL_API_PARAMS]
- Backend extracts and removes markers before sending to external API
This design:
- Keeps frontend vendor-agnostic
- All external API logic stays in backend
- Works with any external API type (Dify, future integrations)
- Maintains clean separation between local engines (Agno, Claude Code) and external APIs
Implemented automatic encryption/decryption for sensitive API keys to enhance security for external API integrations. Security Improvements: - Added generic encryption/decryption functions to shared/utils/crypto.py - encrypt_sensitive_data(): Encrypts any sensitive data using AES-256-CBC - decrypt_sensitive_data(): Decrypts encrypted sensitive data - is_data_encrypted(): Checks if data is encrypted Backend Changes: 1. bot_kinds_service.py - Added _encrypt_agent_config() method to encrypt DIFY_API_KEY before saving - Encrypts on both create_with_user() and update_with_user() operations - Prevents double-encryption with encryption detection 2. team_kinds_service.py - Added _decrypt_agent_config() method to decrypt DIFY_API_KEY when reading - Decrypts in get_team_input_parameters() before calling external API - Only decrypts if data appears to be encrypted 3. executor/agents/dify/dify_agent.py - Decrypts DIFY_API_KEY in _extract_dify_config() before using - Ensures encrypted keys from database are properly decrypted at runtime Implementation Details: - Reuses existing AES-256-CBC encryption infrastructure from git token encryption - Uses GIT_TOKEN_AES_KEY and GIT_TOKEN_AES_IV environment variables - Automatic encryption detection prevents double-encryption - Backward compatible: handles both encrypted and plain text (for migration) Security Benefits: - API keys no longer stored in plain text in database - Sensitive credentials encrypted at rest - Automatic decryption at runtime for seamless operation - Extensible design for encrypting other sensitive fields in the future Testing: - Verified encryption/decryption round-trip correctness - Confirmed double-encryption prevention - Tested backward compatibility with plain text
…perience When Dify Agent is selected in Bot edit page, the configuration area now spans the full width on desktop screens to eliminate large empty spaces. Form elements within the Dify configuration are constrained to a maximum width of 800px to maintain optimal readability and usability on large displays. The responsive layout behavior for mobile devices remains unchanged, ensuring vertical stacking continues to work correctly.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Changes
isDifyAgentflagw-full)lg:w-2/5 xl:w-1/3)DifyBotConfigcomponent in amax-w-[800px]container to limit form element widthImpact
Test Plan