Strange Node View behavior for optional segments on CLP that have been enabled and then disabled

[davidmpickett]

Statuses

[2024-09-12] [Fran] Decision log added identifying Option 1 as the desired solution; AC added; moved to the bottom of Next Refinement.

Background

This came up during Q&A for #18954 and was deemed out of scope.

Note that there are two distinct, but related related errors you might encounter while reproducing this issue

• Confusing error message when disabling the Stories panel on a CLP #19161
• Links with summaries field in Spotlight section of CLP does not indicate it is required #19163

Reproduction steps

1. Go to staging.cms.va.gov (or a Tugboat)
2. Create a new Campaign Landing Page
   • Only fill in the required fields in the Hero banner, Why this matters, What you can do, and VA benefits sections
   • Save the node
   • Validate that the Node View matches the fields populated on Node Edit
3. Edit the node and add an optional section
   • Enable one of the following optional sections, Video, Spotlight, Stories, Downloadable resources, Events, FAQs
   • Fill out required fields for the optional section
   • Save the node
   • Validate that the Node View updates with the new section
4. Edit the node and disable the optional section
   • Uncheck the "Enable this page segment" box on the section you just added
   • Save the node
   • Notice that Node View still shows the content from the subfields of the section you disabled

Possible solution paths

Option 1

• We should clear out any content entered the sub-fields (on Save?) if the enabled box is unchecked
• Consider the Banner alert fieldset on VBA Facility content type. It clears out all content in sub-fields once the "Display a banner alert on this facility box" is unchecked and the node is saved.

Option 2

• Keep the content but hide it on Node View?

Decision Log

Option 1 will be implemented, mimicking existing CMS functionality (e.g. Events).

Acceptance Criteria

• Editing a Campaign Landing Page that has one or more optional sections enabled (e.g. Video, Spotlight, Stories, Downloadable resources, Events, FAQsA) by unchecking an optional section results in clearing out the previously entered content (mimicking current behavior in CMS e.g. events)
• When creating a Campaign Landing Page with one or more optional sections enabled, and during creation an optional section is unchecked, the content is cleared out. (mimicking current behavior in CMS e.g. events)

[FranECross]

@davidmpickett @dsasser I'm looking at the options and thinking #2 would be a good solution, IF we have situations where an editor might follow the following scenario when entering information: They enter information into a CLP that they want to publish right away, but info they enter into a sub-field they want to get further approval on. They uncheck the box so it doesn't display, but they don't want their information to be cleared out because when they get approval, they will then edit, uncheck the box so that it WILL display, and then republish. Thoughts on feasibility and effort?

[dsasser]

In other areas of the CMS, Events for instance, we clear the data from fields that are hidden when making form selections.

They enter information into a CLP that they want to publish right away, but info they enter into a sub-field they want to get further approval on. They uncheck the box so it doesn't display, but they don't want their information to be cleared out because when they get approval, they will then edit, uncheck the box so that it WILL display, and then republish. Thoughts on feasibility and effort?

I would use a node revision in this case. Here the user would create the publish-able version and publish it. Then create a draft of the new changes that need approval.

In my opinion we should (always?) be clearing data when it is hidden dynamically.

[davidmpickett]

I agree with @dsasser that option 1 / clearing out the data is generally the more robust/performant option with dynamically hidden fields. It prevents weird validation glitches like #19161. It's also an established pattern within the CMS so would be relatively straightforward to implement.

Option 2 would be a whole new paradigm and would in someways us fighting against the grain to accommodate a small, hypothetical use case

There's also Option 0, which is to leave it as is. This is not breaking any functionality, just leading to possible confusion.