-
-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support watching assets on a specific account #1124
Conversation
asset, | ||
id: this._generateRandomId(), | ||
status: SuggestedAssetStatus.pending as SuggestedAssetStatus.pending, | ||
time: Date.now(), | ||
type, | ||
}; | ||
if (interactingAddress) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO - Provide selectedAddress as fallback to ensure that suggestedAssetMeta always has an interactingAddress
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions.
|
cb2d3d9
to
eb5cab8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
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
* Add interactingAddress property to SuggestedAssetMetaBase type * Allow passing an account address to watchAsset * Pass interacting account address into addToken from acceptWatchAsset * Support adding token to an account that is not the active wallet account * Rename detection fields to interacting to support more cases * Create test for watching an asset under a specific account address * Create test for storing a watched asset under a specific account address * Use selectedAddress as fallback for interacting address * Fix TokensController tests
* Add interactingAddress property to SuggestedAssetMetaBase type * Allow passing an account address to watchAsset * Pass interacting account address into addToken from acceptWatchAsset * Support adding token to an account that is not the active wallet account * Rename detection fields to interacting to support more cases * Create test for watching an asset under a specific account address * Create test for storing a watched asset under a specific account address * Use selectedAddress as fallback for interacting address * Fix TokensController tests
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 thewatchAsset
andaddToken
method, that would allow for storing of tokens under specific account addresses. All of the listed changes below is backwards compatible and code that uses theTokensController
will not need to change.Description
CHANGED:
TokensController.watchAsset
interactingAddress: string
parameter with the definition ofThe address of the account that is requesting to watch the asset.
TokensController.acceptWatchAsset
interactingAddress: string || selectedAddress: string
) intoTokensController.addToken
under theERC20
switch condition.TokensController.addToken
interactingAddress
is defined and is not equal toselectedAddress
, this method will function the same way but will not updatetokens
,ignoredTokens
,detectedTokens
token states.interactingAddress
is not defined, this method will use theselectedAddress
and function the same way.SuggestedAssetMeta
typeinteractingAddress?: string
property. This is only populated ifinteractingAddress
is passed intoTokensController.watchAsset
.Checklist
Issue
Resolves #???