Support watching assets on a specific account - #1124
Conversation
There was a problem hiding this comment.
TODO - Provide selectedAddress as fallback to ensure that suggestedAssetMeta always has an interactingAddress
|
Hmm, I hadn't realized before that EIP-747 relied upon the current selected account. I guess we'll need to update https://eips.ethereum.org/EIPS/eip-747 to work more effectively with scenarios where multiple accounts are connected. |
we're discussing related topics in context of adding support for adding NFTs via |
Gudahtt
left a comment
There was a problem hiding this comment.
LGTM! Left one suggestion for improved test coverage, and Cal your pending TODO comment looks worth pursing as well, but we don't need to block on that.
c38d0ec to
cb2d3d9
Compare
|
@metamaskbot publish-preview |
cb2d3d9 to
eb5cab8
Compare
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
The `@metamask/assets-controllers` patch added as part of the permission system implementation [1] has been updated to more closely match how the feature was implemented upstream [2]. It should be functionally equivalent. This relates to MetaMask/mobile-planning#877 [1]: #5062 [2]: MetaMask/core#1124
… contract Replace the assumed transactions contract with the one shipping in onramp-api PR #1124 (the neobank-proxy forwards raw MoonPay Enterprise verbatim): - Route: GET /neobank/autoramp-transactions?autoramp_id={id} (flat, not the assumed nested /autoramps/{id}/transactions), returning a MoonPay PagedList; read the `data` array (single page for now, next_cursor pagination is a follow-up). - Payout hash: flat `transaction_hash` (drop the invented payout_transaction_hash and nested payout.transaction_hash). - Status: the real 8 AutorampTransactionStatus values (FundsReviewInProgress, ConversionInProgress, PayoutInProgress, Completed, Failed, RejectedAml, RejectedFraud, RejectedMinAmount). The three Rejected* are terminal and notable; an unknown status falls back to a non-terminal value. This fixes the prior invented enum, which treated rejections as non-terminal and would have polled them forever without ever notifying. - Display fields (amount/currency/moneyAccountAddress) are intentionally left unmapped: MoonPay carries them as structured objects, and the mobile-safe DTO (TRAM-3925) will pin the wire names.
… hash) The prior alignment matched onramp-api #1124's internal mock fixture ({ data, next_cursor } + flat transaction_hash), not the real MoonPay/Iron AutorampTransaction the proxy forwards verbatim. Per Iron's OpenAPI spec the list is a PagedList with an `items` array and the payout hash is nested at `payout_crypto_transaction.transaction_hash`. Reading only `data` / a flat hash would have thrown on every real response (no deposit ever tracked) and never captured the payout hash. Make the mapping tolerant of both, since the proxy PR is unmerged and TRAM-3925 will re-shape it again: - Envelope: read `items` (real Iron), then `data` (proxy fixture), then a bare array. - Payout hash: read nested `payout_crypto_transaction.transaction_hash`, then flat `transaction_hash`. - Tests use the real `{ items, cursor, prev_cursor }` + nested hash as the primary case, with the `data` / flat / bare-array fallbacks covered too.

Support watching assets on a specific account
The purpose of the changes to is allow a user to store a watched asset to the token states in the
TokensController. Why is this needed? The introduction of the Permission System on mobile now allows users to interact with Dapps using accounts that are different than what is active on their wallet screen. This dynamic makes it possible for users to watch assets under the active Dapp account, which may be different than the active wallet account. As a result, we needed to enable passing of an account address to both thewatchAssetandaddTokenmethod, that would allow for storing of tokens under specific account addresses. All of the listed changes below is backwards compatible and code that uses theTokensControllerwill not need to change.Description
CHANGED:
TokensController.watchAssetinteractingAddress: stringparameter with the definition ofThe address of the account that is requesting to watch the asset.TokensController.acceptWatchAssetinteractingAddress: string || selectedAddress: string) intoTokensController.addTokenunder theERC20switch condition.TokensController.addTokeninteractingAddressis defined and is not equal toselectedAddress, this method will function the same way but will not updatetokens,ignoredTokens,detectedTokenstoken states.interactingAddressis not defined, this method will use theselectedAddressand function the same way.SuggestedAssetMetatypeinteractingAddress?: stringproperty. This is only populated ifinteractingAddressis passed intoTokensController.watchAsset.Checklist
Issue
Resolves #???