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

[jilladams]

Status

[2024-09-30] [Fran] Approved to implement; not urgent.
[2024-08-19] [Fran] This doesn't take priority over any quarterly goal work, or defects, but is at the bottom of the Ready column on the slight chance we ever are light on work for some reason.

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. At this time, the editors can't actually edit them, but we should address this to reduce confusion and also in case in future they are able to edit but shouldn't.

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 Editor dashboard
2. See Forms listed
3. Go to VACO Editor dashboard
4. See Forms listed

For a specific example form:

1. Go to VBA Editor dashboard, 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

Root cause analysis: #9469 (comment)

Preferred fix: 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.

Test case
On Facilities, Field Office & Field Administration behave in a similar fashion. Editing a Facility's Field Office value to something other than the Section on the same node, will cause that Facility to appear in two different sections.

ACs

• Forms are not listed in VACO or VBA Editor views.
• Forms Section remains OCTO > Sitewide.
• Verified using the Facility test case.
• Upstreamed the change as a patch to the module, rather than custom code

CMS Team

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

• CMS Team
• Public Websites
• Facilities
• User support

[chri5tia]

I am not clear how/who assigns the section in the first place. This would help me understand the whole workflow and architecture before adding the filter programmatically.

[dsasser]

VA Forms are created by the migration config migrate_plus.migration.va_node_form.yml in va_gov_migrate. Both the fields, field_administration and field_va_form_administration, are defined in this migration config, and get their values from this migration.

[chri5tia]

Solution to edit the taxonomy view should be a simple as adding a relationship for the field_va_form_administration field, then adding a context for the same. If this taxonomy view was used as a page (page is disabled, it's a block somehow), the context for the field to exclude should be configured to "provide default value" using "Content ID from URL". Under validation, there should be an option for Content and somewhere more stuff to choose from, should be able to select "Exclude". That context using the ID in the URL might still work.

But, this exclusion basically ended up invalidating the entire query. Still trying to figure out how to exclude the field and how the filter could be created at the contrib module level.

If we want to filter out field_va_form_administration from the taxonomy index entity table then what is the point of putting it there in the first place e.g. why are we using it as an entity? Daniel described this in solution 2, which I'm starting to really think about.

[FranECross]

@jilladams I see that Christia was working on this, or at least looking into it, but then it was put back in backlog or maybe icebox. Do you remember if a decision was made not to address it, or perhaps it's not causing much of an issue with editors? I ran across it when I was going through epics to see if any could be closed. Thanks!

[jilladams]

This has always been sort of lingering in the backlog -- it's something we could do, but DaveC never felt it was high value enough to prioritize over other work.

[jv-agile6]

Mid-Sprint Update

Today I was able to move #19163 to QA and #12933 to in-progress. This is a five point ticket which might carry some risk for completion before end of sprint.

[jilladams]

When this is picked up, double check the truthiness of notes here: #9469 (comment)

[dsasser]

Confirmed that option 3 in the RCA is still the best way forward and will be working to implement this and contribute it back to the community. I would say 5 points at least is going to be involved. Noting also that the authors of the module don't appear to be active, so a contribution is unlikely to be folded into a new version unless that changes. Still worth putting it out there though.

[dsasser]

Status update:

This work is in PR, and the solution has been contributed back to the community. The PR's Tugboat instance is failing cypress tests that I'm currently looking into. I suspect it is just a flakey test.

[dsasser]

This has been merged.

[dsasser]

Verified in prod: