Skip to content
Gravity Tables
All documentation

Reference

Permissions

View, edit, and action gates with WordPress roles + capabilities.

Gravity Tables permissions operate in three layers: view access, edit access, and action access. Every layer is enforced server-side; no security check relies on the client UI.

Layer 1: View access#

allowed_roles#

Comma-separated WordPress role slugs.

[gravity_table id="42" allowed_roles="customer,subscriber"]
  • A logged-in user with at least one matching role sees the table
  • Users without any matching role get a polite “You don’t have permission” message
  • The * token allows any logged-in user
  • Empty / omitted means anyone (including guests)

The check is database-layer: failed users never receive the entries.

require_login#

[gravity_table id="42" require_login="true"]

Hides the table entirely from guests (no log-in prompt either). Useful when the table’s existence is sensitive.

Layer 2: Edit access#

allow_edit#

Comma-separated columns that become inline-editable.

[gravity_table id="42" allow_edit="phone,address,preferences"]

Cells in allow_edit columns:

  • Show a “Click to edit” tooltip on hover
  • Render as the appropriate native control on click (text input, select, date picker, etc)
  • Save on blur or Enter, cancel on Escape
  • Pass values through Gravity Forms’ validation pipeline before commit

edit_permissions#

Per-column capability gates. Format: column:capability.

[gravity_table id="42"
  allow_edit="status,priority,notes"
  edit_permissions="status:manager,priority:manager"]

In this example:

  • notes, editable by anyone with view access
  • status, priority, editable only by users with manager capability

Use capabilities, not roles, in edit_permissions. Roles can change names; capabilities are stable. WordPress core uses capabilities for the same reason.

Layer 3: Action access#

Bulk actions, exports, and the Add Entry button each have their own gates.

bulk_permissions#

[gravity_table id="42"
  bulk="approve,delete,export"
  bulk_permissions="delete:manage_options"]

Approve and Export are available to all viewers; Delete is gated to admins.

export_permissions#

[gravity_table id="42"
  export="csv,excel,pdf"
  export_permissions="excel:manager"]

CSV and PDF for everyone; Excel only for managers.

add_permissions#

[gravity_table id="42"
  allow_add="true"
  add_permissions="customer,manager"]

Only those capabilities see the Add New Entry button.

Audit log#

For compliance, log every edit:

[gravity_table id="42" allow_edit="status" audit_log="true"]

Audit entries store:

  • entry_id, field_id, old_value, new_value
  • user_id, user_login, ip_address, user_agent
  • timestamp (UTC)

View at Tables → System → Audit log. Export to CSV from the same screen.

For exports specifically:

[gravity_table id="42" export="csv,pdf" audit_exports="true"]

Logs format, row count, filter state JSON, and SHA-256 hash of the generated file.

Capability check vs role membership#

edit_permissions="status:manage_options" matches the capability, not the role. If you’ve granted manage_options to a custom role (e.g., editor via a role-management plugin), those users will now have edit access. Audit your roles before relying on capability gates.

Multisite#

On a multisite WordPress install, capability checks default to the current blog’s capabilities. A user who’s administrator on Blog A but subscriber on Blog B will hit subscriber rules on Blog B’s tables. This is correct behaviour.

← All documentation