Skip to content
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

Hide Root extrinsics from the normal Extrinsics UI #1146

Closed
shawntabrizi opened this issue May 12, 2019 · 4 comments
Closed

Hide Root extrinsics from the normal Extrinsics UI #1146

shawntabrizi opened this issue May 12, 2019 · 4 comments

Comments

@shawntabrizi
Copy link
Member

If the Polkadot UI knows that a function requires Root origin to call, then it does not make sense to show such functions to the user in the Extrinsics UI. They should only show up in the Proposals callable function selector.

@jacogr
Copy link
Member

jacogr commented May 12, 2019

It doesn’t. The metadata interface does not expose any of this information.

EDIT: it actually operated this way in poc-1/poc-2 before the calls interface revamp and the introduction of metadata.

@jacogr jacogr closed this as completed May 12, 2019
@xlc
Copy link
Contributor

xlc commented May 12, 2019

Does it make sense to have metadata expose this information?

@jacogr
Copy link
Member

jacogr commented May 13, 2019

It can to a certain extent. Metadata v0 (first version) did have origin - which allowed you to filter out root (it was used that way with the conversion for the poc-2 version where we had private/public). It is however only a part of the puzzle -

  1. It means you won't see these, and (hopefully) know it needs root, i.e. consensus.setCode - https://github.com/paritytech/substrate/blob/master/srml/consensus/src/lib.rs#L317

  2. This means that these will be assumed a public since it has origin, i.e. balances.transfer - https://github.com/paritytech/substrate/blob/master/srml/balances/src/lib.rs#L346

  3. And then you get these, which is not valid for either, but it has an origin that should be set to inherent, i.e. timestamp.set - https://github.com/paritytech/substrate/blob/master/srml/timestamp/src/lib.rs#L223

So the existence/absence of origin is not enough, but it can get to something just based on the params. I certainly would not advocate bringing the origin parameter back into play, since it never gets encoded/decoded which is the intent of the method parameters, i.e. guiding encoding/decoding. Having to ignore this all over middleware is not a good experience. The addition of a flag/enum on the method could help, but between signer/root/inherent, not sure that all the info can actually be extracted reliably. Parts obviously can (root vs the rest) and may be worth it if somebody is bored and reworking metadata generation.

The apps UI is the only place that I certainly deem this enum/flag useful - at the same time won't go to bat for the addition of the information since it is assumed that developers that use extrinsics in this way know what they are doing. (For all the rest there should be simple-to-follow UIs)

@polkadot-js-bot
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

@polkadot-js polkadot-js locked as resolved and limited conversation to collaborators Jun 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants