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.
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 constantVIEW_CHANNELCREATE_INSTANT_INVITE,MANAGE_PERMISSIONS!READ_MESSAGE_HISTORY,USE_EXTERNAL_EMOJISSEND_MESSAGES,ADD_REACTIONSPlayerinherits fromSpectatorSEND_MESSAGES,SEND_MESSAGES_IN_THREADSREAD_MESSAGE_HISTORYHost?inherits fromPlayerObserverinherits fromSpectatorMANAGE_THREADSMANAGE_CHANNELS,CREATE_INSTANT_INVITEMANAGE_WEBHOOKS,MANAGE_EVENTSMANAGE_PERMISSIONS!EMBED_LINKS,ADD_REACTIONSATTACH_FILES,MANAGE_THREADSManagerinherits fromObserverandPlayer- the former takes priority on existing permissionsMANAGE_CHANNELS,CREATE_INSTANT_INVITEMANAGE_WEBHOOKS,MANAGE_EVENTSMANAGE_PERMISSIONS!EMBED_LINKS,ADD_REACTIONSATTACH_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 of8) 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...