Inline editing that feels like a spreadsheet, keyboard nav + undo/redo

The biggest UX gap between Gravity Tables 4.1.20 and a real spreadsheet was both ridiculous and obvious: you had to lift your hand off the keyboard between every edit. Click a cell, type, click save, click the next cell, type, click save. For a moderation queue with 80 rows to triage, that’s 240 mouse interactions you didn’t need to perform.

These two versions close that gap. v4.1.21 added keyboard navigation; v4.1.24 added undo/redo. Together they turn inline editing into the kind of flow you’d expect from Google Sheets or Excel.

v4.1.21, Keyboard navigation for inline editing#

Four keys, four behaviours, learnable in five seconds.

Key	Action
Tab	Save current cell, move to next editable cell on this row
Shift+Tab	Save current cell, move to previous editable cell on this row
Enter	Save current cell, move down one row in the same column
Escape	Cancel the in-flight edit; revert to the original value

A small implementation detail worth flagging: the keyboard handler only fires while a cell is in edit mode. It doesn’t fight with the host page’s keyboard events when no cell is open, Tab still navigates the page normally, Cmd+S still saves the page, etc. The editor steals focus only when you’ve explicitly opened a cell, and yields it back the moment you Escape or click outside.

Why this matters#

For triage workflows, it changes the unit of effort. Before:

Click → type → click Save → mouse to next cell → click → type → click Save → …

After:

Tab to first editable cell → type → Tab → type → Tab → type → …

For a 50-row moderation queue with 4 editable columns each, that’s the difference between 400 mouse interactions and 0. The fingers never leave home row.

Accessibility#

Tab and Shift-Tab match the WAI-ARIA expected pattern for cell navigation in editable grids. Screen readers announce each cell entry by column header text (we ship aria-labelledby linking each cell to its <th>), so the keyboard flow is fully navigable without sight.

v4.1.24, Undo / Redo with Cmd+Z#

Tab-fast editing is great until you Tab into the wrong cell and overwrite something. Before this version, you had two options: re-type the original value (assuming you remembered it), or pull up the audit log to copy back the previous value.

Now: Cmd+Z. Or Ctrl+Z on Windows/Linux. The last edit reverses, on the same row, in-place.

What gets tracked#

Every successful inline edit pushes an entry onto the undo stack:

• Entry id, field id, old value, new value
• Timestamp + user id (for the audit log; the undo stack uses just the values)

The stack depth is 20. Past 20 edits in one session, the oldest entry drops off, the audit log still has it for review purposes, but you can’t undo further with Cmd+Z.

What gets reverted#

Cmd+Z reverses the cell value through the same GFAPI::update_entry_field() pipeline as the original edit. That means:

• The validation rules re-run on the reverted value (so reverting to a now-invalid state surfaces a proper error)
• Conditional logic re-evaluates
• The edit is logged in the audit table as a separate event with a is_undo: true flag, you can see that user X edited cell Y, then immediately undid it, two distinct rows in the audit trail

It’s not a delete-the-edit-from-history undo; it’s a new edit that reverses the previous one, with full traceability.

Cmd+Shift+Z to redo#

If you Cmd+Z and then change your mind, Cmd+Shift+Z restores the un-done edit. The redo stack mirrors the undo stack, also 20 deep, and clears whenever you make a fresh edit (standard behaviour for any text editor or spreadsheet).

Toast notifications#

Every undo or redo triggers a small toast in the bottom-right of the table:

↶ Undid: status was "approved", now "pending"
↷ Redid: status back to "approved"

The toast describes what changed, in plain English. After a long Tab-fast editing run, the toast is your protection against accidentally Cmd+Z-ing the wrong direction, you see exactly what changed.

Toolbar buttons too#

For mouse-and-trackpad users, the table toolbar gets two new buttons: Undo and Redo, with the same Cmd+Z / Cmd+Shift+Z shortcuts shown in their tooltips. Both gray out when their stack is empty.

What this combines into#

Take a moderation queue with 50 pending entries, 4 editable columns, an audit log on, and a sales lead reviewing them after lunch. The flow:

1. Open /admin/queue (autorefresh keeps it current)
2. Tab to the first editable cell
3. Type the new value, Tab to the next column or Enter to drop down a row
4. Hit a wrong cell? Cmd+Z. Toast confirms what reverted.
5. Repeat. The whole queue takes minutes instead of half an hour.

The keystrokes match what the lead already knows from Excel and Google Sheets, with one exception (Enter goes down, not “out of edit mode”, closer to Excel than Google Sheets). The audit log captures every keystroke that mattered. The mouse stays parked.

Upgrade path#

Both features ship enabled by default with no configuration. There is no opt-in flag to flip, no shortcode parameter to add. If you upgrade to 4.1.24+, your existing tables get keyboard nav + undo/redo immediately.

If you’ve built custom JavaScript that listens for keyboard events while a Gravity Tables cell is open, the new handler may conflict, see the JavaScript events doc for the events to listen on and the order they fire.

Related#

• Add inline editing to Gravity Forms (guide), the editing primitive these features sit on top of
• Build a moderation queue (guide), the workflow these features were designed for
• Build a CRM lead dashboard (guide), another high-volume editing workflow
• JavaScript events, for custom integrations on edit / undo / redo
• Permissions, keyboard nav respects every layer of the permission model