FOUR-32638: Fix Collection record list fields and values

[eiresendez]

Issue & Reproduction Steps

Collection-backed Record Lists regressed after the Collection schema was introduced as the source for available fields.

To reproduce:

1. Import the Collection and Screen fixtures attached to FOUR-32640, or create a Collection with records and configure a Screen Record List to use it.
2. Open the Record List Columns inspector.
3. Add a column and verify that the Collection record id field is missing.
4. Select All columns and inspect the generated configuration.
5. Notice that content and key use the data. prefix.
6. Open Preview and notice that the configured headers are displayed but the record values are empty.

The exported fixtures remain attached to Jira and are not included in this repository.

Solution

• Add a shared Collection field utility that uses the Collection schema as the primary source, removes only the leading data. prefix, deduplicates fields, always includes id, and falls back to the first record when no schema is available.
• Use the normalized fields in the Record List column and single-field selectors.
• Generate flat content and key values for individual fields and All columns.
• Normalize legacy data.* configurations while rendering so existing Screens display their values without rewriting their saved configuration.
• Map Collection records without mutating the API response.
• Add focused unit and Cypress coverage for schema fields, id, flat keys, empty Collections, fallback behavior, Preview values, and legacy configurations.

How to Test

Run:

• npx jest tests/unit/CollectionFieldUtils.spec.js --runInBand --no-coverage
• npm run run-cypress -- --spec tests/e2e/specs/CollectionRecordListColumns.spec.js --browser electron
• npm run build

Manual validation:

1. Configure a Record List with a Collection source.
2. Open the Columns selector and confirm that id and the complete Collection schema are available without data. prefixes.
3. Select All columns and confirm the generated content and key values are flat.
4. Open Preview and confirm that headers and record values are displayed.
5. Load an existing Screen whose column configuration uses data.* and confirm it renders correctly without automatically rewriting the saved configuration.

Related Tickets & Packages

• https://processmaker.atlassian.net/browse/FOUR-32638
• https://processmaker.atlassian.net/browse/FOUR-32640
• https://processmaker.atlassian.net/browse/FOUR-30436
• https://processmaker.atlassian.net/browse/FOUR-32599
• https://github.com/ProcessMaker/package-collections/pull/488

ci:deploy

[eiresendez]

Solution:

[cypress]

screen-builder    Run #2339

Run Properties:   Failed #2339  •  d89c8b2f5a: FOUR-32638: Fix Collection record list fields and values

Project	screen-builder
Branch Review	task/FOUR-32638-FOUR-32640
Run status	Failed #2339
Run duration	20m 57s
Commit	d89c8b2f5a: FOUR-32638: Fix Collection record list fields and values
Committer	Eleazar Resendez
View all properties for this run ↗︎

---

Test results
Failures	1
Flaky	0
Pending	19
Skipped	0
Passing	391
View all changes introduced in this branch ↗︎

---

Tests for review

  tests/e2e/specs/FileDownload.spec.js • 1 failed test • CI - Chrome

View Output

Test		Artifacts
File Download > Can download a single file		Test Replay Screenshots

[nolanpro]

QA server K8S was successfully deployed https://ci-7971945b20.engk8s.processmaker.net

[eiresendez]

@nolanpro @sanjacornelius could you please help assign a reviewer to this PR?

The remaining CI failures are unrelated—a flaky FileDownload test and a Cypress parallel-run Chrome 150/151 environment mismatch.

[CarliPinell]

One Important observation about Collection record id mapping in Preview.

[CarliPinell]

mapCollectionRecordData only reads keys from column.data, but Collection API records expose the system id on the parent object ({ id, data: { ...fields } }), not inside data. After this PR always offers id as a column, Preview/table cells for that column stay empty for real Collection payloads.

The Cypress fixture masks this by putting id inside data ({ id: recordData.id, data: recordData } where recordData also contains id).

Impact: Users can select the id column (or All columns including id), but Preview and runtime Record Lists will show blank id values against real /collections/{id}/records responses.

Suggested Fix: Before mapping, merge the record-level id into the payload, e.g. mapCollectionRecordData({ ...(column.data || {}), ...(column.id != null ? { id: column.id } : {}) }, optionsList). Also update the Cypress intercept so data does not include id, and assert Preview still renders the parent record id.

[eiresendez]

@CarliPinell Thanks for flagging this.

I verified the current Collection API contract: CollectionsApiCollection explicitly copies the parent record ID into data.id before returning records (source). I also confirmed that a real /api/1.0/collections/2/records response contains matching IDs at both record.id and record.data.id, so the Cypress fixture mirrors the production payload and Preview can map id from column.data. Could you share the endpoint or payload where id exists only on the parent? If that shape exists, I can add compatibility coverage; otherwise, no code change should be needed here.

[CarliPinell]

Nice! thanks.