Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In support of #13188, audit all instances of paragraphs and usage of Beneficiaries field #15743

Closed
3 tasks done
Tracked by #15742
FranECross opened this issue Oct 19, 2023 · 10 comments
Closed
3 tasks done
Tracked by #15742
Assignees
Labels
Public Websites Scrum team in the Sitewide crew Resources and support CMS managed product owned by Public Websites team sitewide VA.gov frontend CMS team practice area

Comments

@FranECross
Copy link

FranECross commented Oct 19, 2023

Description

User story

Describe the audience/user, enhancement or fix, and value / outcome desired.

AS A Product Owner/Manager
I WANT to know what will be affected if we add the ability to add multiple Beneficiary types to a Resources & Support article
SO THAT we know the true scope of the work to determine whether or not to do the work.

Engineering notes / background

This is a Taxonomy, used in a Paragraph on R&S.
We can control the cardinality within a Paragraph, so anywhere the Paragraph is used will be affected.
See #13188

Collaboration

Front end/back end will need to collaborate on this ticket to ensure all is taken into consideration. See Engineering notes on the linked ticket.

Analytics considerations

Quality / testing notes

Acceptance criteria

  • Audit paragraphs and instances of Beneficiaries usage and assess impact in FE templates, including CLP and 6 other types listed above
  • Document impact of changing cardinality from one to many, and front end effort
  • Ensure R&S Editor UX allows multiple Beneficiaries per article #13188 reflects the findings and next steps
@FranECross FranECross added Needs refining Issue status Public Websites Scrum team in the Sitewide crew labels Oct 19, 2023
@jilladams jilladams changed the title In support of #13188, audit all instances of paragraphs and usage of In support of #13188, audit all instances of paragraphs and usage of Beneficiaries field Oct 19, 2023
@jilladams jilladams added Drupal engineering CMS team practice area Resources and support CMS managed product owned by Public Websites team and removed Needs refining Issue status labels Oct 19, 2023
@jilladams jilladams added VA.gov frontend CMS team practice area and removed Drupal engineering CMS team practice area labels Nov 2, 2023
@dsasser
Copy link
Contributor

dsasser commented Nov 2, 2023

the fieldTags field is showing up in the following places in content-build:

35 results - 18 files

src/site/filters/liquid.js:
  797  
  798  
  799:   liquid.filters.getTagsList = fieldTags => {

  799      const {
  800      const {

  804        },
  805        },
  806:     } = fieldTags;
  806  
  807  

src/site/filters/liquid.unit.spec.js:
  914  describe('getTagsList', () => {
  915  describe('getTagsList', () => {
  916:   const fieldTags = {

  916      entity: {
  917      entity: {

  947    it('forms a sorted list from properties "fieldTopics", "fieldAudienceBeneficiares", and "fieldNonBeneficiares"', () => {
  948    it('forms a sorted list from properties "fieldTopics", "fieldAudienceBeneficiares", and "fieldNonBeneficiares"', () => {
  949:     const result = liquid.filters.getTagsList(fieldTags);

  949  
  950  

  974    it('omits null poperties', () => {
  975    it('omits null poperties', () => {
  976:     const fieldTags2 = { entity: { ...fieldTags.entity } };
  977:     fieldTags2.entity.fieldAudienceBeneficiares = null;

  977  
  978  
  979:     const result = liquid.filters.getTagsList(fieldTags2);
  979  
  980  

src/site/includes/tags.drupal.liquid:
   1: {% if fieldTags.entity != empty %}

   1    <div
   2    <div

  10        <div class="vads-u-display--flex vads-u-flex-wrap--wrap">
  11        <div class="vads-u-display--flex vads-u-flex-wrap--wrap">
  12:         {% assign tags = fieldTags | getTagsList %}
  12  
  13  

src/site/layouts/checklist.drupal.liquid:
  87            <!-- Tags -->
  88:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  89  

src/site/layouts/faq_multiple_q_a.drupal.liquid:
  128            <!-- Tags -->
  129:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  130  

src/site/layouts/media_list_images.drupal.liquid:
  174            <!-- Tags -->
  175:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  176  

src/site/layouts/media_list_videos.drupal.liquid:
  90            <!-- Tags -->
  91:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  92  

src/site/layouts/q_a.drupal.liquid:
  40            <!-- Tags -->
  41:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  42  

src/site/layouts/step_by_step.drupal.liquid:
  100            <!-- Tags -->
  101            <!-- Tags -->
  102:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  102  
  103  

src/site/layouts/support_resources_detail_page.drupal.liquid:
  74            <!-- Tags -->
  75            <!-- Tags -->
  76:           {% include "src/site/includes/tags.drupal.liquid" with fieldTags = fieldTags %}
  76  
  77  

src/site/stages/build/drupal/graphql/faqMultipleQa.graphql.js:
  89    }
  90:   fieldTags {
  91      entity {

src/site/stages/build/drupal/graphql/nodeChecklist.graphql.js:
  77    }
  78:   fieldTags {
  79      entity {

src/site/stages/build/drupal/graphql/nodeMediaListImages.graphql.js:
  82    }
  83:   fieldTags {
  84      entity {

src/site/stages/build/drupal/graphql/nodeMediaListVideos.graphql.js:
  86    }
  87:   fieldTags {
  88      entity {

src/site/stages/build/drupal/graphql/nodeQa.graphql.js:
  67    }
  68:   fieldTags {
  69      entity {

src/site/stages/build/drupal/graphql/nodeStepByStep.graphql.js:
  96    }
  97:   fieldTags {
  98      entity {

src/site/stages/build/drupal/graphql/nodeSupportResourcesDetailPage.graphql.js:
  81    }
  82    }
  83:   fieldTags {
  83      entity {
  84      entity {

src/site/stages/build/plugins/create-resources-and-support-section.js:
   59    const articleListingsByTag = {};
   60    const articleListingsByTag = {};
   61:   const allTaggedArticles = allArticles.filter(a => !!a.fieldTags);

   61  
   62  
   63      const {
   64      const {
   65:       fieldTags: {

   65          entity: {
   66          entity: {

  413      fieldPrimaryCategory: article.fieldPrimaryCategory,
  414      fieldPrimaryCategory: article.fieldPrimaryCategory,
  415:     fieldTags: article.fieldTags,
  415      searchableContent: deriveSearchableContent(article),
  416      searchableContent: deriveSearchableContent(article),

@dsasser
Copy link
Contributor

dsasser commented Nov 2, 2023

Uses of fieldAudienceBeneficiares

9 results - 4 files

src/site/filters/liquid.js:
  801          fieldTopics = [],
  802          fieldTopics = [],
  803:         fieldAudienceBeneficiares,

  803          fieldNonBeneficiares,
  804          fieldNonBeneficiares,

  812      const audiences = [
  813      const audiences = [
  814:       fieldAudienceBeneficiares?.entity,
  814        fieldNonBeneficiares?.entity,
  815        fieldNonBeneficiares?.entity,

src/site/filters/liquid.unit.spec.js:
  933        ],
  934        ],
  935:       fieldAudienceBeneficiares: {

  935          entity: {
  936          entity: {

  946  
  947  
  948:   it('forms a sorted list from properties "fieldTopics", "fieldAudienceBeneficiares", and "fieldNonBeneficiares"', () => {

  948      const result = liquid.filters.getTagsList(fieldTags);
  949      const result = liquid.filters.getTagsList(fieldTags);

  975      const fieldTags2 = { entity: { ...fieldTags.entity } };
  976      const fieldTags2 = { entity: { ...fieldTags.entity } };
  977:     fieldTags2.entity.fieldAudienceBeneficiares = null;
  977  
  978  

src/site/stages/build/drupal/graphql/paragraph-fragments/audienceTopics.paragraph.graphql.js:
  2  fragment audienceTopics on ParagraphAudienceTopics {
  3:   fieldAudienceBeneficiares {
  4      entity {

src/site/stages/build/plugins/create-resources-and-support-section.js:
  66            fieldTopics,
  67            fieldTopics,
  68:           fieldAudienceBeneficiares,

  68            fieldNonBeneficiares,
  69            fieldNonBeneficiares,

  74  
  75  
  76:     if (fieldAudienceBeneficiares) {
  77:       terms.push(fieldAudienceBeneficiares);
  77      }
  78      }

@randimays randimays self-assigned this Nov 3, 2023
@randimays
Copy link
Contributor

I've been trying to create a Tugboat to add the 4 not-really-used content types (image list, video list, checklist, step-by-step) and confirm how they are rendering. It seems like the main branch in Tugboat is out-of-date and needs to be rebuilt, which will take about an hour and 15 minutes, then I need to create a new Tugboat, add some content and rebuild. Hopefully I'll be able to wrap this research up today but I am about 50% sure it's going to carry over.

@randimays
Copy link
Contributor

randimays commented Nov 8, 2023

@jilladams @FranECross @dsasser Please review my findings below. If this seems complete / comprehensive, I'll add these findings to #13188.

Findings:

The most likely places for code changes are liquid.js (getTagsList) and create-resources-and-support-section.js. There are many places this logic needs to be validated listed below.

Typical Tag Usage

tags.drupal.liquid
This file uses liquid.js to build a list of tags from the Drupal data. It already handles looping through an array. It does not appear changes are necessary here.

liquid.js (getTagsList)
It appears this function is built to handle one item of a Beneficiary Audience and one item of a Non-Beneficiary Audience. The changes we'd need to make are here to account for an array of Beneficiary Audiences versus a single object. This file also has unit tests that need to be updated.

Testing Typical Tag Usage in a Tugboat Instance

The following all rely on tags.drupal.liquid to format their tag data. Validate the files below with their testing instructions.

Outlying Tag Usage

The following are not using tags.drupal.liquid. They are used to group Resources & Support articles by tag for searching when the "Browse by audience" section is included on the R&S home page.

Testing Outlying Tag Usage in a Tugboat Instance

  • browse_by_audience.drupal.liquid: add a content block in the /resources page in the CMS with the section header "Browse by audience." This will create a section on the page with tag-grouped articles
  • page.js: this file facilitates browse_by_audience.drupal.liquid. It appears to already support multiple audience tags. It will be apparent this isn't working if the above testing steps do not have a good outcome
  • create-resources-and-support-section.js: this file has a function (groupByTags) that helps create the child pages in the "Browse by audience" section on the Resources & Support landing page. Need to validate these pages are still produced correctly. It seems like the logic will handle multiple tags per page but not 100% certain

"Browse by audience" section in Resources & Support

Screenshot 2023-11-08 at 9 32 26 AM

Example of these child pages being created in the build

Screenshot 2023-11-08 at 9 59 45 AM

Visual of a child page

Screenshot 2023-11-08 at 10 00 21 AM

@jilladams
Copy link
Contributor

@randimays I think this makes sense but want to clarify: for all the cases where your notes use present tense related to a file, e.g. "add a content block" or "create a Checklist", are you indicating what that file is currently doing in prod, or are you suggesting additions / changes to those files?

If you mean: this is what the file currently does, then I'm tracking. #13188 will track the Drupal change to make the field a multi-select, so your notes will become the FE implementation ticket that will follow it. (Where we will need to verify everything in a Tugboat, prior to shipping either BE or FE changes.)

If we're on the same page, could update the AC here to be to create that FE ticket, and if you're willing, go for it, or @FranECross or I can help if you'd rather - just holler.

@randimays
Copy link
Contributor

@jilladams I was referring to how to test it in a Tugboat instance for the purposes of validating these findings (since we do not have examples of the checklist / step-by-step / image list / video list in prod). I added some clarity to the language there. But of course, it will also be the way we validate the FE changes once the CMS changes are made.

@FranECross I added a new ticket for the front end implementation.

@dsasser
Copy link
Contributor

dsasser commented Nov 13, 2023

@randimays

re:

Please review my findings below. If this seems complete / comprehensive, I'll add these findings to #13188.

The findings look complete and very comprehensive, great work!

@randimays
Copy link
Contributor

Thanks @dsasser!

@jilladams @FranECross anything else we need here before closing?

Confirming:

@FranECross
Copy link
Author

@randimays Nothing else needed. Thank you! cc @jilladams

@randimays
Copy link
Contributor

Completed AC and made new ticket for FE work. Closing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Public Websites Scrum team in the Sitewide crew Resources and support CMS managed product owned by Public Websites team sitewide VA.gov frontend CMS team practice area
Projects
None yet
Development

No branches or pull requests

4 participants