refactor: permission handling for overwrites

[sudojunior]

It should be important to note that the bot doesn't have access to these nodes in overwrites if it's not granted them globally (or probably in the parent category). The app, by itself, would have no intention of using it's access to these to begin with but it suddenly becomes necessary when discussing how players should be restricted from the same level of access.

Personally I think the last one is excessive and requires careful assessment for what I actually need.

Permission groups

Spectator - Branching constant

'Would be' defined as a neutral perspective to the game itself, no immediate actions available to them. All available permissions should be denied by default. If private threads are available on a given server, it may be possible to open a spectator thread within the channel (therefore promoting SEND_MESSAGES_IN_THREADS up from Player)... but that also has it's consequences with metagaming and upholding the rules of the game throughout.

• Category Channel
  • ✅ VIEW_CHANNEL
  • ❎ CREATE_INSTANT_INVITE, MANAGE_PERMISSIONS!
• Text Channel
  • ❔ READ_MESSAGE_HISTORY, USE_EXTERNAL_EMOJIS
  • ❎ SEND_MESSAGES, ADD_REACTIONS

Player inherits from Spectator

Defined as anyone participating in the game itself.

• Text Channel
  • ✅ SEND_MESSAGES, SEND_MESSAGES_IN_THREADS
  • ❎ READ_MESSAGE_HISTORY

Host? inherits from Player

Defined as the initiator of the game.

This doesn't have to exist, since the app would be able to identify the host from the data entry anyway, but I figured it would be worth the consideration to continue having an artificial 'role group' of sorts.

Observer inherits from Spectator

Defined as anyone with existing access to the entire category.

Manager inherits from Observer and Player - the former takes priority on existing permissions. Defined as the application itself... not the role it may get when it joins.

• Text Channel
  • ❔ MANAGE_THREADS
• Category Channel
  • ✅ MANAGE_CHANNELS, CREATE_INSTANT_INVITE
  • ❔ MANAGE_WEBHOOKS, MANAGE_EVENTS
  • ❎ MANAGE_PERMISSIONS!
• Text Channel
  • ✅ EMBED_LINKS, ADD_REACTIONS
  • ❔ ATTACH_FILES, MANAGE_THREADS

Manager inherits from Observer and Player - the former takes priority on existing permissions

Defined as the application itself... not the role it may get when it joins.

• Category Channel
  • ✅ MANAGE_CHANNELS, CREATE_INSTANT_INVITE
  • ❔ MANAGE_WEBHOOKS, MANAGE_EVENTS
  • ❎ MANAGE_PERMISSIONS!
• Text Channel
  • ✅ EMBED_LINKS, ADD_REACTIONS
  • ❔ ATTACH_FILES, MANAGE_THREADS

---

! The reason the last one isn't given is because there's an error thrown if the bot doesn't have full server access (and is also the reason for attempting find a solution to begin with). With that in mind, I have the intention of maintaining best practice for only getting the permissions I (or the application) require to run. There is a general etiquette that fails to be followed in Discord bots where full admin ( bitfield of 8) is requested at OAuth and nothing else. Sure, some have their reasons as a moderator bot and others provide options to work around it - but it's not followed by everyone.

Original plan for permissions rollout...

It went well, if I consider that this was meant to happen - but in truth I never really did know.