Roles and Permissions are used in tandem to control what users can see and do in your community.
It will be important to review them carefully prior to launch, as well as when updating your forum's settings.
To review or edit your roles and permissions, navigate to your dashboard, select the settings tab, and navigate to Roles and Permissions under Membership:
On this screen you can view an overview of existing roles as well as edit or delete them. You can also add a new role from this view.
There is also an additional settings tab where you can toggle a few additional options:
Within this popup, community admins can enable Private Communities and control what permission level is required to expand the SSO ID permission via the API.
If you are ever unsure about any settings, contact your CSM, Implementation Project Manager or Vanilla Support.
Note for clients with a pending Migration:
During your test and final migrations, your current users and roles will be imported into your production site.
Because Vanilla has its own feature set and will likely vary from your previous provider, the roles and permissions will need to be adjusted. It usually makes sense to analyze and note these during the test migration, as they will be wiped out during the final migration and will need to be re-applied postFinal Migration. If you are unsure, contact your implementation project manager.
Notes for clients using SSO
When using SSO, you can choose to pass roles (or not). You can read more about this here:
Vanilla comes with 6 roles out of the box (Guest, Unconfirmed, Applicant, Member, Moderator and Admin). What roles you actually use will depend on your registration settings, where you are in the community lifecycle and if you plan on using SSO.
If you are migrating from another platform, plan on using SSO, have a private community, or have a highly customized setup, your roles may vary from those seen here. If you are unsure, contact your CSM.
Note: The account owner is the main forum administrator of your team. This role does not show in the Dashboard and is set up by the Vanilla team, and is a kind of super admin.
It’s important not to use this role for permissions testing as it will supersede the assigned roles & permissions settings.
This is a special role that represents non-logged in users in Vanilla. You can use this role to restrict what logged out users see when viewing your forum.
As Vanilla does not allow anonymous posting, this role cannot be given other permissions.
If you do not want any guests to see your community at all (i.e., require login to view), you can also enable Private Communities. If you set your community to private, only registered members will be able to view and post. If a user that is not logged in browses to the community, they will see a login page or be redirected to SSO sign-in, if applicable.
Since search engines and their crawling bots are essentially guest viewers, it’s important to understand that only content guests are allowed to see will be indexed and appear in public search results (i.e., google, bing, etc). If you set your community to private, or restrict view permissions for the guest role, your community may not be indexed at all.
If your community is using Vanilla-based registration (i.e., not SSO), and have required users to confirm their email, this role will be given to users who have registered but have not confirmed their email address yet.
If your community is using Vanilla-based registration (i.e., not SSO), and have the Approval method of registration enabled, this role will be given to users who have applied for membership but have not yet been accepted by an admin or mod. Out of the box, they have the same permissions as guests.
Default user role - Members can participate in discussions and access all end-user functionality.
Default types are a way of identifying certain standard user types for other aspects of the Vanilla functionality. For example, some communities might call their end users “Members” like we do out of the box in Vanilla, while others might call them “Registered Users” or “Forum Users” or whatever makes sense within the context of your community. Regardless of what you call them, some parts of the Vanilla application need to understand what roles represent the basic standard member-level user. Default types are used to identify such roles.
The Default role type must be applied only as necessary, as it will govern some default behaviours and permissions, such as assigning a member role automatically on sign-in (or once approved from the applicants’ queue, depending on registration type). For example, if you create a special ‘beta tester’ role that should only have access to a special category, you would NOT want to give it the default type of member as it will assign any and all roles with Member as the default type to users automatically upon sign-in, which may not be the desired behaviour.
The default role type "Member" dictates the roles users are assigned upon registration. Make sure to only choose the default role type "Member" for roles you want auto-assigned on registration.
Moderators have permission to edit content and use the moderation features.
Your moderators manage day-to-day life in your forum. They typically have permission to edit and curate content, review spam and moderation issues, as well as manage user accounts.
Administrators have permission to do everything including configuring the account and creating new Roles. Your administrators are those that are responsible for the forum set up including creating new accounts, configuring add-ons, managing categories and themes.
To delete a role, click the trashcan icon to the right:
This will open an additional dialog box that will allow you to assign another role to any users who currently have that role. If users already have multiple roles, this may not be necessary. However, if the role to be deleted might be the only role some users have, it will be very important to select a replacement role to ensure that users have at least one role with the sign in permission or they will not be able to access the application.
Why can’t I delete some roles?
Some roles are needed for the infrastructure of certain features and cannot be deleted, such as guest, unconfirmed and applicant.
To edit a role, click the crayon icon to the right of the role:
From this screen, in addition to editing the permissions themselves (detailed below) you can also edit the Name of the role. This will typically appear in user profiles, but will only appear on posts in conjunction with the Role Titles addon.
The Default role type must be applied only as necessary, as it will govern some default behaviours and permissions, such as assigning a member role automatically on sign in. For example, if you create a special ‘beta tester’ role that should only have access to a special category, you would NOT want to give it the default type of member as it will assign that role to users automatically upon sign in.
See above for details on what the default type governs for each default role.
If you toggle the “Personal Info” option for a particular role, the role name will only appear on the frontend to users with the “Personal Info” -> view permission and not regular users.
Certain permissions are associated with optional addons and integrations. If you do not see a particular permission in your roles and permissions, ensure the associated addon or integration is enabled, or contact your CSM or Support.
The Garden section of roles and permissions governs 3most basic permissions in Vanilla and should be carefully reviewed for all roles ahead of the launch of your community.
Allows the user to view the activity on the Activity Page.
Delete any activity (regardless of author) from the Activity Page.
Allow Advanced Notifications
This permission is now deprecated since the introduction of our category following feature.
Enables users who have the “View Settings” but not “Manage Settings” permissions access to:
- Banner settings
- Category settings
- Reaction settings
- Typically a default permission of the Moderator role
- Gives access to the ‘Promote’ Reaction
- Note: The Promote reaction gives 5 points to the promoted content and displays it on the Best of Page. (Read more)
- Gives additional weighting to SPAM or Abuse reactions
- When reacting with the SPAM and Abuse reactions, this will set the user’s reaction to have a weight of 5 points rather than the default 1 point per reaction. (Read more)
- Gives users the ability to mark answers as rejected/accepted (Read more)
- Gives users the ability to change a discussion to a question when the Q&A addon is enabled.
Allows users to receive notifications via email. This does not reveal email addresses of other users to the role. Should only be disabled for roles who should not receive email notifications of any kind (including password reset emails, etc).
This permission is typically what identifies a user as a moderator.
- Typically a default permission of the Moderator role
- Gives access to the moderation queue (Read more)
- Gives access to the SPAM queue (Read more)
- Gives permission to change the status of an idea when Ideation is enabled (Read more)
- Gives permission to approve Role Applications (Read more)
Allow No Ads
Hides Pockets labeled as ads. (Read more)
View Personal Info
Allows viewing of personal info such as Email, Register IP and Last IP on the profile page. It is strongly recommended that this is only given to admins and trusted moderators for security reasons.
Edit Profile Picture
Allows users to edit their own profile picture
Allows editing of the users’ own profile. Does not grant the permissions to edit other users’ profiles.
Allows viewing other members’ profile pages.
- Typically a default permission of the Moderator role
- Allows viewing of account settings in the Dashboard. Required for “Community Manage” and for “Manage Moderation” to have access to dashboard functionality.
This permission is typically what identifies a user as an administrator.
Grants full access to all functionality in the dashboard. This is an Admin only permission.
Allow Sign In
The permission to log in. Should generally be enabled but can be used to temporarily prevent a group of users from logging in.
For certain integrations like Zendesk and Salesforce, this allows for staff to access the plugin functionality without gaining forum moderation tools.
For use with APIv2. Allows users to generate personal API tokens via their profile. The tokens’ permissions will be reflective of the permissions of the user who generated the token. (Read more)
Allows users to upload attachments when using the Rich editor (Read more)
Allows moderators and admins to manually create users on the User page in the Moderation section of the dashboard (read more), as well as to create users via the API using their API token.
Allows moderators and admins to approve users’ requests for membership, if using the Approval registration method.
Allows moderators and admins to delete members from the User page in the Moderation section of the dashboard as well as to delete users via the API using their API token. (Read more)
Allows moderators and admins to edit user info in the dashboard, on frontend user profiles, as well as via the API using their API token.
If this permission is set, unverified members’ posts will have to be approved from the moderation queue before they are posted on the community (also known as pre-moderation). (Read more)
Deprecated. Does nothing.
Gives users the ability to close their own discussions. (Read more)
If the Tagging addon is enabled, this will allow users to create new Tags. Note that if tagging is enabled, all users will be able to add existing tags to discussions. This permission is to allow new tags to be created.
Conversations are private messages sent between users. (See main article).
Allows for new private conversations to be added. Removing this from members will still allow them to receive messages from those with the permission, they simply will not be able to initiate conversations.
Admins and mods need the permission to Add Conversations if they want to use the Warnings & Notes Addon.
Manage Moderation Conversations
Allows admins or mods to view and manage private messages between members. This permission is not recommended. Should you have an appropriate use case, a config setting change must be requested through your CSM or Support.
Allow Attachments Upload
Permission to upload files when using a legacy editor (any editor other than the Rich editor).
Grants access to the Pockets addon, if enabled. (Read more)
Permission to create a poll-type discussion when the Polls plugin is enabled. (Read more)
Permission to create and edit a signature when the Signatures plugin is enabled. (Read more)
This section of permissions only applies if the Badges addon is enabled.
Grants ability to manually award badges from a users profile page or from the badges page, as well as to approve badge requests. This also governs the ability to give badges via the API using their API token. (Read more.)
Allows for the creation and management of badges in the dashboard. (Read more.)
Allows users to request a badge from the badge request page. It will send the request to the badge request queue. (Read more.)
Ability to see badges on profiles (Read more.)
This section of permissions only applies if the Reactions addon is enabled.
- Allows use of the “Spam” or “Abuse” Reactions, which have the ability to accumulate to then hide posts for review. (Read more)
- Gives the ability to report posts (Read more)
Allows use of “Dislike”, “Downvote”, “Off Topic”, and “WTF” Reactions. Negative Reactions are inactive by default. (Read more)
Allows use of positive Reactions. (Read more)
This section of permissions only applies if the Groups and Events addon is enabled.
Grants the ability to create new groups (Read more)
Grants the ability to moderate groups, even if not a group member. (Read more)
This section of permissions only applies if the VanillaPop addon is enabled.
When using VanillaPop, grants ability to comment by email.
When using VanillaPop, grants ability to add private messages by email.
When using VanillaPop, grants ability to add Discussions by email.
This section of permissions only applies if the Knowledge addon is enabled.
Allows users to add new articles to your KB (Read more)
Allows users to view your KB (Read more)
This applies to any categories that do not have ‘custom permissions’ enabled.
See main article on roles and permissions: https://success.vanillaforums.com/kb/articles/8-category-configuration-management
To enable custom permissions on a particular category, edit the category in question and toggle the ‘This category has custom permissions’ option. (Read more)
Add Comments / Discussions
- Enables the user to create new discussions or comments in the category.
- The Add.Comment permission is also necessary for users to vote on polls.
- Enables the user to announce a discussion (sometimes called ‘pinning’) in the category (Read more)
- Allows admins/mods to close a discussion to new comments in the category.
- Note: Admins/mods will still be able to comment.
- If you would like users to be able to close their own discussions, use the ‘Closeown discussions’ permission above instead. (Read more)
- Allows admins/mods to delete any and all discussions or comments in the category (Read more)
- Allows admins/mods to edit any and all discussions or comments in the category. (Read more)
- Allows admins/mods to sink any and all discussions or comments in the category. When you sink a discussion it won't be brought to the top of the discussion list when new comments are added. This feature is typically used to de-emphasize a discussion and keep it off the recent discussion lists in a more subtle way than just closing it. (Read more)
Allows users to view discussions and their associated comments in the category.
Special Considerations for Infrastructure Categories
Member-type users should typically be allowed to create reports, but not see them. In order to report a discussion, members need the ‘add comment’ permission for the Reported Posts category but should have no other permissions for this category
The social groups category is an infrastructure-only category and is not meant to be viewed by end users. It is used with our Groups addon.
All users should only have the permission to add discussions and comments, not view.
If users have the permission to view this category, they will see posts from all groups, including private and secret or if they belong to them.
Allowing users to view this category will create unexpected behaviour and is strongly discouraged.
Theming and Visual Considerations
The Role of a user is typically only visible on posts if the Role Titles addon is enabled, but is usually shown on user profiles.
The description is only visible to admins and mods.
If you would like to hide a role from profiles (or from the role titles addon), you can do so by enabling the checkbox for “This role is Personal Info. Only users with permission to view personal info will see it.”