feat: highlight owner methods #61
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
chadoh
force-pushed
the
feat/owner-methods
branch
from
4054dbf
to
816c48c
Compare
chadoh
commented
Apr 13, 2022
Comment on lines
+30
to
+32
| export const adminMethods = Object.keys(topLevelSchema.definitions).filter(m => | ||
| allowsAdmin(m as MethodName) | ||
| ) as MethodName[] |
There was a problem hiding this comment.
Plans for a follow-up PR:
- Since we want to make this form general-purpose for any contract, we should stop making assumptions about the permission system of a contract. Rather than have one group of
admins, a contract could have, say, a group oflegislatorsthat can do some things andexecutiveswho can do others. Whatever. So the UI should just filter the list of Change Methods based on the current user's permissions.
The idea of the comments in the Rust is that they will eventually be
generated by a Rust macro that replaces all the `assert_owner` calls.
The macro can look like:
#[only(::owner, willem.near, ::admins, ::get_admin_contract_id::admins)]
Or maybe:
#[only(owner, "willem.near", admins, ::get_admin_contract_id::admins)]
The "owner" view method could be auto-generated from a `derive` on the
struct:
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault, Ownable)]
While `::admins` and `::get_admin_contract_id` would be
explicitly-defined methods on this contract.
The methods specified here would all be expected to return `AccountId |
Vec<AccountId>`
::get_admin_contract_id::admins specifies that any accounts returned by
this method on an external contract should be allowed calling the
specified method. This would be simple to handle on a frontend, but
implies that a cross-contract call with callback is generated by having
such a specification in the macro.
chadoh
force-pushed
the
feat/owner-methods
branch
from
816c48c
to
cd72ac4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The idea of the comments in the Rust is that they will eventually be
generated by a Rust macro that replaces all the
assert_ownercalls.The macro can look like:
Or maybe:
The "owner" view method could be auto-generated from a
deriveon thestruct:
While
::adminsand::get_admin_contract_idwould beexplicitly-defined methods on this contract.
The methods specified here would all be expected to return
AccountId | Vec<AccountId>::get_admin_contract_id::admins specifies that any accounts returned by
this method on an external contract should be allowed calling the
specified method. This would be simple to handle on a frontend, but
implies that a cross-contract call with callback is generated by having
such a specification in the macro.