Debugging Permission Denied Errors

If users are seeing “Permission Denied” or are unable to view/post in the forum, follow these steps to diagnose the issue.

1. Check Administrator Access #

First, verify that administrators can see the content.

• Rule: Users with the manage_options capability (typically Administrators) bypass all forum-specific permission checks.
• Test: If an administrator cannot see the content, the issue is likely a Routing/404 issue or the content does not exist, rather than a permission problem.

2. Verify Role Mapping #

The forum uses “Access Sets” (Standard User, Moderator, Read Only) which must be mapped to WordPress Roles.

• Check Settings: Go to GravityOps > Forum > Access.
• Identify the User’s Role: Verify the WordPress Role of the affected user (e.g., “Subscriber”, “Contributor”).
• Mapping: Ensure that the user’s role is listed under the correct Access Set.
• Fail-Closed Behavior: If a WordPress role is not mapped to any Access Set, that user will have no access to restricted forums.

3. Check Forum Access Settings #

Each forum can be assigned a specific Access Set.

• Check Forum Configuration: Go to GravityOps > Forum > Forums and click “Edit” on the affected forum.
• Access Set Field: Ensure an Access Set is selected.
• Default Behavior: If no Access Set is selected for a forum, the plugin defaults to “fail-closed,” meaning only Administrators will have access.

4. Check Board and Forum Status #

Status restrictions are evaluated before regular capability checks.

• Forum Status:
  • active: Standard access-set behavior.
  • private: Requires login, then access-set match.
  • hidden: Requires login + access-set match and is not listed in non-admin indexes.
  • draft: Admin-only.
• Board Cascading:
  • A draft board makes all child forums admin-only.
  • A private or hidden board forces login across child forums, even if a child forum is active.

5. Understand Permission Hierarchy #

The plugin uses a hierarchical “Superset” logic rather than a strict ID match.

• Rule: A user is granted access to a forum if their role’s mapped Access Set contains all of the capabilities enabled in the Forum’s assigned Access Set.
• Example: If a forum is set to Read Only (view capability), users with the Standard User set (which has view, post, and reply) will have access.
• Check: If a user is blocked, compare the capabilities in their mapped set versus the forum’s set.
• Inheritance: Permissions flow from the Forum level down to all Topics and Replies within it.

6. Private/Locked Content #

Even if a user has permission to view a forum, they might be restricted from specific actions:

• Locked Topics: If a Topic is “Locked” by a Moderator, “Standard User” roles will be able to view the topic but will not see the “Reply” form.
• Trashed Entries: If a topic or reply has been moved to the trash in Gravity Forms, it will no longer be visible in the forum.

7. Shortcode Context Permissions #

When using shortcodes to embed a forum on a non-forum page:

• Verification: The plugin still performs full permission checks. If you embed a private forum on a public page, guest users will see a “Permission Denied” message (or nothing, depending on the template) even if the page itself is public.
• Logged In Requirement: Login is required when the resolved forum/board status is private or hidden. For active forums, access depends on access-set mapping (including anonymous mapping, if configured).