You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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=[newEveryoneCheck(command.allowEveryone),newAllowedUsersCheck(command.allowedUsers)]}elseif(isGuildMessage){permissionsChain=[newEveryoneCheck(command.allowEveryone),newAllowedRolesCheck(command.allowedRoles),newAllowedUsersCheck(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.
The text was updated successfully, but these errors were encountered:
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 useallowedRoles
") 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:
But for now, it does actually work, so this is a low-priority item that I'm just noting for later.
The text was updated successfully, but these errors were encountered: