Description
Disclaimer: This plugin is not affiliated with, endorsed by, or sponsored by Rocketgenius, Inc. Gravity Forms is a trademark of Rocketgenius, Inc. This plugin is an independent third-party extension.
Out of the box, only Administrators can use Gravity Forms. That is usually wrong for real sites: the person who writes the content is often the same person who should build the contact form and read the submissions, but handing them an admin account to do it is a bad trade.
This plugin gives the Editor role access to Gravity Forms, and lets you decide precisely how much.
On activation it grants a sensible starting set: Editors can build, preview and delete forms, and view, edit, export and annotate entries. It does not grant anything that changes site configuration, and it does not grant entry deletion. From there, a single settings screen under Forms Settings Role Permissions turns each individual capability on or off with a checkbox.
Add-on capabilities are detected automatically
Add-ons register their own capabilities, and those are usually the ones that trip people up: the Editor can reach the form editor but the add-on’s settings tab is invisible, with no obvious reason why.
This plugin reads the active add-ons directly from Gravity Forms and lists their capabilities in their own sections, using the add-on’s own labels. Nothing is hard-coded. New add-ons, and third-party ones, show up without an update to this plugin, and add-ons you do not have are never shown.
Capabilities that can escalate to administrator
Some capabilities can be turned into full administrator access by the person you grant them to. gravityforms_user_registration is the clear case: it allows editing User Registration feeds, and those feeds assign WordPress roles, so anyone who holds it can make themselves an administrator.
This plugin does not offer those capabilities at all. The settings screen lists each one with an info line instead of a checkbox, explaining that it is disabled because of the privilege escalation risk. That way it is clear the capability was considered, not overlooked. If the Editor role already holds one because other code granted it, the screen says so, so you can remove it there.
If you maintain your own list, the resonanz_user_role_permissions_gf_blocked_caps filter lets you add to it. The built-in entries cannot be removed through the filter.
Careful with your existing setup
The plugin records which capabilities it granted. When you uninstall it, only those are removed. Capabilities the Editor role already had: from custom code, a role editor, or another plugin, are left exactly as they were.
Deactivating changes nothing at all. Your configuration is still there when you switch it back on.
FAQ
-
Does this work with roles other than Editor?
-
Not in this version. Version 1 manages the Editor role only, which covers the large majority of sites that need this. Support for other roles is planned.
-
What is the “Full access” checkbox?
-
It grants
gform_full_access, Gravity Forms’ catch-all capability. It overrides every individual permission, including capabilities added by add-ons you install later. It is there because it is occasionally what you want, and because sites migrating from a code snippet often already have it. For most sites the checkboxes are the better choice. -
I unchecked a box but the user still has access.
-
Check whether “Full access” is on. It overrides everything. Also check whether the user has more than one role, or whether another plugin grants the capability. Removing it here only affects the Editor role.
-
Does this modify Gravity Forms?
-
No. It only adds and removes capabilities on the Editor role using the standard WordPress roles API. Gravity Forms itself is untouched.
-
Where can I find further help?
-
If you require assistance or experience technical problem, feel free to contact us
Reviews
There are no reviews for this plugin.
Contributors & Developers
“Resonanz User Role Permissions for Gravity Forms” is open source software. The following people have contributed to this plugin.
Contributors
Translate “Resonanz User Role Permissions for Gravity Forms” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.2.0
- Renamed to “Resonanz User Role Permissions for Gravity Forms”. The plugin slug and text domain are now
resonanz-user-role-permissions-gf, and the settings tab is now Forms Settings Role Permissions. - Saved settings carry over. The stored capability list moves to its new option name automatically, on reactivation or on the next admin page load.
- Capabilities that escalate to administrator access are no longer offered.
gravityforms_user_registrationnow shows an info line explaining why, instead of a checkbox. If this plugin granted it before, it is revoked on upgrade. - The
resonanz_role_access_risky_capsfilter is replaced byresonanz_user_role_permissions_gf_blocked_caps. - Fixed the capability groups stacking in a single column. They now sit two side by side, like the panels on other Gravity Forms settings screens.
- The settings tab now carries the non-affiliation note below the save button, so it is clear inside the Gravity Forms admin that this is not an official add-on.
1.1.0
- The settings screen is now a tab on the Gravity Forms settings page, at Forms Settings Role Access, alongside the official add-ons. The old Forms Role Access menu entry is gone; the Settings link on the Plugins page points at the new location.
- The tab is registered for administrators only. Gravity Forms applies no capability check to registered settings tabs, so an Editor holding
gravityforms_view_settingswould otherwise have been able to open the screen that hands out capabilities. - Capabilities that can be escalated to administrator access are now marked with a visible warning.
gravityforms_user_registrationis flagged by default, and theresonanz_role_access_risky_capsfilter accepts more. - Added the non-affiliation disclaimer required for pages about Gravity Forms products.
- The screen now uses Gravity Forms’ own settings markup, so it matches the rest of their admin:
gform_settings_formfor the two-column grid,gform-settings-panelcards with title bars for each capability group,gform-settings-choicecheckbox rows, and theiralertstyles for notices. Most of the plugin’s own CSS became unnecessary as a result. - Fixed the save button rendering white on white. Gravity Forms styles
.gform-settings__wrapper .buttonwith a white background and no colour, so the white label of WordPress’.button-primarysurvived and the button was only legible on hover. It now uses Gravity Forms’ own.button.primaryclass.
1.0.1
- Lowered the PHP requirement from 8.0 to 7.0. The plugin never used any PHP 8 syntax; the header alone stopped WordPress from activating it on older servers.
- Replaced the constructs that needed a later PHP 7 release: a typed static property and an arrow function (both 7.4),
voidand nullable return types, and class constant visibility modifiers (all 7.1). - No functional change. Behaviour on PHP 8 is identical.
1.0.0
- Initial release.