# 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).
