Skip to content

Conversation

@ronnyReliefapp
Copy link

Description

Backend support for display-only resources grids in SurveyJS forms. This feature allows forms to display previous form data without storing the display-only questions as database fields.

The fix prevents validation errors when saving forms with display-only resources questions that don't have a relatedName property, as these questions are meant only for display purposes and should not be persisted.

Useful links

Type of change

  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Test A: Add display-only resources question

  • Created a new form in the form builder
  • Added a resources question
  • Selected a resource and display field
  • Checked the "Display only" checkbox (in general category)
  • Verified that "Related Name" field is hidden when display-only is enabled
  • Saved the form successfully without relatedName validation error

Test B: Display-only grid rendering

  • Enabled "Display As Grid" option on the display-only resources question
  • Configured grid fields settings
  • Previewed the form
  • Verified that the grid displays resource records
  • Confirmed that no "Search" or "Add" buttons appear
  • Verified that the grid is read-only (no selection checkboxes)

Test C: Form submission

  • Filled out a form with a display-only resources question
  • Submitted the form
  • Verified that display-only question data is NOT saved to the database
  • Confirmed other form fields save correctly

Screenshots

N/A

Checklist:

( * == Mandatory )

  • - I have set myself as assignee of the pull request
  • - My code follows the style guidelines of this project
  • - Linting does not generate new warnings
  • - I have performed a self-review of my own code
  • - I have put the ticket for review, adding the oort-backend team to the list of reviewers
  • - I have commented my code, particularly in hard-to-understand areas
  • - I have put JSDoc comment in all required places
  • - My changes generate no new warnings
  • - I have included screenshots describing my changes if relevant
  • - I have selected labels in the Pull Request, according to the changes with code brings
  • I have made corresponding changes to the documentation ( if required )
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

More explanation

https://www.loom.com/share/05a716d61b9744faaf51fb304c21d1e5?sid=f87cf896-582a-4f76-93ae-8ceed801b145

if (element.type === 'panel') {
await extractFields(element, fields, core);
} else {
if (element.type === 'resources' && element.displayOnly) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use guard clauses to handle special cases first

await extractFields(element, fields, core);
} else {
if (element.type === 'resources' && element.displayOnly) {
// Don't store as field if question is display only

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no comments

Copy link

@marianorelief marianorelief left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some comments

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Still Missing TypeScript types
  • All parameters are implicit 'any'
  1. Potential null reference errors
  • Line 73: element.items.map() - no check if items exists
  • Line 84: element.rows.map() - no check if rows exists
  • Line 90: element.columns.map() - no check if columns exists
  • Line 144: element.choices.map() - no check if choices exists
  • Line 188: element.choices.map() - no check if choices exists
  • Use element.items?.map() ?? [] or validate before mapping
  1. Still Missing displayOnly validation
  2. DRY

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marianorelief I agree with your comment, thus it's a bit out of scope as the method was already there before Ronny worked on it, that's why he didn't do typing I think

I'll keep this PR active but won't merge it now because it should be good to do a bit more testing to prevent unexpected issue to raise due to type validation

I'll create another PR, with a simplified version of the code to go faster as we have tight deadline incoming

cc @ronnyCapriles

@AntoineRelief AntoineRelief added the icebox On hold label Jan 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

icebox On hold

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants