Skip to content

**BREAKING** Add PermissionTree class & introduce children to Permission specifications #1513

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

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
Open
6 changes: 6 additions & 0 deletions packages/permission-controller/src/Permission.ts
Original file line number Diff line number Diff line change
Expand Up @@ -423,6 +423,12 @@ type PermissionSpecificationBase<Type extends PermissionType> = {
* Leaving this as undefined uses default behaviour where the permission is available to request for all subject types.
*/
subjectTypes?: readonly SubjectType[];

/**
* An array of associated permission names that fall under this "parent" permission. Target names would be limited to the
* array of child permissions associated with this particular permission.
*/
children?: Readonly<TargetName[]>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we enforce that only a special type of permission can have children?

I am thinking it might be useful to define a PermissionGroup similarly to how we have endowments and RPC methods currently and only allow permissions of type "permission group" to actually function as a group.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-doing this PR based on a convo w/ @rekmarks to keep a concept of groups as well, minus the need for an extraneous permission in state.

};

/**
Expand Down
Loading