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

Elimination of an hierarchal based permissions system #9

Closed
No767 opened this issue Nov 10, 2023 · 3 comments · Fixed by #50
Closed

Elimination of an hierarchal based permissions system #9

No767 opened this issue Nov 10, 2023 · 3 comments · Fixed by #50
Assignees

Comments

@No767
Copy link
Member

No767 commented Nov 10, 2023

Analyzing ModMail, the purpose of said system is to have access to some "owner-level" commands. Namely:

  • ?alias
  • ?block
  • ?unblock

alias is eliminated as slash commands are employed, and do not allow the creation of aliased slash commands. block and unblock is effectively a role/user blacklist, which permission can be given to the admins directly. And the main commands can be given the relevant permissions or have no permissions to begin with. By eliminating this decrepit system, we gain the benefits of the modern permissions system.

Note that the help command is not needed. The slash commands provide documentation and guidance on how to use said command.

@No767 No767 mentioned this issue Nov 10, 2023
@No767 No767 self-assigned this Jan 5, 2024
@No767 No767 added this to Rodhaj Jan 7, 2024
@No767 No767 moved this to Todo in Rodhaj Jan 7, 2024
@No767
Copy link
Member Author

No767 commented Jan 10, 2024

This needs more research. Modmail purely relies on a hierachal based system, but there are no permissions checks involved. Ideally there is a system of both. Permission checks are primarily used, alongside with hierarchy checks. I'm considering copying the owner system (e.g. users have access to certain commands based on rank), but probably no owner rank as owner checks are possible.

@No767
Copy link
Member Author

No767 commented Jan 16, 2024

Having thought about this for some time, I'm looking to structure it with three different hierarchies:

  1. Permission checks
  2. Role Hierarchy checks (https://gist.github.com/apple502j/d1330461e7e8ad6532cb62a670d06a5a#role-hierarchy-matters)
  3. Rodhaj-based internal hierarchy checks (similar to modmail)

These three will be used to check whether an command can be ran or not. Perms and role hierarchy checks will also be applied to the bot itself

@No767
Copy link
Member Author

No767 commented Jan 21, 2024

After some thinking and implementation, I am NOT doing an internal modmail-based hierarchy check at all, due to these reasons:

  1. Integrating said system would introduce complexities with the current permissions system checks
  2. It's insecure. Actions such as editing threads, adding channels, requires permissions. And Modmail's excuse for forcing users to invite the bot using admin perms is because of their internal hierarchy system. The hierarchy system that Modmail has basically does not protect it against discord.HTTPException errors when interacting with Discord
  3. I would have to store, and bulk add users into the user_settings just to store their current permissions value. That's an extremely expensive operation to do, as there are thousands of users that need to be dealt with. This would also slow the bot down.
  4. Just to spite the modmail dev team

Ultimately, permission checks with an built-in hierarchy check is what's going to be implemented. The checks are based off of R. Danny's checks, and have been modified to inject permission extras into the command so we can display what permissions are needed for what commands. If R. Danny can survive with 9,000+ servers with these checks, Rodhaj will also

@No767 No767 mentioned this issue Jan 21, 2024
15 tasks
@No767 No767 moved this from Todo to In Progress in Rodhaj Jan 21, 2024
@No767 No767 linked a pull request Jan 21, 2024 that will close this issue
15 tasks
@No767 No767 closed this as completed in #50 Jan 25, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in Rodhaj Jan 25, 2024
@No767 No767 removed this from Rodhaj Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant