search

blockchainprojects / bitshares-ui

Graphical User Interface for BitShares Blockchain
https://wallet.bitshares.org
MIT License
0 stars 1 forks source link

Proposal - Incorrect information about fee #2881 #138

Closed sschiessl-bcp closed 5 years ago

sschiessl-bcp commented 5 years ago

https://github.com/bitshares/bitshares-ui/issues/2881

Please check if that is still happening with your new component

Metizik commented 5 years ago

Same issue is actual for HTLC creation: image I thought it is an issue in TransactionConfirm component, but it seems like not, since actual Fee paid was equal to one, stated in TransactionConfirm modal

Metizik commented 5 years ago

@sschiessl-bcp , same seems true for new component, even worse - it seems like new component state is not reflected now in actual transaction created. When I choose CNY asset to pay fee, in transaction confirm I still see TEST as asset for fee payment.

One more question - should I be able to specify arbitrary fee asset for propose operation? if so - there is another issue here since in propose dialog on https://develop.bitshares.org/#/account/twat123 when I change fee asset - default one is used for fee displaying in TransactionConfirm dialog: https://gyazo.com/5f83191bb11fdecd6604d267409aef96

Metizik commented 5 years ago

@sschiessl-bcp , after some initial research I believe that cause of this problem lies in checkFeeStatusAsync function of trxHelper. This function is used in lots of places and is not designed to handle propose operation. All the components, which do use it for fee calculation do not handle this situation in any proper way - so they just use it with specific operation type. If we take a look onto, for example, transfer method of ApplicationApi it checks if propose_account is set and in this case creates proposal_create operation. I think implementing the same handling in checkFeeStatusAsync will resolve the problem, but I am not sure how to verify suggested concept, can you give me a hint on this?