-
Notifications
You must be signed in to change notification settings - Fork 11
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
chore: 🤖 review permissions #1413
base: alpha
Are you sure you want to change the base?
Conversation
Quality Gate failedFailed conditions See analysis details on SonarQube Cloud Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE |
@@ -55,6 +55,7 @@ export async function prepareRemoveSecondaryAccounts( | |||
export const removeSecondaryAccounts = (): Procedure<RemoveSecondaryAccountsParams> => | |||
new Procedure(prepareRemoveSecondaryAccounts, { | |||
permissions: { | |||
// TODO: might not need this -> chain checks if called by primary key, checks if secondary key exists and can be unlinked, then unlinks |
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.
chain checks if called by primary key,
I don't get this. Technically we don't need to check any permissions since the chain always checks them, but we do this to avoid having the chain catch obvious errors.
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 here -> so as I understood from the chain logic -> there are no specific extra checks for the Tx method -> if it is ok with those two conditions then the extrinsic will run
@@ -81,6 +81,7 @@ export async function getAuthorization( | |||
|
|||
return { | |||
permissions: { | |||
// TODO: on chain just checks if is signed by primary key -> so we should check in prepareAddSecondaryKeysWithAuth if signer is the target primary key |
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.
I think there is a few methods like this. Would we need to add an extra field to permissions for that?
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.
I mean we don't need to check for the TxTags -> as the chain does not do it anyways
@@ -80,6 +80,7 @@ export async function getAuthorization( | |||
|
|||
return { | |||
permissions: { | |||
// TODO: might not need these as prepareUnlinkChildIdentity checks if signer is primary key of either the child or parent which the same as done on chain | |||
transactions: [TxTags.identity.UnlinkChildIdentity], |
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.
All the TxTags are given in the case where as secondary key is performing the given action, and if that key has the permission for that tx or not. Maybe in a few cases it may not be needed but my guess most of them will be required
Description
on chain there are multiple ways how we check permissions, the main ones are
Additional checks are done via specific methods in the extrinsic - e.g. if the signer is multiSig admin, if it is multiSig
JIRA Link
https://polymesh.atlassian.net/browse/DA-1411