-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
cool - we should probably add a |
@gavofyork So the DeadManSwitch contract is working fine when backup/owner are Wallets Contracts (I just tested every methods), from the Contracts view. However, the DeadManSwitch contract cannot be used as a Wallet for now. I think we might want to open the Wallet options to other contracts than the standard one. However it would take some work to get there, as we need to make the events and methods that we use more general. |
@@ -90,7 +90,7 @@ export default handleActions({ | |||
signerSuccessRejectRequest (state, action) { | |||
const { id } = action.payload; | |||
const rejected = Object.assign( | |||
state.pending.find(p => p.id === id), | |||
state.pending.find(p => p.id === id) || { id }, |
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.
Same as the previous fix (now for reject), I missed this case the first time around. (Let's hope it is indeed dead now)
hasContracts: Object.keys(contracts).length !== 0, | ||
wallets, | ||
hasWallets: Object.keys(wallets).length !== 0 | ||
hasContracts: Object.keys(contracts).length !== 0 |
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.
While we are here, could we just fix the ordering as well?
* a Wallet. The result is cached in order not | ||
* to make unnecessary calls on non wallet accounts | ||
*/ | ||
_isWallet (address) { |
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.
Not 100% sure this is the correct place for this functionality. Can we walk through today and discuss?
@@ -60,6 +60,7 @@ class TransactionPendingFormConfirm extends Component { | |||
<Form> | |||
{ keyInput } | |||
<Input | |||
autoFocus |
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.
Where does it focus when there are multiple requests? Still on the first?
wallet: PropTypes.object.isRequired, | ||
isTest: PropTypes.bool.isRequired | ||
walletAccount: nullableProptype(PropTypes.object.isRequired) |
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.
Possibly nullableProptype(PropTypes.object).isRequired
(the full property is required, but could be either null or object)
|
||
resolve: { | ||
alias: { | ||
'~': path.resolve(__dirname, '../src') |
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.
+1
? (hint || '') | ||
: this.context.intl.formatMessage( | ||
hint.props, | ||
hint.props.values || [] |
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.
hint.props.values || {}
It's totally valid for input's length not to be a multiple of 32 bytes. EG. for Wallet Contracts
There were the following issues with your Pull Request
Guidelines are available at https://github.com/ethcore/parity This message was auto-generated by https://gitcop.com |
@ngotchac Yeah - we'll need an extensible architecture so that code hashes (i.e. types of wallet contracts) can be registered with specialised means of signing. This way dapps can use various addresses with |
Changes Unknown when pulling f087475 on ng-wallet-improv into ** on master**. |
Changes Unknown when pulling f087475 on ng-wallet-improv into ** on master**. |
This PR fixes some issues (balances not updating, not being able to send tokens from a Wallet), and should close #3784
This adds a new lookup action to the
Contract
class, which checks for a transaction whether thefrom
field corresponds to a Wallet or not. If it does, then try to post the transaction/estimate gas with the correct options, ie.from
being one of the owner of the wallet that is also one of the user account, etc.Note that this can be recursive : if a Wallet is owned by another Wallet owner by one of my account, it will correctly set the account as the transaction sender, to the middle Wallet, that will call the execute method on the initial Wallet, which will execute the correct transaction.
The gas estimation is sometimes (more or less 2/3) wrong. So to test one might want to multiply the gas by 2. Maybe this should be taken into account in the PR (while the gas estimation gets fixed) ?
As the modification lies in the Contract class, this also work within dApps ! The only thing not available for Wallets is contract deployment (that would require a modification of the Wallet contract itself)...
Might fix #3849