-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Feat/monday.com #2638
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
base: staging
Are you sure you want to change the base?
Feat/monday.com #2638
Conversation
… fixes, subflow resize clamping
…ribe, auth checks, new db indexes
…dioai#2481) The realtime service network policy was missing the custom egress rules section that allows configuration of additional egress rules via values.yaml. This caused the realtime pods to be unable to connect to external databases (e.g., PostgreSQL on port 5432) when using external database configurations. The app network policy already had this section, but the realtime network policy was missing it, creating an inconsistency and preventing the realtime service from accessing external databases configured via networkPolicy.egress values. This fix adds the same custom egress rules template section to the realtime network policy, matching the app network policy behavior and allowing users to configure database connectivity via values.yaml.
…rovements, additional kb tag types
…ts, LLM providers standardization
|
@Shubhamxshah is attempting to deploy a commit to the Sim Team on Vercel. A member of the Team first needs to authorize it. |
Greptile SummaryAdded comprehensive Monday.com integration with 4 tools (create, update, get, list items), 2 triggers (new item, column changed), and complete selector infrastructure for dynamic field loading. Key Changes:
Architecture:
Confidence Score: 5/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant UI as Block UI
participant API as API Routes
participant MondayAPI as Monday.com API
participant Selector as Selector Registry
participant Tool as Tool Executor
participant Webhook as Webhook Processor
Note over User,Webhook: Tool Operation Flow
User->>UI: Configure Monday block
UI->>API: POST /api/tools/monday/boards
API->>MondayAPI: GraphQL: GET_BOARDS
MondayAPI-->>API: Return boards list
API-->>UI: Return formatted boards
UI->>User: Display board selector
User->>UI: Select board
UI->>Selector: Resolve dependent selectors
Selector->>API: POST /api/tools/monday/groups
API->>MondayAPI: GraphQL: GET_BOARD_GROUPS
MondayAPI-->>API: Return groups
API-->>Selector: Return formatted groups
Selector-->>UI: Update dependent fields
User->>UI: Configure item details
UI->>Tool: Execute operation
Tool->>MondayAPI: GraphQL mutation/query
MondayAPI-->>Tool: Return item data
Tool-->>UI: Return success/error
UI-->>User: Display result
Note over User,Webhook: Trigger Flow
User->>UI: Configure Monday trigger
UI->>User: Display webhook URL
User->>MondayAPI: Configure webhook in Monday
MondayAPI->>Webhook: POST challenge verification
Webhook-->>MondayAPI: Return challenge response
MondayAPI->>Webhook: POST new item event
Webhook->>Webhook: Extract provider identifier
Webhook->>Webhook: Check idempotency
Webhook->>Tool: Execute workflow
Tool-->>Webhook: Workflow completed
Webhook-->>MondayAPI: Return 200 OK
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional Comments (28)
-
apps/sim/app/api/tools/monday/columns/route.ts, line 39 (link)logic:
parseIntcan returnNaNifboardIdis invalid, which could cause GraphQL query issues. Should this validate the parsed integer or handle NaN cases? -
apps/sim/app/api/tools/monday/columns/route.ts, line 55 (link)logic: Exposing internal error messages to clients could leak sensitive information
-
apps/sim/app/api/tools/monday/items/route.ts, line 71 (link)logic: Using
anytype violates project TypeScript rules. Define a proper type interface for Monday.com items or import from types file.Context Used: Context from
dashboard- TypeScript conventions and type safety (source) -
apps/sim/lib/workflows/executor/execution-core.ts, line 158 (link)style: Using
(sb as any).valuebypasses TypeScript type safety. Consider defining proper types for subblock structure.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Context Used: Context from
dashboard- TypeScript conventions and type safety (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/hooks/use-depends-on-gate.ts, line 148-157 (link)syntax: Debug logging should use logger instead of console.log
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/triggers/monday/new_item.ts, line 5 (link)style: Logger created but never used in the file
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/tools/monday/update_item.ts, line 18 (link)logic: API key should use 'user-only' visibility, not 'hidden'. User-provided credentials require 'user-only' per security guidelines.
Context Used: Rule from
dashboard- API keys and other user-provided credentials should use 'user-only' visibility, not 'hidden'. Only f... (source) -
apps/sim/tools/monday/types.ts, line 138-146 (link)style: MondayResponse duplicates ToolResponse pattern - consider using specific response interfaces instead. Is this generic type needed when you already have specific response interfaces for each operation?
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/tools/monday/graphql.ts, line 175-196 (link)style: LIST_ITEMS_NO_FILTER appears identical to LIST_ITEMS. Consider removing duplicate or clarifying the difference. What's the intended difference between LIST_ITEMS and LIST_ITEMS_NO_FILTER?
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/app/api/tools/monday/subitems/route.ts, line 70 (link)style: Using
anytype violates TypeScript rules. Should define proper interface for subitem structureNote: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Context Used: Context from
dashboard- TypeScript conventions and type safety (source) -
apps/sim/tools/monday/list_items.ts, line 18 (link)logic: API key should use 'user-only' visibility, not 'hidden'. Monday.com API keys are user-provided credentials.
Context Used: Rule from
dashboard- API keys and other user-provided credentials should use 'user-only' visibility, not 'hidden'. Only f... (source) -
apps/sim/tools/monday/list_items.ts, line 89 (link)style: Type assertion
anyshould be replaced with proper Monday.com item typeContext Used: Context from
dashboard- TypeScript conventions and type safety (source) -
apps/sim/app/api/tools/monday/status-options/route.ts, line 69 (link)style: The
anytype should be replaced with a proper interface for the label objectNote: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Context Used: Context from
dashboard- TypeScript conventions and type safety (source) -
apps/sim/hooks/selectors/resolution.ts, line 132-139 (link)style: Multiple board ID patterns suggest inconsistent naming conventions across the codebase. Are these different ID variants necessary for backward compatibility or could they be standardized?
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/tools/monday/create_item.ts, line 18 (link)style: Consider using 'user-only' visibility instead of 'hidden' for API keys that users manually provide, per established guidelines
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Context Used: Rule from
dashboard- API keys and other user-provided credentials should use 'user-only' visibility, not 'hidden'. Only f... (source). Is this API key provided manually by users or injected by the OAuth system? -
apps/sim/app/api/tools/monday/boards/route.ts, line 2 (link)style: Import should use the established pattern
@/lib/logs/console/loggerinstead of@sim/loggerto follow the repository's import conventionsNote: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Context Used: Context from
dashboard- Import patterns for the Sim application (source) -
apps/sim/app/api/tools/monday/boards/route.ts, line 18 (link)style: Missing TSDoc documentation for the POST function - should describe the endpoint's purpose, parameters, and return type
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/tools/monday/get_item.ts, line 18 (link)style: API keys should use 'user-only' visibility, not 'hidden'. 'hidden' is reserved for framework-injected tokens like OAuth tokens.
Context Used: Rule from
dashboard- API keys and other user-provided credentials should use 'user-only' visibility, not 'hidden'. Only f... (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/sub-block.tsx, line 404-414 (link)syntax: Using console.log violates the global logging standard. Use logger.info/warn/error instead.
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/sub-block.tsx, line 672-677 (link)syntax: Using console.log violates the global logging standard. Use logger.info/warn/error instead.
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/selector-combobox/selector-combobox.tsx, line 71-79 (link)syntax: Remove console.log statement - should use logger.info/warn/error instead
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/selector-combobox/selector-combobox.tsx, line 48-54 (link)style: Consider memoizing this object to prevent unnecessary re-renders
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/file-selector/file-selector-input.tsx, line 52-65 (link)style: These Monday.com hooks introduce substantial duplication and inconsistent naming patterns. Multiple variants for the same values (snake_case vs camelCase, operation-specific suffixes) suggest the data structure could be normalized.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/file-selector/file-selector-input.tsx, line 75-99 (link)style: The cascading fallback logic for Monday.com values creates a complex precedence chain that could be error-prone. Consider standardizing on a single naming convention to avoid this complexity.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/file-selector/file-selector-input.tsx, line 164-177 (link)style: Monday.com dependency validation logic hardcodes specific selector keys, making it brittle to changes in the selector registry. Consider deriving these requirements from the selector configuration instead.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
-
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/sub-block/components/file-selector/file-selector-input.tsx, line 34 (link)syntax: Remove console.log statement - use logger instead per project standards
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/sub-block/components/file-selector/file-selector-input.tsx, line 150-166 (link)syntax: Remove console.log statements and replace with logger.info for debugging
Context Used: Context from
dashboard- Global coding standards that apply to all files (source) -
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/sub-block/components/file-selector/file-selector-input.tsx, line 226-232 (link)syntax: Remove console.log statement - use logger instead
Context Used: Context from
dashboard- Global coding standards that apply to all files (source)
32 files reviewed, 28 comments
|
@waleedlatif1 @emir-karabeg please review this. |
Summary
This PR adds comprehensive Monday.com integration to the SIM platform, enabling users to create, update, retrieve, and list items on Monday.com boards directly through workflows.
Key Features:
Technical Implementation:
Type of Change
Testing
All Monday.com API endpoints have been tested including:
Focus areas for reviewers:
Checklist
Screenshots/Videos