feat(wallets): show wallet and recurring rule connections in an External apps tab - #4314
Open
domenicofalco wants to merge 5 commits into
Open
domenicofalco wants to merge 5 commits into
domenicofalco wants to merge 5 commits into
Conversation
…nal apps tab ## Context ING-519 and ING-520 gave the wallet form the connection-first payment drawer and the additional integration settings drawer, but nothing in the read views showed what a wallet or one of its recurring rules actually routes to. ING-683 now exposes `connections` on both objects — behaviour plus resolved code — which is what lets the UI tell an explicit choice from one inherited from the customer. This ships the read half, behind the `multi_connection` feature flag, and absorbs ING-528: the shared connection read components are built here together with their first consumer, so ING-523 (subscription) and ING-526 (invoice) can reuse them unchanged. ## Description - Select `connections { category behavior code }` on the `WalletDetails` fragment, for the wallet and for each of its recurring transaction rules. - Add shared, category-agnostic read components under `src/components/connectionSelection/read/`: the connection code chip with its provider avatar, the routing value with its four states (specific, inherited, skipped, nothing resolved), the payment method value, the labeled grid rows, and the two-section composite every view composes. - Add an "External apps" tab to the wallet details page, between "Recurring rule" and "Transactions": "Payment app and settings" (payment connection + payment method) and "Additional app settings" (tax, accounting, CRM). - Render the same two sections per recurring rule, inside the rule's own block. - Move the payment method row off the wallet Overview when the flag is on, so it is not duplicated; the invoice custom sections row stays there. - Wire each section's Edit to the wallet form with a router-state intent flag that auto-opens the matching drawer, mirroring the existing recurring-rule bridge. Everything above is gated: with `multi_connection` off, all three views render exactly as before. Notes for review: - The rows read "(Customer default)" from a new key, as the design draws. The shipped "inherit from customer" key is untouched, so the subscription view still reads the old wording until product settles it. - The design also draws a "(Wallet default)" variant on a rule. `ConnectionRouting.behavior` only says `inherit`, never whether the value came from the wallet or the customer, so only one wording can be rendered today. - The provider URL / invoice sync row of ING-528 is not built here: its only consumer is the invoice tab (ING-526), which is blocked on ING-667. - `Run Codegen` stays red until lago-api#6401 merges — CI builds the schema from lago-api main, which does not expose these fields yet. <!-- Linear link --> Fixes ING-527
added 4 commits
September 16, 2026 14:39
Explicit return types on the new components, the row and grid-item types exported from useConnectionRoutingGridItems instead of re-declared, and WalletExternalApps deriving the edit-link ids from the wallet rather than taking the route params twice.
Every Edit on the wallet detail is now the same inline link labelled "Edit", where the overview and recurring-rule tabs still had a quaternary button labelled "Edit wallet". The connection sections also get the 48px rhythm the other detail sections have: a bottom padding on the closing section, and the same gap between a rule's own block and its two connection sections.
…ection A payment method belongs to one connection, but the read views passed the customer-wide list to useResolvedPaymentMethodDisplay, which falls back to the first default method: a wallet or rule routed to connection B could therefore show the default card of connection A. The list is now filtered by the resolved connection, the same way ConnectionPaymentSettingsDrawerContent filters it, and a skipped connection no longer claims the method is a customer default. The per-rule Edit links are also limited to the first rule: the wallet form only opens and saves recurringTransactionRules[0], so an Edit on a later rule edited the wrong one.
…se the category list The read components sat in a read/ subfolder, the only nesting in connectionSelection and an axis no other component folder uses; they now sit beside the write-side ones, where their names already say what they are. The three integration categories were also declared a fourth time here — the additional-settings list is reused instead, which also aligns the read rows with the order the settings drawer already shows.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
ING-519 and ING-520 gave the wallet form the connection-first payment drawer and the
additional integration settings drawer, but nothing in the read views showed what a wallet
or one of its recurring rules actually routes to. ING-683 now exposes
connectionson bothobjects — behaviour plus resolved code — which is what lets the UI tell an explicit choice
from one inherited from the customer.
This ships the read half, behind the
multi_connectionfeature flag, and absorbs ING-528:the shared connection read components are built here together with their first consumer,
so ING-523 (subscription) and ING-526 (invoice) can reuse them unchanged.
Description
connections { category behavior code }on theWalletDetailsfragment, for thewallet and for each of its recurring transaction rules.
src/components/connectionSelection/read/: the connection code chip with its provideravatar, the routing value with its four states (specific, inherited, skipped, nothing
resolved), the payment method value, the labeled grid rows, and the two-section composite
every view composes.
"Transactions": "Payment app and settings" (payment connection + payment method) and
"Additional app settings" (tax, accounting, CRM).
duplicated; the invoice custom sections row stays there.
the matching drawer, mirroring the existing recurring-rule bridge.
Everything above is gated: with
multi_connectionoff, all three views render exactly as before.Notes for review:
"inherit from customer" key is untouched, so the subscription view still reads the old
wording until product settles it.
ConnectionRouting.behavioronly says
inherit, never whether the value came from the wallet or the customer, so onlyone wording can be rendered today.
invoice tab (ING-526), which is blocked on ING-667.
Run Codegenstays red until lago-api#6401 merges — CI builds the schema from lago-apimain, which does not expose these fields yet.
Fixes ING-527