Conversation
Welcome, @aquinofb!Thanks for your first contribution! Before we proceed with the review, please sign the Contributor License Agreement: Once signed, this PR will be automatically updated. |
Thanks, @aquinofb! 🎉Your CLA has been signed and is now on file. We'll proceed with the review shortly. |
…g resources Expose invoice custom section fields on subscription, wallet, recurring transaction rule, wallet transaction, and one-off invoice to match the backend API contract.
8fa9208 to
261c713
Compare
There was a problem hiding this comment.
@aquinofb not a blocker, but it would be good to update the customer_wallet_test.go to add the tests we have here, since they are shared by the customer_wallet.go endpoints too
There was a problem hiding this comment.
Good call, Osmar. Brought customer_wallet_test.go to full parity with wallet_test.go in f9f9927. The mock fixtures now include payment_method and applied_invoice_custom_sections, the Get test asserts on those fields, and the new CreateWithPaymentMethod and UpdateWithPaymentMethod test cases cover the same scenarios as the wallet endpoint.
Add payment_method and applied_invoice_custom_sections to mock fixtures and assertions. Add CreateWithPaymentMethod and UpdateWithPaymentMethod test cases for the customer wallet endpoint.
Summary
The Lago backend now supports attaching invoice custom sections to additional billing resources beyond customer and billing entity. This PR updates the Go API client to expose those new fields on subscription, wallet, recurring transaction rule, wallet transaction, and one-off invoice.
On the request side, each resource now accepts an optional nested
invoice_custom_sectionobject containinginvoice_custom_section_codes(an array of section code strings) andskip_invoice_custom_sections(a boolean flag). This nesting mirrors the backend's strong params structure, which is notably different from the customer resource, where these fields sit at the top level.On the response side, each resource now deserializes an
applied_invoice_custom_sectionsarray. Each entry containslago_id,invoice_custom_section_id, andcreated_at: the join-table representation returned by the backend'sAppliedInvoiceCustomSectionSerializer, not the fullInvoiceCustomSectionobject.Two new shared types were introduced in
invoice_custom_section.go:InvoiceCustomSectionInputfor requests andAppliedInvoiceCustomSectionfor responses. This keeps the pattern consistent across all five resources without duplicating struct definitions.The implementation was cross-verified against the backend controller strong params, serializer output, and the equivalent Python client PR (getlago/lago-python-client#382) to ensure the JSON field names and nesting structure match exactly.
How to test it locally
Pull the Go Docker image if you don't have Go installed:
Run the tests:
To verify the request JSON shape against a local Lago instance, you can spin up an echo server and point the client at it:
The echo server will print the full request body. Verify that
invoice_custom_section_codesandskip_invoice_custom_sectionsare nested under aninvoice_custom_sectionkey.