Permissions

link Introduction

Permissions are the way you control what users are able and not able to do on your server. Managing permissions correctly is extremely important to prevent abuse while giving your members an optimal experience.

However, it can be difficult to manage them correctly, and even small exploits that do not cause major issues can still make the server appear disorganized and poorly operated.

In this guide, we explain the details behind how permissions interact and are calculated. Additionally, there are often multiple ways to technically obtain the same effect, but some are much harder to maintain and can cause restrictions later on, so we give recommendations for how you may want to set things up.

link Mechanics

Certain actions like deleting messages apply in a specific channel, and the permissions that allow those can be set at a channel level. Categories can have these permissions set, but they do not actually give the permissions in their child channels, it just determines what overrides new channels in the category have, and synced channels (children with the exact same overrides) will be updated when the category's overrides are edited.

The priority order of permissions and overrides is as follows:

• If the user is the owner or has a role with the Administrator permission, they are allowed.
• If the user is timed out or has not passed membership screening and the permission is not View Channel or Read Message History , they are denied.
• If the user has a user-level override, it applies.^†
• If the user has a role that has a role-level override that allows that permission, they are allowed.^†
• If the user has a role that has a role-level override that denies that permission, they are denied.^†
• If there is an @everyone-level override, it applies. ^†
• If the user has a role that has that permission globally (including @everyone), they are allowed.
• If all fail, they are denied.

^† If the permission is not channel-level, e.g. Ban Members, this does not apply.

link How To

link Introduction

Due to the way permissions are calculated (allow role-level overrides always overrule deny role-level overrides regardless of hierarchy), you want to grant as few allow overrides as possible. Note that allow @everyone-level overrides are not an issue as role-level overrides take priority.

In the following sections, we cover many common patterns, the best way to set them up to optimize maintainability, and common pitfalls to watch out for.

link How do I set up a verification role?

Most servers have a role that is granted by clicking on the verification prompt to confirm that they have read the rules (as a weak filter against bots). Typically, channels are only visible to verified users except landing channels. Due to the way permissions are calculated, giving the verified role allow overrides will prevent you from denying them on other roles. For example, giving it Send Messages via an override will stop mute roles from working.

Before you set one up, consider using Discord's built-in member verification. This is stronger than verification roles, as a user who has not passed membership screening cannot DM server members. It automatically disables all interaction, including clicking buttons or adding to existing reactions. Verification roles are already a weak filter against bots, and allowing @everyone to see all public channels does not actually create any tangible threat.

If you've decided to do this anyway, the best way to set it up is to deny @everyone and grant your verification role View Channel at a base level. All channels are now automatically visible only to verified users. Then, just allow @everyone permission to see your landing channels via overrides (remember that allow @everyone-level overrides are not an issue).

In addition to not using unnecessary allow overrides, this is actually easier as you will only need to set up overrides on your landing channels. A common way to do this is to use a deny @everyone-level and allow role-level override on all non-landing channels, which is not only harder but also introduces allow role-level overrides.

If you want a public channel that @everyone can see but only verified users can send messages in, just disable Send Messages for @everyone and enable it for the verified role. If you then need a channel that @everyone can send messages in, just enable that via an override.

link How do I set up access roles

You may want to lock some channels behind access roles such as reaction roles, or staff channels for staff roles. For example, you might want to restrict your leaks channel behind a self-assignable role. In this case, you will need to use an allow role-level override. It is unavoidable, but this is acceptable because usually you don't need to set deny role-level overrides just for viewing the channel.

Firstly, add a deny @everyone-level override for View Channel. Then, add allow role-level overrides for any roles you want to grant access.

Importantly, do not enable any permissions other than View Channel like sending messages. If a user cannot see a channel, they cannot take any actions relating to the channel.

link What about public channels that only staff can send messages in?

For this, you will need to grant an allow role-level override. However, if it's going to staff, it is fine. The reason you want to avoid allow role-level overrides is that it stops you from disabling it per role via things like mute roles. However, you should not need to mute your staff members. Also, you have the option to use timeouts if needed.

link How do I set up a mute role?

Before you read this, consider if you want to use mute roles. Discord now has timeouts which are very similar but built into the system. There are several advantages - it makes it obvious to the user that they are timed out, lets moderators easily identify that they are timed out without letting other users be able to know, and shows a countdown to the user in the client.

There are a few disadvantages as well - it can only last up to 28 days, and it disables all permissions except view channel and read message history. In fact, they cannot even react, even to reactions that already exist, and cannot interact with buttons either. This prevents them from using reaction roles.

If you have decided that you want to use a mute role instead, you will want to set an override in every channel (where the mute role matters) that denies permissions you want muted users to be unable to use. We recommend Send Messages, Send Messages in Threads, Add Reactions, Connect, and Use Application Commands. If you allow your members to create threads, you should deny that to the mute role as well.