feat: add batch payment to existing requests #67
Conversation
… and update related logic in invoice form
…just invoice schema accordingly
…ts with currency selection and validation
…ransaction handling and approval logic
…alidation limits, and summary statistics
…-easyinvoice---one-time-batch-payments-from-payout-page
…oardView components
WalkthroughThis update introduces a new Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant DashboardView
participant Wallet
participant Backend
participant handleBatchPayment
User->>DashboardView: Select invoices, click "Batch Pay"
DashboardView->>Wallet: Check connection / Prompt connect if needed
alt Connected
DashboardView->>Backend: Request batch payment data (requestIds)
Backend-->>DashboardView: Return batch payment data (approvals, tx)
DashboardView->>handleBatchPayment: Execute batch payment (signer, data, callbacks)
handleBatchPayment->>Wallet: Send approval tx(s) if needed
handleBatchPayment->>Wallet: Send batch payment tx
handleBatchPayment-->>DashboardView: Callbacks for status/success/error
DashboardView-->>User: Show toast, update UI
else Not connected
DashboardView-->>User: Prompt wallet connection
end
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (6)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (3)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (1)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
…prevent selection of paid invoices in InvoiceRow
…-easyinvoice---one-time-batch-payments-from-the-invoice-dashboard-not-recurring
…ardView components - Introduced a new `handleBatchPayment` function to encapsulate batch payment logic, improving code reusability and readability. - Updated `BatchPayout` and `DashboardView` components to utilize the new function, enhancing error handling and user feedback through toast notifications. - Removed redundant code and improved state management during payment processing.
…invoice currencies - Updated the invoice form and schema to use `INVOICE_CURRENCIES` instead of `EXTENDED_INVOICE_CURRENCIES`, ensuring consistency across the application. - Adjusted type definitions for invoice currency to reflect the change, improving type safety and clarity.
…m-the-invoice-dashboard-not-recurring
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
src/components/batch-payout.tsx (1)
197-197: Consider migrating to ethers v6 for consistency.Similar to the dashboard view, this component uses ethers v5 API.
🧹 Nitpick comments (3)
src/components/dashboard-view.tsx (1)
48-50: Consider migrating to ethers v6 for better compatibility and features.The code uses
ethers.providers.Web3Providerwhich is the ethers v5 API. Consider updating to ethers v6 for improved performance and modern features.For ethers v6, the pattern would be:
-const ethersProvider = new ethers.providers.Web3Provider( - walletProvider as ethers.providers.ExternalProvider, -); +const ethersProvider = new ethers.BrowserProvider(walletProvider);src/components/invoice-table.tsx (1)
294-319: Robust selection logic with good validation.The
handleSelectInvoicefunction implements solid business rules:
- Prevents mixing invoices from different networks
- Blocks selection of paid invoices
- Properly manages selection state
The network extraction logic
invoice.paymentCurrency.split("-")[1]appears to rely on a specific format. Consider adding validation to ensure the split operation is safe.Consider adding validation for the network extraction:
- const invoiceNetwork = invoice.paymentCurrency.split("-")[1]; + const parts = invoice.paymentCurrency.split("-"); + if (parts.length < 2) { + toast.error("Invalid payment currency format"); + return false; + } + const invoiceNetwork = parts[1];src/lib/invoice/batch-payment.ts (1)
122-154: Consider simplifying the error message extraction logic.The nested error message extraction logic is quite complex and could be prone to runtime errors if the error object structure is unexpected.
Consider creating a helper function to safely extract error messages:
+const extractErrorMessage = (error: any): string => { + const defaultMessage = "There was an error processing your batch payment. Please try again."; + + if (!error || typeof error !== "object") return defaultMessage; + + // Try common error message paths + const paths = [ + error.data?.message, + error.message, + error.response?.data?.message, + error.error?.message + ]; + + for (const path of paths) { + if (typeof path === "string" && path.trim()) { + return path; + } + } + + return defaultMessage; +}; - let errorMessage = - "There was an error processing your batch payment. Please try again."; - - if (error && typeof error === "object") { - if ( - "data" in error && - error.data && - typeof error.data === "object" && - "message" in error.data - ) { - errorMessage = error.data.message || errorMessage; - } else if ("message" in error) { - errorMessage = error.message || errorMessage; - } else if ("response" in error && error.response?.data?.message) { - errorMessage = error.response.data.message; - } else if ( - "error" in error && - typeof error.error === "object" && - error.error && - "message" in error.error - ) { - errorMessage = error.error.message; - } - } + const errorMessage = extractErrorMessage(error);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/app/dashboard/page.tsx(2 hunks)src/components/batch-payout.tsx(2 hunks)src/components/dashboard-view.tsx(1 hunks)src/components/invoice-table.tsx(9 hunks)src/lib/invoice/batch-payment.ts(1 hunks)src/server/routers/payment.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
src/server/routers/payment.ts (1)
src/lib/schemas/payment.ts (1)
batchPaymentFormSchema(19-24)
src/components/batch-payout.tsx (1)
src/lib/invoice/batch-payment.ts (1)
handleBatchPayment(14-155)
src/components/invoice-table.tsx (3)
src/server/db/schema.ts (1)
Request(273-273)src/components/ui/table.tsx (3)
TableRow(114-114)TableCell(115-115)TableHead(113-113)src/components/ui/checkbox.tsx (1)
Checkbox(30-30)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Build
🔇 Additional comments (14)
src/app/dashboard/page.tsx (1)
1-37: LGTM! Clean refactoring to use the new DashboardView component.The refactor successfully delegates the dashboard UI rendering and batch payment logic to the new
DashboardViewcomponent, improving separation of concerns and maintainability.src/components/dashboard-view.tsx (1)
39-86: The batch payment implementation looks solid.The error handling is comprehensive, with proper UI state management and user feedback through toast notifications. The integration with the
handleBatchPaymentutility effectively centralizes the payment logic.src/components/batch-payout.tsx (1)
205-232: Excellent refactoring to use the centralized handleBatchPayment utility.The delegation to
handleBatchPaymentsignificantly simplifies the component by removing complex transaction handling logic while maintaining all the necessary functionality. The error handling and UI state management through callbacks is well implemented.src/components/invoice-table.tsx (6)
5-5: LGTM!The Checkbox import is correctly added for the new selection functionality.
50-53: Well-structured props for selection state management.The new props properly encapsulate the selection state and network tracking functionality needed for batch payments.
78-84: Component signature correctly updated.The function signature properly accepts all the new selection-related props with appropriate typing.
323-328: Checkbox integration looks good.The checkbox is properly integrated with the selection logic and state management.
411-411: Table header updated appropriately.The "Select" column header is correctly added with proper styling and width constraint.
185-188: Props properly passed to child components.The selection-related props are correctly passed down to InvoiceRow components in both tabs.
Also applies to: 230-233
src/lib/invoice/batch-payment.ts (5)
29-58: Well-structured approval transaction processing.The sequential processing of approval transactions with proper error handling is implemented correctly. The user rejection handling (code 4001) is specifically handled with appropriate feedback.
59-81: Batch payment transaction logic is sound.The main transaction processing follows the same pattern as approvals with proper user rejection handling and success callbacks.
85-97: Comprehensive insufficient funds detection.The error handling covers multiple ways insufficient funds errors can manifest across different providers and network conditions.
99-111: Good network error detection.The network error handling covers various network-related error patterns effectively.
113-120: Smart contract error handling is appropriate.Using the
error.reasonfield for smart contract errors provides useful debugging information to users.
- Integrated `useAppKitNetwork` to manage network switching during batch payments. - Added logic to switch networks based on the last selected network, improving user experience with toast notifications for network changes. - Updated constants in `chains.ts` to support new network mappings.
…ce-dashboard-not-recurring' of github.com:RequestNetwork/easy-invoice into 28-easyinvoice---one-time-batch-payments-from-the-invoice-dashboard-not-recurring
- Updated `BatchPaymentData` interface to use `providers.TransactionRequest` for improved type safety. - Added validation to the `batchPay` input schema to ensure either `payouts` or `requestIds` is provided, enhancing input integrity.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/lib/invoice/batch-payment.ts(1 hunks)src/server/routers/payment.ts(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/lib/invoice/batch-payment.ts
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/server/routers/payment.ts (1)
src/lib/schemas/payment.ts (1)
batchPaymentFormSchema(19-24)
🔇 Additional comments (2)
src/server/routers/payment.ts (2)
41-49: Good implementation of flexible input validation.The schema change successfully addresses the past review comment by allowing both
payoutsandrequestIdsas optional fields while ensuring at least one is provided through the refinement validation.
62-70: Correct conditional handling of payouts and requestIds.The mutation logic properly handles both input scenarios:
- When
payoutsis provided, it maps the data to the expected API format- When only
requestIdsis provided, therequestsfield is set toundefined- The
requestIdsfield is always included, allowing the backend to handle the appropriate case
MantisClone
left a comment
MantisClone
left a comment
There was a problem hiding this comment.
Approved 👍 pending comment resolution 🚧
…ndling - Updated `duplicatePayment` function to remove unnecessary payee reset. - Enhanced `getUniquePayeesCount` to handle payee addresses in a case-insensitive manner. - Modified `getTotalsByCurrency` to return human-readable totals instead of BigNumber, improving display clarity. - Simplified signer retrieval in `BatchPayout`, `DirectPayment`, and `PaymentSection` components for consistency.
- Added validation to check for a selected network before proceeding with batch payments. - Implemented error handling to notify users when no network is selected, improving user experience. - Updated network switching logic to ensure proper state management during payment processing.
- Removed toast notifications for various error states during batch payment processing to simplify user feedback. - Enhanced the error handling logic to focus on status changes without displaying redundant messages, improving code clarity and maintainability.
aimensahnoun
deleted the
28-easyinvoice---one-time-batch-payments-from-the-invoice-dashboard-not-recurring
branch
Batch Payment System Enhancement & Dashboard Refactor
Resolves #28
Changes Overview
Key Features
Technical Details
handleBatchPaymentutility for centralized payment processingDashboardViewcomponent with batch payment capabilitiesTesting Notes
Please test the following scenarios:
Screenshots
Invoice selection
Cross-network error
Paid invoice error
Summary by CodeRabbit
New Features
Refactor
Bug Fixes