RCA: VA forms are incorrectly showing up in VBA and VACO sections

[kevwalsh]

Describe the defect

Certain Section listings are showing certain content that they shouldn't.

Content Manager views built based on Section permissions are showing content with a different Section. e.g. VBA section view is showing Forms content with the Octo Section.

User story

As an editor I want to see only content that I can edit, in my editor views so that I don't mess with things I can't / shouldn't touch.

To Reproduce

Steps to reproduce the behavior:

1. Go to VBA
2. See Forms listed
3. Go to VACO
4. See Forms listed

For a specific example form:

1. Go to VBA, Filter by Content Type = VA Form
2. Click through to a listed Form, e.g. https://prod.cms.va.gov/node/5714/edit
3. Under Section, see Section is OCTO > Sitewide > Forms

Screenshots

Forms appear in VBA section

Section listed on example form

Additional context

Not sure if this Forms specific, or a canary for something else that's going on.

When we import from Forms DB, we receive/set a "Form Administration" field that corresponds to the area where these forms are appearing for VBA / VACO. That could be implicated somehow.

ACs

• [ ] Root cause analysis
• [ ] Determine path forward and cut new ticket

CMS Team

Please check the team(s) that will do this work.

• [ ] CMS Team
• [X] Public Websites
• [ ] Facilities
• [ ] User support

[msbtterswrth]

I found this related d.o issue. Doesn't seem to be a d8 patch for this issue yet.

[swirtSJW]

Raised this with module maintainers here https://civicactions.slack.com/archives/C0ASJ7C8P/p1655313649513379

[swirtSJW]

Sadly they are both foggy on the issue. So we will have to contribute a patch.

[EWashb]

@jilladams PW has forms, right? I would like to remove our label and add to your backlog

[jilladams]

Good call, updated - fyi @wesrowe . This was previously refined and points added, but PW should review scope and confirm estimate. Moving back to "Needs refining."

[wesrowe]

Assigned to @dsasser for pre-refinement review.

[jilladams]

Suspicion: The forms that are appearing incorrectly in these views have that Administration assigned as the Form Administration, from the Forms DB CSV import. I think this may be implicated.

Example:

• VBA content manager view: https://prod.cms.va.gov/section/vba
• Shows Form 21P-0571: https://prod.cms.va.gov/node/6089/edit
• Which has Form Administration = VBA set

Backend Refinement:

• This is where in the code we map the Forms DB Form Administration to a Taxonomy term: https://github.com/department-of-veterans-affairs/va.gov-cms/blob/main/docroot/modules/custom/va_gov_migrate/config/install/migrate_plus.migration.va_node_form.yml
  • Investigation should start with how those terms / vocabularies line up with Sections (or don't), to see if this has anything to do with it

Keeping the 5 estimate (more than a day, less than a week), and can timebox the effort to root cause.

Pulling into sprint for @chri5tia since she has capacity. Goal is to get to root cause and then double check if 5 sufficient for the fix as well.

[jilladams]

Ticket was added to sprint opportunistically. However, #12731 is a new ticket with higher priority re: quarterly goals, so: ejecting this, pulling that one in instead.

[wesrowe]

@jilladams, we're pulling this into sprint 79 opportunistically.

[dsasser]

Root cause analysis:

VA Forms have two "administration" fields:

1. "Form Administration" a. Machine name: field_va_form_administration b. Field type: entity_reference. c. Referencing "Section" taxonomy terms (parents only, using entity reference selection View administration_section)
2. "Section" a. Machine name: field_administration b. Field type: entity_reference c. Referencing "Section" taxonomy terms. Statically set to term id 196 (OCTO -> Sitewide content team -> Forms) for all forms

What this reveals is that VA Forms content has two entity reference fields which map to the same Vocabulary: Sections.

In the View controlling the display of section content (eg: /section/vba), a contextual filter (an argument to the query) is being added which joins data from the taxonomy_entity_index database table. This table collects mappings from entities (nodes in this case) to taxonomy terms. Because we are mapping two fields to the same Vocabulary in VA Forms, there will always be two entries for each of the form nodes:

Due to the query settings for the View (distinct, and aggregated), only one result is displayed for each node, which has a side-effect of masking the underlying problem.

Possible solutions (in no particular order)

1. Don't use an entity_reference field for "Form Administration" - XL (5-8ish points, more fragile, FE work, VA Forms query would need work)

This solution would essentially be to replace the existing 'field_va_form_administration' field, which is an entity reference field, with some other type of field that doesn't reference the same Section vocabulary as the 'field_administration' field.

One type of field we could use is a 'List (select)' field. In this scenario, the select list would be populated with a copy of the root level Section terms. Because it isn't an entity reference field, the taxonomy tables used in the View would not return two instances for the same node.

Side effects with this approach:

• Field name could change, which would cause any GraphQL queries using the old field name to break. This means the query Lighthouse uses to populate the Forms API would need to be altered. Further complicating this is the fact that, graphQL will return the 'key' of the value, rather than the 'label'. For our example node, 5714, this would result in the value '1' to be returned from GraphQL, rather than the expected 'VBA'.
• Forms audit views would need to be updated to replace the field and any related filters.
• A migration from old field -> new field would need to be written.
• Keeping parity between the select field and the Section parent terms would need to be handled. This could be done in an allowed_values_function callback.

2. Views query alter - M (3ish points)

Performing a Views query alter to limit results using a field name. This would alter the query by filtering on the 'taxonomy_entity_index.field_name' column, limiting results to results with the fieldname 'field_administration' (or excluding fields with the name 'field_va_form_administration'.

Side effects with this approach:

• "hides" logic, making it more difficult to troubleshoot in the future.
• Introduces tech debt.
• Is rather "fast" to develop, in terms of the other options.

3. Views filter - Large (5ish points, but: less tech debt)

Ideally, we could filter out certain fields from the section listings by way of configuration in Views. This would require one of several possible solutions, including either adding a field filter (no such filter is provided by the taxonomy_entity_index module), enhancing the existing argument code to do such filtering (probably not recommended as this would also hide the filtering logic)

Side effects with this approach:

• It might be the most difficult/time consuming to write
• It can be committed back to the community as a patch to the taxonomy_entity_index module.
• No hiding of the logic
• Doesn't affect any other content types
• No assumed tech debt

We can then upstream these changes to the module, for the community.

[jilladams]

Backend refinement:

• Also discussed: could we swap the taxonomy field to just be a list field with the same machine name. Have to provide a key/value pair, and GraphQL just wants to send a key. Has a GraphQL impact, and Lighthouse impact. So no.

So: Option 3 wins. This ticketed converted to an RCA issue,and we'll file a new ticket for the fix, due to sprint boundary.