The Permission Inheritance Model

GravityOps Forum features a powerful and flexible permission system that allows administrators to define who can view, post, and moderate specific sections of the forum. This is achieved through “Access Sets” and a hierarchical inheritance model.

Access Sets #

The core of the permission system is the “Access Set.” An Access Set defines specific capabilities:

• View: Can the user see the board/forum/topic?
• Post: Can the user create new topics?
• Reply: Can the user post replies to existing topics?
• Edit Own: Can the user edit their own topics and replies, and lock or delete their own topics?
• Moderate: Can the user sticky, lock, edit, or delete any topic or reply?

Administrators can map different WordPress roles (e.g., Administrator, Subscriber, or even “Anonymous” for logged-out users) to these Access Sets.

Hierarchy and Inheritance #

The permission system follows a two-tier hierarchical model:

1. User-Role Hierarchy: Higher-privileged Access Sets automatically inherit access to lower-privileged forums. For example, a user mapped to the Moderator set can view and participate in a forum that only requires Read Only or Standard User access.
2. Forum-Topic Inheritance: Individual topics automatically inherit their permissions from the forum where they are posted.

This structure allows you to have public and private sections within the same community while ensuring that staff and highly-privileged users can access all content without needing multiple role mappings.

Fail-Closed Security Model #

The plugin uses a “fail-closed” security approach to ensure that unauthorized access is prevented:

• No Access Set: If a forum does not have an Access Set assigned, all access is denied by default (except for site administrators).
• Unmapped Roles: If a user’s role is not mapped to an Access Set, they will be unable to view or interact with the forum.
• Moderator Privileges: Moderation actions (sticky, lock, delete) are strictly limited to those roles mapped to an Access Set with “Moderate” capabilities enabled.

By using this model, you can easily manage permissions across thousands of topics and forums from a centralized dashboard.

Inheriting Access to WordPress Child Pages #

GravityOps Forum enforces inherited access for any standard WordPress page that is a descendant of a mapped (or auto‑discovered) forum page:

• Covered ancestor types: index, forum, topic, profile.
• Detection is based on the plugin’s page settings and the auto‑discovered shortcode_map — no content scanning in order to keep your sites performance fast.
• Scope: any ancestor in the chain (not just immediate parent). Strategy is configurable via filter.
• Deny behavior: guests are redirected to the Profile (login) page with gofrm_redirect back to the original URL; logged‑in but unauthorized users are redirected to a permission‑denied destination (defaults to Forum Index).

Strategy and Filters #

• Default strategy: strongest (most restrictive) requirement among matched ancestors.
• Switch to first‑match: add_filter( 'gofrm_inherit_access_use_first_match', '__return_true' );
• Master switch: add_filter( 'gofrm_inherit_access_enabled', '__return_false' ); to disable entirely.
• Custom login URL: add_filter( 'gofrm_inherit_access_login_url', function( $url ){ return $url; } );
• Custom denied URL: add_filter( 'gofrm_inherit_access_denied_url', function( $url ){ return $url; } );
• Bypass in Strict Pretty URLs mode: enabled by default. Override with add_filter( 'gofrm_inherit_access_bypass_strict_mode', '__return_false' );
• Force a page to be treated as within a forum tree: add_filter( 'gofrm_inherit_access_is_forum_ancestor', function( $is, $post_id ){ return $is; }, 10, 2 );

Conservative Fallback #

• When a specific forum_id cannot be determined from the request, access falls back to the plugin’s default for view without context: requires the user to be logged in.