New Components - openphone #14505
New Components - openphone #14505
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
luancazarine
added
the
ai-assisted
WalkthroughThis pull request introduces several new functionalities to the OpenPhone component, including actions for creating, updating contacts, and sending messages, as well as event sources for completed call recordings and calls. A utility function for parsing input objects is also added. The changes enhance the OpenPhone API integration by providing structured methods for managing contacts and handling call events. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Sources - New Call Recording Completed (Instant) - New Outgoing Call Completed (Instant) - New Incoming Call Completed (Instant) Actions - Send Message - Create Contact - Update Contact
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🧹 Outside diff range and nitpick comments (15)
components/openphone/common/utils.mjs (3)
1-2: Add JSDoc documentation for better maintainability.As this is a utility function used across multiple components, adding JSDoc documentation would improve maintainability and help other developers understand its purpose and usage.
+/** + * Parses and transforms input objects for OpenPhone API requests. + * @param {any} obj - The input object to parse + * @returns {undefined|string|Array|Object} The parsed object, or undefined for falsy inputs + */ export const parseObject = (obj) => {
13-15: Add protection against circular references.The recursive nature of the function could cause stack overflow errors with circular references. Consider adding a WeakMap to track processed objects.
+const seen = new WeakMap(); export const parseObject = (obj) => { if (!obj) return undefined; + if (typeof obj === 'object' && seen.has(obj)) { + return seen.get(obj); + } + if (typeof obj === 'object') { + seen.set(obj, obj); + } // ... rest of the function };
16-23: Simplify destructuring syntax.The current formatting of Object.entries destructuring spans multiple lines unnecessarily. Consider a more concise format.
if (typeof parsedObj === "object") { - for (const [ - key, - value, - ] of Object.entries(parsedObj)) { + for (const [key, value] of Object.entries(parsedObj)) { parsedObj[key] = parseObject(value); } }components/openphone/sources/new-call-recording-completed-instant/new-call-recording-completed-instant.mjs (1)
4-11: Enhance the component descriptionWhile the current description is functional, it could be more informative by specifying:
- What triggers the event (webhook from OpenPhone)
- What data is included in the event
- description: "Emit new event when a call recording has finished.", + description: "Emit new event when an OpenPhone call recording has finished. The event includes the call ID and recording details.",components/openphone/sources/new-incoming-call-completed-instant/new-incoming-call-completed-instant.mjs (3)
1-2: Consider separating test-related imports.The test event import should ideally be moved to a separate test file rather than being included in the main component file. This helps maintain a clear separation between production and test code.
Consider creating a separate test file (e.g.,
new-incoming-call-completed-instant.test.mjs) and moving the test event import there.
4-11: Add webhook configuration documentation.The component lacks documentation about the required webhook configuration. Users need to know how to set up the webhook in their OpenPhone account to receive these events.
Add JSDoc comments or documentation explaining:
- Required webhook URL configuration in OpenPhone
- Any necessary authentication or security settings
- Expected webhook payload format
4-27: Add error handling for webhook events.While the basic implementation is good, the component should include proper error handling for various scenarios:
- Invalid webhook payloads
- Network timeouts
- Rate limiting
- API errors
Consider implementing:
- Retry logic for failed webhook processing
- Error logging for debugging
- Rate limiting protection
- Proper error messages for users
Would you like me to provide a detailed implementation for these error handling mechanisms?
components/openphone/sources/new-outgoing-call-completed-instant/test-event.mjs (1)
18-22: Consider adding content-type validation for voicemail URLs.The voicemail object includes audio file information. Consider adding validation to ensure:
- The URL uses HTTPS
- The content-type matches the specified type
- The duration is a positive number
components/openphone/actions/send-message/send-message.mjs (2)
29-41: Consider exposingsetInboxStatusas a configurable prop.The
setInboxStatusis currently hardcoded to "done". Consider making this configurable by exposing it as a prop with "done" as the default value.props: { // ... existing props ... + setInboxStatus: { + type: "string", + label: "Inbox Status", + description: "Set the inbox status for the message.", + options: ["done", "todo"], + default: "done", + optional: true, + }, },Then update the run method:
data: { content: this.content, from: this.from, to: [ this.to, ], - setInboxStatus: "done", + setInboxStatus: this.setInboxStatus, },
42-42: Enhance the success message with more details.The current success message could provide more context about the sent message.
- $.export("$summary", `Successfully sent message to ${this.to}`); + $.export("$summary", `Successfully sent message from ${this.from} to ${this.to} (${this.content.length} characters)`);components/openphone/actions/create-contact/create-contact.mjs (1)
61-79: Consider enhancing error handling and input validation.While the implementation is functional, consider these improvements:
- Add specific error handling for common API errors
- Add input validation for email format and phone numbers
- Document the expected response structure in comments
Here's a suggested enhancement:
async run({ $ }) { + // Validate email format if provided + if (this.emails) { + const emails = parseObject(this.emails); + emails.forEach(email => { + if (!email.match(/^[^\s@]+@[^\s@]+\.[^\s@]+$/)) { + throw new Error(`Invalid email format: ${email}`); + } + }); + } + + try { const response = await this.openphone.createContact({ $, data: { defaultFields: { firstName: this.firstName, lastName: this.lastName, company: this.company, role: this.role, emails: parseObject(this.emails), phoneNumbers: parseObject(this.phoneNumbers), }, customFields: parseObject(this.customFields), }, }); $.export("$summary", `Successfully created contact with ID: ${response.data.id}`); return response; + } catch (error) { + if (error.response?.status === 409) { + throw new Error('Contact already exists'); + } + throw error; + } },components/openphone/actions/update-contact/update-contact.mjs (1)
1-87: Consider implementing response type definitions.To improve maintainability and type safety, consider:
- Adding TypeScript or JSDoc type definitions for the API response
- Creating a shared interface for contact-related operations
- Documenting the expected shape of custom fields
This will help maintain consistency across the OpenPhone integration and improve developer experience.
components/openphone/openphone.app.mjs (3)
57-57: Fix string escaping in the 'customFields' exampleThe example provided in the
customFieldsdescription has improperly escaped quotes, which could cause confusion or errors. Correct the string escaping to accurately represent the JSON structure.Apply this diff to fix the example:
description: "Array of objects of custom fields for the contact. **Example:** `{\"key\": \"inbound-lead\", \"value\": [\"option1\", \"option2\"]}`.",
12-19: Handle pagination when listing phone numbersWhen calling
listPhoneNumbers()in thefromproperty options, ensure that all available phone numbers are fetched, especially if there's pagination in the API response. The current implementation may only retrieve the first page of results.Consider modifying
listPhoneNumbers()to handle pagination, or specify parameters to fetch all records if supported by the API.
70-77: Add error handling in the_makeRequestmethodThe
_makeRequestmethod does not currently handle errors that may occur during the API call. Implementing error handling will improve robustness and provide clearer feedback in case of failures.Consider wrapping the axios call in a
try...catchblock and appropriately handling or logging errors.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (13)
components/openphone/actions/create-contact/create-contact.mjs(1 hunks)components/openphone/actions/send-message/send-message.mjs(1 hunks)components/openphone/actions/update-contact/update-contact.mjs(1 hunks)components/openphone/common/utils.mjs(1 hunks)components/openphone/openphone.app.mjs(1 hunks)components/openphone/package.json(2 hunks)components/openphone/sources/common/base.mjs(1 hunks)components/openphone/sources/new-call-recording-completed-instant/new-call-recording-completed-instant.mjs(1 hunks)components/openphone/sources/new-call-recording-completed-instant/test-event.mjs(1 hunks)components/openphone/sources/new-incoming-call-completed-instant/new-incoming-call-completed-instant.mjs(1 hunks)components/openphone/sources/new-incoming-call-completed-instant/test-event.mjs(1 hunks)components/openphone/sources/new-outgoing-call-completed-instant/new-outgoing-call-completed-instant.mjs(1 hunks)components/openphone/sources/new-outgoing-call-completed-instant/test-event.mjs(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- components/openphone/sources/new-call-recording-completed-instant/test-event.mjs
- components/openphone/sources/new-incoming-call-completed-instant/test-event.mjs
🔇 Additional comments (22)
components/openphone/package.json (2)
3-3: LGTM! Version bump follows semantic versioning.
The version increment from 0.0.1 to 0.1.0 appropriately reflects the addition of new features (webhook sources, polling sources, and actions) as a minor version change.
15-17: Verify @pipedream/platform version compatibility.
The addition of @pipedream/platform dependency is correct for implementing the new OpenPhone components. The caret version constraint (^3.0.3) appropriately allows minor updates while preventing breaking changes.
✅ Verification successful
Based on the search results, I can provide the final response since I have comprehensive information about @pipedream/platform versions across the codebase.
@pipedream/platform version ^3.0.3 is compatible with existing components
The version ^3.0.3 specified in openphone/package.json is consistent with many recently updated components in the codebase. Several components are already using version ^3.0.3 or similar 3.x versions (e.g., wati ^3.0.3, xata ^3.0.2, trello ^3.0.1), indicating this is a stable and recommended version.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify @pipedream/platform version usage across other components
# This helps ensure version consistency across the codebase
# Search for @pipedream/platform version specifications in other components
rg '"@pipedream/platform":\s*"\^?[0-9]+\.[0-9]+\.[0-9]+"' components/*/package.json
Length of output: 167829
components/openphone/common/utils.mjs (1)
1-26: Verify handling of OpenPhone API data types.
Please ensure this utility function correctly handles all data types required by the OpenPhone API endpoints, particularly for the contact and message actions.
✅ Verification successful
Based on the results from our verification scripts, I can now provide a final response:
The parseObject utility correctly handles OpenPhone API data types
The function is appropriately used in create-contact and update-contact actions for parsing:
- Contact emails
- Phone numbers
- Custom fields
The recursive parsing approach ensures proper handling of nested objects and arrays, which matches the OpenPhone API requirements for contact operations. No conflicting JSON parsing implementations were found in the OpenPhone components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for OpenPhone API type definitions and usage patterns
rg -t js -t mjs "openphone.*api" --context 3
# Look for other JSON parsing implementations in OpenPhone components
rg -t js -t mjs "JSON\.parse" --context 3 components/openphone/
Length of output: 168
Script:
#!/bin/bash
# Search for OpenPhone API patterns with correct file type
rg "openphone.*api" --type-add 'js:*.{js,mjs,jsx}' -t js
# Look for JSON parsing in OpenPhone components
rg "JSON\.parse" --type-add 'js:*.{js,mjs,jsx}' -t js components/openphone/
# Find all OpenPhone component files to understand usage context
fd -e mjs -e js -e jsx . components/openphone/
# Search for imports of parseObject to understand usage
rg "parseObject" --type-add 'js:*.{js,mjs,jsx}' -t js components/openphone/
Length of output: 3044
Script:
#!/bin/bash
# Check the structure of contact-related data in the components
rg -A 10 "prop.*emails|prop.*phoneNumbers|prop.*customFields" --type-add 'js:*.{js,mjs,jsx}' -t js components/openphone/
# Look for any type definitions or schemas
rg "type.*=|interface|schema" --type-add 'js:*.{js,mjs,jsx}' -t js components/openphone/actions/
Length of output: 221
components/openphone/sources/new-call-recording-completed-instant/new-call-recording-completed-instant.mjs (2)
1-2: LGTM! Good use of common base module
The imports are well-structured and promote code reuse through the common base module.
22-22: Verify test event structure
Ensure the test event matches the expected webhook payload structure from OpenPhone's API.
components/openphone/sources/new-outgoing-call-completed-instant/new-outgoing-call-completed-instant.mjs (3)
1-2: LGTM! Imports are properly structured.
The imports correctly reference the common base functionality and test events.
26-26: LGTM! Sample event is properly exported.
The sample event export is correctly implemented for testing and documentation purposes.
4-11:
Verify the source type implementation.
There appears to be a discrepancy between the PR objectives and the implementation:
- PR objectives list this as a polling source
- Implementation shows it's an instant (webhook) source
- This affects how the component processes events
Please confirm if this should be a polling source or an instant webhook source.
If this should be a polling source:
- key: "openphone-new-outgoing-call-completed-instant",
- name: "New Outgoing Call Completed (Instant)",
+ key: "openphone-new-outgoing-call-completed",
+ name: "New Outgoing Call Completed",components/openphone/sources/new-incoming-call-completed-instant/new-incoming-call-completed-instant.mjs (1)
26-26: Verify sample event structure.
Ensure that the sample event structure in test-event.mjs accurately reflects the OpenPhone API webhook payload format.
✅ Verification successful
Sample event structure appears valid and consistent
The sample event structure in test-event.mjs appears to be valid based on several indicators:
- It follows a standard webhook event structure with
apiVersion,id,object, andtypefields - The call object contains expected fields for a completed call:
direction,status,from,to,completedAt - The implementation validates the event type (
call.completed) and direction (incoming) before emitting - The event structure is used consistently across the webhook handling in the common base implementation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if test event matches OpenPhone API documentation
# Test: Look for OpenPhone API documentation or similar test events
rg -g '*.md' -g '*.json' -i 'openphone.*webhook.*payload|openphone.*event.*format'
Length of output: 84
Script:
#!/bin/bash
# Let's check the test event file content directly
cat components/openphone/sources/new-incoming-call-completed-instant/test-event.mjs
# Also search for any OpenPhone related files that might contain event structure
fd -e json -e js -e mjs openphone
Length of output: 887
Script:
#!/bin/bash
# Let's check the OpenPhone app file for any event structure definitions or validations
cat components/openphone/openphone.app.mjs
# Also let's check if there are any schema validations in the source file
cat components/openphone/sources/new-incoming-call-completed-instant/new-incoming-call-completed-instant.mjs
Length of output: 3913
Script:
#!/bin/bash
# Let's check the common base file for any webhook event validation
cat components/openphone/sources/common/base.mjs
# Also check if there are any other OpenPhone webhook sources that might validate the structure
fd webhook components/openphone/sources
Length of output: 1503
components/openphone/sources/new-outgoing-call-completed-instant/test-event.mjs (2)
11-12: Verify phone number format requirements.
The phone numbers are in E.164 format (+1XXXXXXXXXX). Let's verify if OpenPhone's API requires this format for all phone numbers.
Also applies to: 16-17
✅ Verification successful
Based on the search results, I can generate a final response since I found clear evidence about phone number format requirements in the OpenPhone API from the codebase:
Phone numbers must be in E.164 format for OpenPhone API
The codebase shows consistent usage of E.164 format (+[country code][number]) for phone numbers across OpenPhone components:
- In
openphone.app.mjs: "The sender's phone number... in E.164 format" - In test events: Phone numbers consistently follow E.164 format (e.g. "+18005550100")
- In actions like
send-message: "Recipient phone number in E.164 format"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for phone number format validation or similar implementations
# Look for phone number validation or formatting
rg -g "*.{js,mjs}" "phone.*number.*format|E\.164|\+1[0-9]{10}"
# Search for OpenPhone-specific phone number handling
ast-grep --pattern 'from: $_' -l | xargs rg "phone.*number"
Length of output: 106062
1-28: The webhook payload structure looks good, but test data could be improved.
The event object correctly represents a completed outgoing call with appropriate fields and structure. However, consider enhancing the test data:
- Use more realistic phone numbers instead of 800/888 numbers
- Add a test case with non-null
answeredAtto cover answered calls - Include a test case with non-empty
mediaarray if applicable
Let's verify this matches OpenPhone's API documentation:
✅ Verification successful
Let's search for OpenPhone-specific webhook documentation and similar event structures to verify the payload format.
Let's compare the webhook payload structures and check the app documentation to verify the format.
Test event structure is consistent and valid
The test event structure is correct and consistent with OpenPhone's webhook implementation. The comparison between incoming and outgoing call completed events shows:
- Both follow the same v3 API structure
- The only key difference is the
directionfield ("incoming" vs "outgoing") - The test phone numbers, while fictional, are in valid E.164 format
- The payload includes all necessary fields for call tracking (timestamps, IDs, status)
While the original review suggested improvements to test data, the current structure is sufficient for testing purposes as it represents a valid webhook payload format.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for OpenPhone API documentation or similar webhook implementations
# to verify the payload structure matches the official spec
# Look for other OpenPhone test events or documentation
fd -e md -e txt -e json -e yaml "openphone|webhook" --exec rg -l -i "api.*v3|webhook|payload"
# Search for similar webhook implementations
rg -g "test-event*" -l "apiVersion.*v3.*object.*event.*type"
Length of output: 106062
Script:
#!/bin/bash
# Search for OpenPhone webhook event files and documentation
fd -e mjs -e md "openphone" --exec rg -l "apiVersion.*v3|webhook|event"
# Search for similar webhook event structures in OpenPhone components
rg -g "components/openphone/**" -A 10 "type.*call\.completed"
Length of output: 555
Script:
#!/bin/bash
# Let's examine the structure of both incoming and outgoing call completed events
cat components/openphone/sources/new-incoming-call-completed-instant/test-event.mjs
cat components/openphone/sources/new-outgoing-call-completed-instant/test-event.mjs
# Check OpenPhone app for webhook/event documentation
rg -g "components/openphone/openphone.app.mjs" -A 5 -B 5 "webhook|event"
Length of output: 2809
components/openphone/actions/send-message/send-message.mjs (2)
1-3: LGTM! Appropriate imports for the functionality.
The imports are well-structured, bringing in the necessary error handling from the platform and the OpenPhone app module.
4-57: Implementation successfully meets PR objectives.
The action implementation satisfies the requirements outlined in the PR objectives for the "send-message" action, including all necessary properties and functionality.
components/openphone/actions/create-contact/create-contact.mjs (4)
4-9: Verify the OpenPhone API documentation link.
The action metadata is well-structured, but please verify that the documentation link is permanent and won't change with API versions.
#!/bin/bash
# Description: Check if this documentation URL is used consistently across OpenPhone components
rg -l "openphone\.com/docs/api-reference" 1-80: Verify consistency with other OpenPhone actions.
The implementation looks solid overall. Let's verify consistency with other OpenPhone actions in the codebase.
#!/bin/bash
# Description: Check for consistency in implementation patterns across OpenPhone actions
# Expected: Should find similar patterns in other action files
# Look for similar action patterns
fd -e mjs -e js . components/openphone/actions -x rg -l "type: \"action\"" {} \;
# Check for consistent error handling patterns
rg "try|catch" components/openphone/actions10-60: Verify prop definitions in the OpenPhone app.
The props structure looks good and aligns with the PR objectives. All required and optional fields are properly defined.
#!/bin/bash
# Description: Verify that all prop definitions exist in the OpenPhone app
# Expected: Should find all prop definitions used in this action
# Search for prop definitions in the app file
rg "firstName|lastName|company|role|emails|phoneNumbers|customFields" "components/openphone/openphone.app.mjs"1-2: Verify the parseObject utility function implementation.
The imports look correct, but let's verify the implementation of the parseObject utility function since it's used for critical data transformation.
✅ Verification successful
The parseObject utility function is correctly implemented and imported
The utility function exists in components/openphone/common/utils.mjs and is properly implemented as a recursive function that handles object parsing. It's also being used consistently across related components (create-contact and update-contact actions).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the parseObject utility implementation
# Expected: Should find the implementation of parseObject in utils.mjs
# Search for the parseObject function definition
ast-grep --pattern 'export const parseObject = $_' || ast-grep --pattern 'export function parseObject($_)'
# Also check the raw implementation as fallback
rg -l "parseObject" "components/openphone/common/utils.mjs"
Length of output: 566
Script:
#!/bin/bash
# Let's try a different approach to verify the parseObject utility
# First, check if the utils.mjs file exists
fd "utils.mjs" components/openphone/common/
# Then look for any parseObject references in the file
rg "parseObject" components/openphone/common/ -A 2 -B 2
# Also check for any usage patterns across the codebase
rg "parseObject" components/openphone/ -l
Length of output: 1149
components/openphone/actions/update-contact/update-contact.mjs (3)
4-9: LGTM! Well-structured component metadata.
The component metadata is well-defined with clear naming, appropriate versioning for a new component, and includes documentation links.
10-66: Verify OpenPhone app propDefinitions.
The props structure looks good, but let's verify the propDefinitions referenced from the OpenPhone app to ensure all field types and validations are properly defined.
#!/bin/bash
# Description: Verify OpenPhone app propDefinitions
# Expected: Find all referenced propDefinitions
echo "Searching for propDefinitions in openphone.app.mjs:"
rg -A 2 'firstName:|lastName:|company:|role:|emails:|phoneNumbers:|customFields:' components/openphone/openphone.app.mjs1-2: Verify the parseObject utility implementation.
The imported parseObject utility is crucial for formatting the contact data. Let's verify its implementation to ensure proper handling of complex objects.
✅ Verification successful
Based on the search results, I found the implementation of parseObject utility in components/openphone/common/utils.mjs and its usage across the codebase. Let me verify its implementation with one more script to ensure it's properly handling the contact data.
The parseObject utility implementation is verified and safe to use
The parseObject utility in components/openphone/common/utils.mjs is well-implemented with proper:
- Null/undefined handling
- String-to-JSON parsing with error recovery
- Recursive handling of nested objects and arrays
- Type preservation for non-string/object values
This implementation is suitable for formatting contact data in the update-contact action, as it safely handles the expected data structures (emails, phone numbers, and custom fields).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the parseObject utility implementation
# Expected: Find the implementation and usage patterns of parseObject
# Search for the implementation
echo "Searching for parseObject implementation:"
ast-grep --pattern 'export const parseObject = $_' || ast-grep --pattern 'export function parseObject($_)'
# Search for other usages to understand the expected behavior
echo -e "\nSearching for parseObject usage patterns:"
rg 'parseObject\(' -A 2
Length of output: 66718
Script:
#!/bin/bash
# Description: Verify the parseObject implementation in OpenPhone utils
# Expected: Find the implementation details of parseObject in OpenPhone's utils
echo "Searching for parseObject implementation in OpenPhone utils:"
rg -A 10 'parseObject' components/openphone/common/utils.mjs
Length of output: 664
components/openphone/sources/common/base.mjs (2)
58-58: Ensure completedAt exists before parsing
In Date.parse(body.data.object.completedAt), make sure that body.data.object.completedAt exists to avoid potential undefined errors.
Consider adding a validation check before parsing:
ts: Date.parse(
+ body.data.object?.completedAt || new Date().toISOString()
),Alternatively, handle cases where completedAt may be undefined to prevent runtime errors.
9-12: Verify propDefinition for resourceIds
The resourceIds prop uses propDefinition referencing openphone and "from". Ensure that "from" is the correct propDefinition for resourceIds, as it may not align with the expected data for resource IDs.
Run the following script to verify the propDefinition:
✅ Verification successful
The from propDefinition is correctly used for resourceIds
The verification shows that the usage is correct. The from propDefinition in openphone.app.mjs returns phone number IDs through its options() method, which aligns perfectly with the resourceIds prop's purpose of identifying phone numbers for webhook configuration. The prop's description explicitly states "The unique identifiers of phone numbers associated with the webhook."
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the 'from' propDefinition in openphone.app.mjs
# Search for the 'from' propDefinition in openphone.app.mjs
rg 'propDefinitions:\s*{\s*from:' components/openphone/openphone.app.mjs
Length of output: 205
Script:
#!/bin/bash
# Let's try a different approach to find the 'from' propDefinition
# First, let's check the app.mjs file content
cat components/openphone/openphone.app.mjs
# Also check the base.mjs file for context
cat components/openphone/sources/common/base.mjs
Length of output: 4575
...nphone/sources/new-call-recording-completed-instant/new-call-recording-completed-instant.mjs
Outdated
Show resolved
Hide resolved
...penphone/sources/new-outgoing-call-completed-instant/new-outgoing-call-completed-instant.mjs
Show resolved
Hide resolved
...penphone/sources/new-incoming-call-completed-instant/new-incoming-call-completed-instant.mjs
Show resolved
Hide resolved
|
/approve |
* openphone init * [Components] openphone #14493 Sources - New Call Recording Completed (Instant) - New Outgoing Call Completed (Instant) - New Incoming Call Completed (Instant) Actions - Send Message - Create Contact - Update Contact * pnpm update * fix source
Resolves #14493.
Summary by CodeRabbit
Release Notes
New Features
Improvements
Version Update