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

Refactor permission checker for clarity #14

Open
oqkr opened this issue Mar 10, 2019 · 0 comments
Open

Refactor permission checker for clarity #14

oqkr opened this issue Mar 10, 2019 · 0 comments

Comments

@oqkr
Copy link
Owner

oqkr commented Mar 10, 2019

The current permission system works, but it's a little hard for me to reason about without leaving detailed comments to myself (see isAllowed function).

This probably needs to be refactored for clarity/simplicity or reworked.

It's not so much that the system is complex as that parts of it don't behave in a straightforward manner — like the fact that an empty allowedUsers field means "allow everyone" in a direct-message context yet means exactly the opposite ("ignore this and use allowedRoles") in a guild-channel context.

It's been suggested that a better route may be to treat permission checks more like a chain and at each part of the chain make a decision to allow, deny, or defer to the next link in the chain using something like this pseudocode:

/** pseudocode */
if (isDM) {
  permissionsChain = [
    new EveryoneCheck(command.allowEveryone),
    new AllowedUsersCheck(command.allowedUsers) ]
} else if (isGuildMessage) {
  permissionsChain = [
    new EveryoneCheck(command.allowEveryone),
    new AllowedRolesCheck(command.allowedRoles),
    new AllowedUsersCheck(command.allowedUsers) ]
}
if (permissionsChain.allow()) {
  // do stuff
}

But for now, it does actually work, so this is a low-priority item that I'm just noting for later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant