Exchange virtual iban - #1797
Conversation
- Introduced Virtual IBAN functionality for private EUR deposits and withdrawals. - Updated locator and repository to include Virtual IBAN components. - Added UI elements and localization for Confidential SEPA. - Implemented handling for special recipient types related to Virtual IBAN. - Enhanced funding methods to support Confidential SEPA transactions.
- Consolidated parameter definitions in the Bullbitcoin API datasource for improved readability. - Removed unnecessary line breaks in various files to enhance code clarity. - Ensured consistent formatting across multiple components related to Virtual IBAN functionality.
…ams and improve response handling; adjust FundExchangeEuropeMethods layout for KYC verification
…I updates; streamline FundExchangeEuropeMethods layout and remove unnecessary comments
…recipient management with address handling and UI improvements; update localization for new features
…line recipient type handling and enhance location eligibility checks
…g; enhance UI styling and fix activation flow - Update withdrawal order creation to safely parse nested error responses and extract API error messages - Fix FR_PAYEE recipient creation to use nested params structure and parse element from response - Improve Virtual IBAN activation flow by triggering creation on pending state initialization - Allow create requests from both notSubmitted and pending states for better retry handling - Update
…rove recipient type selection and navigation logic - Replace unsupported Virtual IBAN error handling with SEPA transfer designation in pay and send payment screens - Adjust recipient type selection logic to enhance user experience and streamline flow - Refine step-based navigation checks for recipients location - Improve state management in withdraw flow to accommodate user navigation
…g in payment screens - Refactor recipient type selection logic to enhance clarity and maintainability - Improve formatting and alignment of UI elements in pay_receive_payment_screen and pay_send_payment_screen - Update error handling for unsupported Virtual IBAN types to ensure consistent user experience
|
@kumulynja this feature required comprehensive updates to recipients . please check if it's structured correctly |
|
|
||
| /// Entity representing a user's physical address. | ||
| @freezed | ||
| sealed class UserAddress with _$UserAddress { |
There was a problem hiding this comment.
This is not an entity since it has no identity, no business rules or whatever makes something an entity. It also has protocol level things like from/to json which should only be present in models in the adapters, not in the domain. The same for address stringified it is also not something to put in an entity or in the domain in general if it is not used in the domain. It feels more like a presentation concern and as far as I can see the UI is indeed the only place where it is used, so shouldn't be here but there.
There was a problem hiding this comment.
To clarify, the UserAddress concept and so class can be in the domain of course, but get it out of the entity folder and remove the json and stringied stuff. This is more of a Value Object, since it is used as a field in the virtual iban recipient entity. It is not an entity itself.
| _apiKeyDatasource = apiKeyDatasource, | ||
| _isTestnet = isTestnet; | ||
|
|
||
| Future<String> _getApiKey() async { |
There was a problem hiding this comment.
Check the frameworks/http folder in recipients feature and reuse that way of managing the api key.
(Best would be to move that http folder to core actually to reuse it for all exchange features instead of repeating in every feature)
| /// - Only show recipients with isOwner=true | ||
| /// - Group by IBAN | ||
| /// - If both cjPayee and frPayee exist for the same IBAN, keep only frPayee | ||
| class FilterRecipientsByVirtualIbanUsecase { |
There was a problem hiding this comment.
This should not be a usecase. This acts on View Models and doesn't use any ports/adapters, this should just be done in the Presentation layer (bloc state probably), not in a usecase.
| @@ -0,0 +1,12 @@ | |||
| /// Defines the current step in the recipient selection flow. | |||
| /// Used for multi-step flows like sell/withdraw where VIBAN activation may be required. | |||
| enum RecipientFlowStep { | |||
There was a problem hiding this comment.
This is not a domain thing. This is for navigation. This should not be here.
| ); | ||
|
|
||
| // For step-based flows (sell, withdraw, pay), handle step-based navigation | ||
| if (location.usesStepBasedFlow) { |
There was a problem hiding this comment.
I feel like this step based flow like this needs another thought to see if there are no better ways like nested navigation. This feels hacky and error-prone and it now mixes three different ways of some sort of navigation, go router, tabs and now steps in the tabs. This is just a first impression, I should look at it some more, but first though is there should be a better way.
There was a problem hiding this comment.
Did you think of or try using StatefulShellRoute navigation to be able to have steps in tabs?
| on<RecipientsCadBillersSearched>(_onCadBillersSearched); | ||
| on<RecipientsSelected>(_onSelected); | ||
| // Virtual IBAN step flow navigation handlers | ||
| on<RecipientsNextStepPressed>(_onNextStepPressed); |
There was a problem hiding this comment.
This confirms my first impression that the step based stuff is not good. This mixes navigation into the BLoC, no bueno. The BLoC is the controller to invoke and pass data to and from the usecases, not for navigation logic.
| class VirtualIbanRouter { | ||
| /// Creates a shell route that provides the singleton VirtualIbanBloc. | ||
| /// No location parameter needed - the bloc is a singleton that's already loaded. | ||
| static ShellRoute createRoute() { |
There was a problem hiding this comment.
We stopped using ShellRoute since it affects default/native back navigation. Better to just pass the BLoC as extra in the navigation routes to use the same instance for different routes and don't lose the default back navigation when entering a flow/feature's first route.
…across exchange features - Introduced BullbitcoinApiKeyProvider to streamline API key retrieval and management. - Updated VirtualIbanRepository to utilize the new provider instead of the deprecated BullbitcoinApiKeyDatasource. - Refactored ExchangeLocator and RecipientsLocator to register and reuse the API key provider. - Changed imports from user_address entity to value_objects for consistency and clarity. - Removed unused recipient-related classes and methods to clean up the codebase.
|
@kumulynja the following changes were made
Pending discussionDeferred (Comments 5-7) - Navigation Architecture |
47d3ede to
7e26795
Compare
2 participants
This branch introduces a new "Confidential SEPA" (Virtual IBAN) feature that enables private EUR deposits and withdrawals through a personal virtual IBAN. The feature is integrated across funding, withdrawal, and recipient management flows.
1. New Feature: Confidential SEPA / Virtual IBAN
Intro/Activation Screen (
VirtualIbanIntroScreen)Pending/Activation Screen (
VirtualIbanPendingScreen)Activated/Success Screen (
VirtualIbanActiveScreen)IBAN Details Screen (
VirtualIbanDetailsScreen)2. Fund Exchange Methods Updates
Europe Funding Methods (
FundExchangeEuropeMethods)3. Recipient Management Updates
New Step-Based Flow
The recipient selection flow now uses a step-based navigation for sell/withdraw:
Step 1: Type Selection (
RecipientTypeSelectionStep)Step 2 (if frPayee selected without VIBAN): Virtual IBAN Activation (
VirtualIbanActivationStep)Step 3: Enter Details (standard recipient form)
Recipients Screen Updates (
RecipientsScreen)New Recipient Tab Updates (
NewRecipientTab)Recipient Type Selector Updates (
RecipientTypeSelector)frVirtualAccount)frPayeewhen VIBAN is not activecjPayee: "Regular SEPA"Recipients List Tile Updates
frVirtualAccount,frPayee,cjPayee4. Withdrawal Flow Updates
Amount Screen (
WithdrawAmountScreen)Confirmation Screen Updates
frVirtualAccount,frPayee,cjPayee)5. Payment Screen Updates (
PaySendPaymentScreen)frPayee: "Confidential SEPA"cjPayee: "Regular SEPA"frVirtualAccount: "Virtual IBAN"6. Localization Additions
New strings added for multiple languages (EN as primary):
confidentialSepaTitleconfidentialSepaDescriptionconfidentialSepaBullet1-3confidentialSepaWarningTitleconfidentialSepaWarningDescaccountOwnerNameconfirmLegalNameactivateConfidentialSepaactivatingConfidentialSepaTitle/DescuseRegularSepaInsteadconfidentialSepaActivatedTitleconfidentialSepaActivated*DescshowVirtualIbanDetailsprivacyBankingTitlevirtualIbanNameWarningvirtualIbanAccountNumberrecipientName/AddressbankAccountCountry/bankAddress/bicCodenewBadgeuseVirtualIbanuseVirtualIbanSubtitleregularSepaconfidentialSepaShortDescVisual Design Patterns Used