Auto suggestion for proxy based on transaction type #11579
Merged
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.
fixes #9201
Problem
Currently, when a user has a proxy account set up (e.g., a 'NonTransfer' proxy), the UI may auto-suggest this proxy for all transactions, even for actions the proxy isn’t allowed to do (e.g., suggesting a 'NonTransfer' proxy for a balance transfer).
Solution
This PR refines the proxy filtering logic in Address.tsx to enable more intelligent auto-suggestion of proxies:
BYPASS_PROXY_CHECK
constant has been removed.bypassProxyTypeCheck
boolean parameter (defaulting to false).bypassProxyTypeCheck
is false (the default),filterProxies
will strictly filter proxies based on their type and the nature of the transaction. This is intended for use by the auto-suggestion logic.bypassProxyTypeCheck
is true, the type-specific filtering is skipped, allowing a list of all structurally valid proxies to be returned (e.g., for a UI element where the user explicitly wants to see all proxies and make their own choice).Testing Summary:
Tested with an account having two proxies:
PROXY1
(NonTransfer type) andPROXY2
(Any type).PROXY2
(Any) was correctly auto-suggested, whilePROXY1
(NonTransfer) was not.filterProxies
logic behaved as expected in both scenarios.