Per-table "Add New Entry" toggle, sometimes the answer is "off"
A small but heavily-requested switch: turn the "Add New Entry" button on or off per table. Some dashboards are read-only. Now the UI matches.
- Per-table setting to show or hide the "Add New Entry" button
- Independent of user permissions, admins can hide for everyone
- Permission-aware: button respects both setting AND role capabilities
- Clean default: hidden until explicitly enabled in table builder
Some tables exist to display data. Some exist to display and collect data. The UI should reflect the difference.
The shape of the request#
A common pattern in support emails:
“Our Q1 sales table is read-only, no one should be adding rows from the dashboard. But the Add New Entry button shows because the user has GF entry permissions. Can we hide it?”
In 2.3.2 we added a per-table switch. Table builder → Display → “Show Add New Entry button”. On = visible (subject to permissions). Off = hidden, server-side enforced.
Why this isn’t just a permissions question#
We could have told users: “configure permissions so the role can’t add entries”. That would have hidden the button. It would also have stopped users with that role from adding entries through any path, Gravity Forms admin, REST API, other plugins, which is usually too aggressive.
The new switch is a display-only setting. The user might still be able to add entries elsewhere; just not from this particular table’s UI. That matches how most teams actually want to scope read-only views.
How it interacts with permissions#
The button appears only when both of these are true:
- The “Show Add New Entry” setting is on for the table
- The current user has
gravityforms_create_entriescapability (or a custom role granted equivalent)
If the setting is off, the button is hidden for everyone, even admins. If the setting is on but the user lacks permissions, the button is also hidden.
Server-side enforcement on the AJAX handler makes this not just a UI hide: even if someone unhides the button via DOM manipulation, the AJAX endpoint returns 403.
Default behaviour#
For new tables, the button defaults to hidden. We chose this because:
- Most tables shipped with Gravity Tables in 2025 are read-or-edit dashboards, not data-entry forms
- The original Gravity Forms entry form is still the right place to collect new entries for most teams
- A button that does something dangerous-by-default (in the wrong context) is worse than one that does nothing
If you’re upgrading from earlier 2.3.x, your existing tables keep the previous behaviour (button visible) for backwards compatibility.
What this enabled#
This release set up the architecture for 4.0’s Thickbox modal. Once the Add New Entry button became a first-class, conditionally-rendered UI element, replacing it with a Thickbox-popped form was a clean swap. Without 2.3.2, the button rendering logic was scattered across template files in ways that made the 4.0 work harder.
A small switch with a clean implementation. Sometimes that’s the whole release note.