GravityView capabilities

Note: A custom role needs no GravityView or Gravity Forms capabilities for its users to edit their own entries: turn on Allow User Edit on the View’s Edit Entry settings tab. The role does need the WordPress read capability, or the Edit Entry screen opens with no fields. How does GravityView know who can edit the entry? explains each check.

GravityView capabilities #

You can control who has each GravityView capability. We recommend managing them with the Members plugin.

GravityView’s capabilities are standard WordPress capabilities. Each time an admin page loads, GravityView gives the built-in roles (Administrator, Editor, Author, Contributor, and Subscriber) any default capability they are missing, so a capability you only remove comes back.

To take one away from a built-in role, deny it, for example with the capability’s Deny checkbox in Members. The free User Role Editor plugin can remove a capability from a role but can’t deny it.

Administrators also have gravityview_full_access, which grants every GravityView capability, including any denied to their role. To take a capability away from administrators, deny gravityview_full_access as well. Remove Data clears these denials, so deny the capabilities again after removing GravityView’s data.

Full access

gravityview_full_access: Gives the user every other GravityView capability. It also lets them edit Views without the unfiltered_html capability.

Settings

gravityview_view_settings: Shows the Data Source column in the Views list, with a Settings link to each View’s form.
gravityview_edit_settings: GravityView gives this capability to administrators but doesn’t check it.
gravityview_uninstall: Controls whether the user can remove GravityView’s data, with the Remove Data section of GravityKit’s settings or the dialog that opens when GravityView is deactivated. Uninstalling GravityView and removing its data lists what it deletes.
gravityview_getting_started: Controls whether the user can open GravityView’s Getting Started page, with its List of Changes and Credits tabs.

Users who can also edit Views get GravityKit’s Welcome page in its place: the Getting Started menu item is hidden, and the page’s address opens GravityView’s page on Welcome. Users who can’t edit Views, such as Contributors and Authors, still get Getting Started. Welcome doesn’t check gravityview_getting_started, so a role that can edit Views sees it without that capability.

GravityKit’s Settings page, which holds GravityView’s settings, needs the WordPress manage_options capability. By default only administrators have it, whatever GravityView capabilities other roles have.

Entry capabilities

gravityview_moderate_entries: Controls whether entries can be approved or rejected. Without it, the Gravity Forms Entries screen has no approval column and no Approve, Disapprove, or Reset Approval bulk actions. It’s also needed to moderate entries from the front end.
gravityview_edit_others_entries: Controls whether the user can edit other users’ entries on a View’s Edit Entry screen, even when Allow User Edit is off. A View’s Edit Window doesn’t close editing for these users.
gravityview_delete_others_entries: Controls whether the user can delete other users’ entries from a View. When a View’s Edit Window also closes deleting, these users can still delete.
gravityview_edit_entries: Shows Edit Entry in the WordPress toolbar on a View’s single entry page, linking to the entry in Gravity Forms. With the WordPress list_users capability, it also lets the user change who created an entry (Change Entry Creator) while editing it in Gravity Forms.

Users with the Gravity Forms gravityforms_edit_entries capability can also edit every entry in a View, and an Edit Window doesn’t close editing for them either. Setting an editing deadline with Edit Window explains the deadline, and Creating an Entry Moderator role shows how to give a role these capabilities.

Entry notes capabilities

gravityview_add_entry_notes: Controls whether the user gets the form for adding a note in a View’s Entry Notes field, and can add notes with it.
gravityview_view_entry_notes: Controls whether the user sees the notes in a View’s Entry Notes field.
gravityview_delete_entry_notes: Controls whether the user can delete notes in a View’s Entry Notes field. The delete controls are part of the notes list, so the user also needs gravityview_view_entry_notes.
gravityview_email_entry_notes: Controls whether the user can also email a note while adding it.

View capabilities

edit_gravityviews: Controls whether Views can be edited. Without it, All Views and New View don’t show in the GravityKit menu.
edit_others_gravityviews: Controls whether Views owned by other users can be edited.
publish_gravityviews: Controls whether Views can be published.
read_private_gravityviews: Controls whether private Views can be read.
delete_gravityviews: Controls whether Views can be deleted.
delete_private_gravityviews: Controls whether private Views can be deleted.
delete_published_gravityviews: Controls whether published Views can be deleted.
delete_others_gravityviews: Controls whether Views owned by other users can be deleted, and whether the Delete Views section shows in GravityKit, then Settings, then GravityView.
edit_private_gravityviews: Controls whether private Views can be edited.
edit_published_gravityviews: Controls whether published Views can be edited.
copy_gravityviews: Controls whether the Clone and New Draft links show in the Views list.

Warning: A user without the unfiltered_html capability can’t edit Views, whatever View capabilities their role has. The only exception is a user with gravityview_full_access.

The built-in Editor role has unfiltered_html, but a custom role built up from Subscriber does not. On a multisite network, WordPress gives the capability to Super Admins only.

Creating a View Editor role sets up a role that can edit Views with these capabilities.

The GravityView tools of the GravityKit MCP check the same capabilities, so a role you set up for an AI assistant needs unfiltered_html as well. Creating Views with AI using the GravityKit MCP covers the setup. Where a role can’t have it, the gravityview/security/require_unfiltered_html filter turns the requirement off for the users you choose.

Support capabilities

gravityview_contact_support: GravityView gives this capability to administrators but doesn’t check it.
gravityview_support_port: Controls whether the Support Port help panel loads on GravityView’s screens, and whether the user’s profile has the GravityView Support Port setting.

Per-View capabilities

These are meta capabilities: each one stands for an action on a single View. They don’t appear in a role editor such as Members, and adding them to a role has no effect. WordPress turns them into the primitive capabilities listed under View capabilities above, based on who authored the View.

edit_gravityview: Controls whether a specific View can be edited.
read_gravityview: Controls whether a specific View can be read.
delete_gravityview: Controls whether a specific View can be deleted.

Letting a role edit only one View

The primitive capabilities apply to every View, so edit_others_gravityviews grants editing on all of them at once. On its own, WordPress tells Views apart only by who authored them, which separates editing your own Views from editing everyone else’s. Each option below uses that difference.

Option 1: make the user the View’s author. Give the role edit_gravityviews, edit_published_gravityviews, and unfiltered_html, and leave edit_others_gravityviews off. That user can then edit any View they authored, and no others.

Views don’t show an Author box in the editor by default, so add one:

add_filter( 'gravityview_post_type_support', function ( $supports ) {
    $supports[] = 'author';

    return $supports;
} );

add_filter( 'gravityview_post_type_support', function ( $supports ) {
    $supports[] = 'author';

    return $supports;
} );

Option 2: grant one specific View. To tie the permission to a single View whoever authored it, filter user_has_cap and grant the primitive capabilities only for that one pair of user and View. The user still needs unfiltered_html.

Replace 45 with the user ID and 123 with the View ID:

/**
 * Allows one user to edit one specific View.
 *
 * The per-View meta capability (edit_gravityview) is resolved by WordPress into the
 * primitive capabilities granted below, so those are what need to be set.
 *
 * @param array $caps     All capabilities the user currently has.
 * @param array $required The capabilities required for this check.
 * @param array $args     [0] requested capability, [1] user ID, [2] object ID.
 *
 * @return array
 */
add_filter( 'user_has_cap', function ( $caps, $required, $args ) {
    $user_id = 45;  // The user who should get access.
    $view_id = 123; // The View they should be able to edit.

    // Only act on an edit check against a specific post.
    if ( 'edit_post' !== ( $args[0] ?? '' ) ) {
        return $caps;
    }

    // Bail unless this is the exact user and View pairing.
    if (
        (int) ( $args[1] ?? 0 ) !== $user_id
        || (int) ( $args[2] ?? 0 ) !== $view_id
    ) {
        return $caps;
    }

    $caps['edit_others_gravityviews']    = true;
    $caps['edit_published_gravityviews'] = true;

    return $caps;
}, 10, 3 );

/**
 * Allows one user to edit one specific View.
 *
 * The per-View meta capability (edit_gravityview) is resolved by WordPress into the
 * primitive capabilities granted below, so those are what need to be set.
 *
 * @param array $caps     All capabilities the user currently has.
 * @param array $required The capabilities required for this check.
 * @param array $args     [0] requested capability, [1] user ID, [2] object ID.
 *
 * @return array
 */
add_filter( 'user_has_cap', function ( $caps, $required, $args ) {
    $user_id = 45;  // The user who should get access.
    $view_id = 123; // The View they should be able to edit.

    // Only act on an edit check against a specific post.
    if ( 'edit_post' !== ( $args[0] ?? '' ) ) {
        return $caps;
    }

    // Bail unless this is the exact user and View pairing.
    if (
        (int) ( $args[1] ?? 0 ) !== $user_id
        || (int) ( $args[2] ?? 0 ) !== $view_id
    ) {
        return $caps;
    }

    $caps['edit_others_gravityviews']    = true;
    $caps['edit_published_gravityviews'] = true;

    return $caps;
}, 10, 3 );

Note: Adding custom PHP code snippets to your website explains how to add these snippets to your site.

Roles #

GravityView gives each built-in role these capabilities, and adds back any that are missing.

Administrator

Administrators get these capabilities and those of the roles below.

gravityview_full_access
gravityview_view_settings
gravityview_edit_settings
gravityview_uninstall
gravityview_contact_support
edit_others_gravityviews
edit_private_gravityviews
edit_published_gravityviews

Editor

Editors get these capabilities and those of the roles below.

read_private_gravityviews
delete_private_gravityviews
delete_others_gravityviews
publish_gravityviews
delete_published_gravityviews
copy_gravityviews
gravityview_edit_others_entries
gravityview_moderate_entries
gravityview_delete_others_entries
gravityview_add_entry_notes
gravityview_view_entry_notes
gravityview_delete_entry_notes
gravityview_email_entry_notes

Author

Authors get these capabilities and those of the roles below.

gravityview_edit_entries
gravityview_edit_entry
gravityview_edit_form_entries
gravityview_delete_entries
gravityview_delete_entry

Contributor

Contributors get these capabilities and those of the roles below.

edit_gravityviews
delete_gravityviews
gravityview_getting_started
gravityview_support_port

Subscriber

Subscribers get these capabilities:

gravityview_view_entries
gravityview_view_others_entries

Every built-in role also has the WordPress read capability. Users editing their own entries need it to see the fields on the Edit Entry screen.

GravityView capabilities