You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.
Describe the bug
When using these extended types (extended_asset and extended_symbol) one must use a string like '100.0000 [email protected]', or '4,[email protected]' when passing as arguments to actions, but the inverse conversion is not made when reading them from tables, as opposed to regular asset and symbol types which are converted back to string format as expected.
To Reproduce
Steps to reproduce the behavior:
Push an action that stores an eosio::extended_xxx in a table
Read from said table the field and receive a JSON object instead of a string (as occurs in asset or symbol)
Expected behavior
It was expected to have similar behaviour as their regular counter parties asset and symbol. If you send a string, it is expected to receive a string in the same format back when reading.
Desktop (please complete the following information):
any
Smartphone (please complete the following information):
any
Additional context
It seems that the conversion implementation on the reading part was missed when adding support to these extended types.
The text was updated successfully, but these errors were encountered:
prcolaco
changed the title
extended_asset and extended_symbol are not returned as a formatted string when read from tables
extended_asset and extended_symbol are not returned as a formatted string when read from tables
Sep 15, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Version of EOSJS
any
Describe the bug
When using these extended types (
extended_asset
andextended_symbol
) one must use a string like'100.0000 [email protected]'
, or'4,[email protected]'
when passing as arguments to actions, but the inverse conversion is not made when reading them from tables, as opposed to regularasset
andsymbol
types which are converted back to string format as expected.To Reproduce
Steps to reproduce the behavior:
eosio::extended_xxx
in a tableJSON object
instead of astring
(as occurs inasset
orsymbol
)Expected behavior
It was expected to have similar behaviour as their regular counter parties asset and symbol. If you send a string, it is expected to receive a string in the same format back when reading.
Desktop (please complete the following information):
any
Smartphone (please complete the following information):
any
Additional context
It seems that the conversion implementation on the reading part was missed when adding support to these extended types.
The text was updated successfully, but these errors were encountered: