New Components - ifthenpay #16393
New Components - ifthenpay #16393
Conversation
luancazarine
added
the
ai-assisted
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
|
""" WalkthroughThis update introduces a new integration for Ifthenpay, including actions to generate payment references and issue refunds, as well as a polling source to emit events when payments are completed. It adds supporting constants, updates the app definition with new authentication and API methods, and includes a sample event for testing. Several other app files receive minor formatting changes with the addition of trailing newline characters. The package manifest is updated to include a dependency on "@pipedream/platform" and a new version number. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Action_CreatePaymentReference
participant IfthenpayApp
participant IfthenpayAPI
User->>Action_CreatePaymentReference: Provide payment details
Action_CreatePaymentReference->>IfthenpayApp: generatePaymentReference(data)
IfthenpayApp->>IfthenpayAPI: POST /init or /mbway (based on method)
IfthenpayAPI-->>IfthenpayApp: Payment reference response
IfthenpayApp-->>Action_CreatePaymentReference: Return result
Action_CreatePaymentReference-->>User: Export summary
sequenceDiagram
participant User
participant Action_IssueRefund
participant IfthenpayApp
participant IfthenpayAPI
User->>Action_IssueRefund: Provide refund details
Action_IssueRefund->>IfthenpayApp: refundPayment(data)
IfthenpayApp->>IfthenpayAPI: POST /refund
IfthenpayAPI-->>IfthenpayApp: Refund response
IfthenpayApp-->>Action_IssueRefund: Return result
Action_IssueRefund-->>User: Export summary
sequenceDiagram
participant Source_NewPayment
participant IfthenpayApp
participant IfthenpayAPI
participant User
Source_NewPayment->>IfthenpayApp: listPayments(since lastDate)
IfthenpayApp->>IfthenpayAPI: POST /read
IfthenpayAPI-->>IfthenpayApp: List of new payments
IfthenpayApp-->>Source_NewPayment: Return payment data
Source_NewPayment-->>User: Emit event(s) for new payments
Assessment against linked issues
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
components/ifthenpay/actions/create-payment-reference/create-payment-reference.mjsOops! Something went wrong! :( ESLint: 8.57.1 Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'jsonc-eslint-parser' imported from /eslint.config.mjs 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (3)
✨ Finishing Touches
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. 🪧 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 Payment Actions - Create Payment Reference - Issue Refund
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (6)
components/ifthenpay/sources/new-payment/test-event.mjs (1)
1-13: Test event structure looks good but missing trailing newline.The test event object provides a comprehensive sample with appropriate data types and values for testing payment events. The date format in
paymentDatefollows the European format (DD-MM-YYYY).Add a trailing newline at the end of the file to follow best practices:
"terminal": "5-0000000000-CAIXA GERAL DE " } +components/ifthenpay/actions/issue-refund/issue-refund.mjs (2)
3-22: Component definition looks good, but consider improving the amount prop.The action component follows Pipedream's component pattern with appropriate metadata and property definitions.
Consider enhancing the
amountproperty with validation to ensure it's a valid currency value:amount: { type: "string", label: "Amount", description: "The amount to be refunded.", + pattern: "^\\d+(\\.\\d{1,2})?$", + examples: ["10.50", "100"], },
36-37: Add trailing newline at the end of the file.Following best practices, add a trailing newline at the end of the file.
}; +components/ifthenpay/ifthenpay.app.mjs (1)
11-31: Consider adding error handling for the async options method.While the implementation works well, it's missing error handling for potential API failures.
async options({ prevContext }) { + try { const { payments } = await this.listPayments({ data: { dateStart: prevContext.token, }, }); + if (!payments || !Array.isArray(payments)) { + return { + options: [], + context: { token: null }, + }; + } + return { options: payments.map(({ requestId: value, orderId: label, }) => ({ label, value, })), context: { token: payments.length ? payments[0].paymentDate : null, }, }; + } catch (error) { + console.error('Error fetching payment requests:', error); + return { + options: [], + context: prevContext, + }; + } },components/ifthenpay/actions/create-payment-reference/create-payment-reference.mjs (2)
77-81: Fix incorrect description for the email property.The email property has an incorrect description that doesn't match its purpose.
email: { type: "string", label: "Email", - description: "The Client's name.", + description: "The client's email address, with a maximum length of 200 characters", optional: true, },
127-148: Remove duplicate client email in API request.The data object includes both
clientEmailwith the same value, which is redundant.data: { mbKey: this.mbKey, mbWayKey: this.mbWayKey, orderId: this.orderId, amount: parseFloat(this.amount), mobileNumber: this.mobileNumber, email: this.email, description: this.description, url: this.url, clientCode: this.clientCode, clientName: this.clientName, clientUsername: this.clientUsername, clientPhone: this.clientPhone, expiryDays: this.expiryDays, expirationDate: this.expirationDate, - clientEmail: this.email, },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (12)
components/bika_ai/bika_ai.app.mjs(1 hunks)components/ifthenpay/actions/create-payment-reference/create-payment-reference.mjs(1 hunks)components/ifthenpay/actions/issue-refund/issue-refund.mjs(1 hunks)components/ifthenpay/common/constants.mjs(1 hunks)components/ifthenpay/ifthenpay.app.mjs(1 hunks)components/ifthenpay/package.json(2 hunks)components/ifthenpay/sources/new-payment/new-payment.mjs(1 hunks)components/ifthenpay/sources/new-payment/test-event.mjs(1 hunks)components/inferable/inferable.app.mjs(1 hunks)components/instasent/instasent.app.mjs(1 hunks)components/peerdom/peerdom.app.mjs(1 hunks)components/urltopdf/urltopdf.app.mjs(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Verify TypeScript components
- GitHub Check: pnpm publish
- GitHub Check: Publish TypeScript components
🔇 Additional comments (22)
components/inferable/inferable.app.mjs (1)
11-11: Consistent EOF newline
A single newline was added at the end of the file for formatting consistency. No functional modifications were made.components/instasent/instasent.app.mjs (1)
11-11: Consistent EOF newline
A single newline was added at the end of the file for formatting consistency. No functional modifications were made.components/bika_ai/bika_ai.app.mjs (1)
11-11: Consistent EOF newline
A single newline was added at the end of the file for formatting consistency. No functional modifications were made.components/peerdom/peerdom.app.mjs (1)
11-11: Consistent EOF newline
A single newline was added at the end of the file for formatting consistency. No functional modifications were made.components/urltopdf/urltopdf.app.mjs (1)
11-11: Consistent EOF newline
A single newline was added at the end of the file for formatting consistency. No functional modifications were made.components/ifthenpay/common/constants.mjs (1)
1-4: LGTM: Clean constant definition for payment methods.The constant
PAYMENT_METHOD_OPTIONSis well-defined and will serve as a centralized reference for supported payment methods across the Ifthenpay integration.components/ifthenpay/package.json (2)
3-3: Version bump follows semantic versioning.The version upgrade from 0.0.1 to 0.1.0 appropriately reflects the addition of new features without breaking changes.
14-16: LGTM: Required dependency added properly.Adding the dependency on
@pipedream/platformis appropriate for the expanded Ifthenpay integration functionality.components/ifthenpay/actions/issue-refund/issue-refund.mjs (1)
1-2: LGTM: Proper import and spacing.The import statement for the Ifthenpay app is correctly defined with appropriate spacing.
components/ifthenpay/ifthenpay.app.mjs (4)
1-2: Appropriate import from Pipedream platform.Good choice importing axios from the Pipedream platform package instead of using it directly. This helps maintain consistency with platform standards.
6-45: Well-structured prop definitions with proper descriptions and appropriate security measures.The prop definitions are well-organized with clear labels and descriptions. Good practice marking the API keys as
secret: truefor security purposes.For the
requestIdprop, the async options implementation provides a good user experience by fetching and formatting payment data dynamically.
47-67: Well-structured HTTP request helper methods.Good job implementing helper methods for API interactions:
_baseUrl()for the consistent API URL_data()for handling authentication keys_makeRequest()as a reusable request wrapper with consistent headersThese utility methods follow best practices for organizing API integration code.
85-98: Clean implementation of payment service methods.The
refundPaymentandlistPaymentsmethods are implemented cleanly, following the same pattern and reusing the_makeRequestutility method.components/ifthenpay/actions/create-payment-reference/create-payment-reference.mjs (4)
1-9: Good module composition with appropriate metadata.The action module is well-organized with proper imports and clear metadata. The description provides helpful context and includes a link to documentation.
10-18: Well-structured props with proper reloadProps implementation.Good job implementing
reloadProps: truefor the payment method selection, allowing dynamic UI updates based on the selected option.
104-126: Well-implemented dynamic props handling.The
additionalPropsmethod effectively manages visibility and default values based on the selected payment method. Good practice updating labels and descriptions dynamically.One minor suggestion:
async additionalProps(props) { const isMb = this.paymentMethod === "Multibanco"; props.mbKey.default = isMb ? this.ifthenpay.$auth.mb_key : null; props.mbKey.hidden = !isMb; props.mbWayKey.default = !isMb ? this.ifthenpay.$auth.mbway_key : null; props.mbWayKey.hidden = isMb; props.mobileNumber.hidden = isMb; props.url.hidden = isMb; props.clientCode.hidden = isMb; props.clientName.hidden = isMb; props.email.label = "Client Email"; props.email.description = "Client's email address, with a maximum length of 200 characters"; props.clientUsername.hidden = isMb; props.clientPhone.hidden = isMb; props.expiryDays.hidden = isMb; - return {}; + return props; // Return props to maintain consistency with standard additionalProps pattern },
149-152: Good job providing a clear success message.The export summary provides clear feedback on the action's result, which improves user experience.
components/ifthenpay/sources/new-payment/new-payment.mjs (5)
1-12: Well-structured source component with proper imports and metadata.Good job using the standard pattern for Pipedream source components, including the proper default polling interval and deduplication strategy.
12-21: Standard and clean props implementation for source components.The props follow Pipedream's best practices for source components with proper timer and database integration.
22-28: Clean implementation of database helpers.The database helper methods are concise and follow best practices for persisting state in Pipedream sources.
54-62: Good implementation of source lifecycle hooks.The deploy hook correctly limits the initial emission to 25 items to prevent overwhelming the workflow. The run method keeps the implementation simple and focused.
45-51:❓ Verification inconclusive
Verify the order of emitted events.
The code reverses the payment array before emission, which might impact the chronological order of events.
Currently, you're using
response.reverse()which reverses the array in place. Verify that this is the intended behavior:
- If the API returns payments in descending order (newest first), then reversing makes sense to emit oldest payments first
- If the API returns payments in ascending order (oldest first), then reversing would emit newest payments first
🏁 Script executed:
#!/bin/bash # Check if there are comments or documentation about the order of payments rg -i "order|sort|chronological" --type js components/ifthenpayLength of output: 65
Verify the ordering of emitted events
I couldn’t find any in-code documentation on whether the IfThenPay API returns payments in ascending (oldest-first) or descending (newest-first) order. Please confirm the API’s default sort order in its official docs or by inspecting a sample response:
- If the API returns newest-first, keep the
.reverse()so you emit oldest-first.- If the API returns oldest-first, remove the
.reverse()so you emit newest-first.
components/ifthenpay/actions/create-payment-reference/create-payment-reference.mjs
Show resolved
Hide resolved
|
/approve |
Resolves #16383.
Summary by CodeRabbit