Table Answers Were Missing From The PDF

A table's answers were missing from the PDF

Reported by a user · Fixed in #1849 · Released in 2.3.1

---

What you saw

Somebody filled in a form with a table question - a purchase list, say, with an item, a quantity and a date on each row - submitted it, and downloaded the submission as a PDF.

The PDF showed the question's heading, ITEMS, and then nothing. The fields after it printed normally. It read exactly as though the person had skipped the table.

They had not. The rows were there the whole time.

The same submission was missing the same rows on screen and in the CSV export, for the same reason. It was reported as a PDF fault only because that is where somebody happened to look first, and a heading with a gap under it is more obviously wrong than a table you were not expecting to see.

---

What was actually wrong

A table question keeps its two halves in two different places:

• the columns - what the table asks - live in form_fields.config
• the answers - what somebody typed - live in form_submission_data.field_value

The endpoint that feeds the submissions screen selected this:

SELECT id, field_type, label, is_deleted
  FROM form_fields

No config. So the answers came back and the columns did not.

FormLogic.gridColumns() then had nothing to read and returned an empty list, and every reader laid three rows of perfectly good data out against no columns at all:

Where	What that produced
On screen	a <table> with an empty <thead> and empty rows
The PDF	autoTable called with head: [[]] - the label printed, nothing beneath it
The CSV	no cells for that field

All three failed silently. Nothing errored, nothing was logged, and the JSON response genuinely contained the answers - so anyone checking the data would have found it present and concluded the export was fine.

Why it lasted

Because the sibling endpoint was already right. FormsService::collectionSubmissions(), which feeds the collection view, selects options and config - so the very same table rendered correctly there.

🔑 Two endpoints feeding the same JavaScript different field shapes. One was complete, one was not, and the incomplete one was the one most people use. Nothing compared them.

---

How it was fixed

The endpoint selects options, config as well, which is a one-line change.

The part worth more than the fix: both endpoints now return the same field shape, rather than this one merely being made to work. The test asserts that equality directly - it checks that the submissions endpoint returns every field key the collection view gets - so the two cannot drift apart again without something saying so.

---

Files changed

File	What changed
api/forms/get_submissions.php	selects options, config, matching the collection endpoint
tests/form-submission-grid-export.php	new

---

How it was proved

• The new test builds a form with a table, submits against it, and drives the real endpoint with a forged analyst session - asserting the columns arrive, their labels are intact, and a choice column keeps its options.
• Run against the old query as a control it fails 6 of 12.
• The row-count assertion passes even in that control run, which is the detail that proves the diagnosis: the answers were never the missing half.

---

If you have older submissions

Nothing was lost and nothing needs repairing. The rows were always in the database, and they reappear as soon as you upgrade.

It is worth re-opening any submission you looked at and assumed had been left blank - on screen and in any CSV you exported, not only in a PDF.

---

See also

• Forms - what a table question is
• The approvals inbox said "Error" and nothing else - the same field type, a different reader, found the same week
• Bugs resolved