BE: Events: Add "national outreach calendar" checkbox to Event UI

[jilladams]

STATUS

• design done in CMS Design: Enable Facility Editors to publish events to the National Outreach Calendar #14788
• need to form change management plan (if any) prior to implementation (ask DaveC at 9/25 product sync)

Description

User story

AS AN Outreach Events editor (and only outreach events editor)
I WANT my event to get posted on the Outreach Events calendar by default (without any specific input from me)
SO THAT I don't have any new cognitive load added.

AS AN Editor who can create events for a Facility
I WANT to be given the option of publishing to the Outreach Events calendar (i.e. "national" calendar) in addition to my usual options
SO THAT I can easily expose an event with broad appeal and remote accessibility to all Veterans.

Notes / background

Current Event creation form:
https://prod.cms.va.gov/node/add/event

Design
Figma file

Tasks

• Create checkbox field (non-required)
• BE processing to add Event to outreach hub cal – OE Cal is a specific node, an Event List: https://prod.cms.va.gov/outreach-and-events/events
  • "spike" chunk of work needed to figure out how Event Lists get turned into calendars on the FE
• Inspect FE template to ensure it can handle an event that's assigned to multiple Event Lists
• Implement hiding logic for select users

Acceptance Criteria

• Implementation of checkbox follows Figma design above
• On Event edit UI, any Facility Editor can check a box to also publish to the Outreach events calendar
• For an Editor whose only section is the Outreach Hub, the checkbox is hidden
• On Save with the checkbox selected, the Event is added to the selected facility and to the Outreach calendar
• DO NOT MERGE until validated that Drupal changes A) successfully publish to the Outreach calendar and B) doesn't break anything else on FE
  • Ticket FE changes needed to pick up the change
  • Ticket merging the PR if it should not merge until after FE work is complete
• Feature is behind a feature toggle
• Appropriate test(s) added
• Requires design review
• Requires PM review
• Requires a11y review

[wesrowe]

BE refinement:

• What do the role/permissions/section-assigments look like for this "outreach-only editor"?
  • We think Tim Hudak is a good example
  • Confirm with DaveC

[jilladams]

How Events get associated with Listings:

• Reverse entity lookup: https://prod.cms.va.gov/admin/reports/content-model/fields?field_name=field_listing&field_type=&entity_type=&bundle=event&label=
• On the Event, currently, an Editor selects the appropriate list from "Where should the event be listed?" (edit-field-listing).
• event_list graph QL query includes a reverse entity reference lookup for all events that point to the list page.

[jilladams]

Noting from planning:

• Checkbox needs to map to the Listing selection, for the sake of FE, and we need to make that work with custom code or figure out for sure if/how it can
  • We still think execution / figuring this out can happen with in the 8pts
• Christia to ride along for learning

[thejordanwood]

@dsasser If the checkbox ends up being too tricky, I added an alternative design idea in the Figma file. This uses a multiselect modal similar to the benefit hub section in the Video List content type.

[dsasser]

Status Update 9/29/23

Frontend

We unpacked how the FE is building event listings in content-build. The FE uses a graphql query, similar to the below abbreviated Graphql query to pull all events, grouped by event listing. The query shows how the data is being fetched by the FE, which is done by reverse entity referencing the field_listing field. Ultimately, we need to be adding additional values to this field, rather than adding a separate data source/field for the Outreach calendar, in order to avoid necessitating FE changes.

Graphql for building event listings

This graphql query is for a single 'event_list' (The National Outreach Calendar) for ease of testing:

query MyQuery {
  nodeQuery(
        limit: 1000
        offset: 0
        sort: { field: "nid", direction:  ASC }
        filter: {
        conditions: [
          { field: "status", value: ["1"], enabled: true },
          { field: "type", value: ["event_listing"] },
          { field: "nid", value:"736"}
        ]
    
      })
  {
    count
        entities {
          ... on NodeEventListing {
            entityId
            entityLabel
            reverseFieldListingNode(limit: 50, filter: { conditions: [{ field: "status", value: "1", operator: EQUAL, enabled: true }, { field: "moderation_state", value: "archived", operator: NOT_EQUAL }, { field: "type", value: "event" }]}, sort: {field: "changed", direction: DESC}) {
              count
              entities {
                entityLabel
              }
            }
          }
        }
    }
  }

Backend

We looked at two approaches for the backend. Both require first setting the field_listing field to support multiple values. By doing this, it immediately changes how the field is presented when editing, adding the 'multiple' property to the existing <select> element. This, in turn, changes the behavior of the select field from a dropdown to a multi-select element. This type of element does not have a great UX, since in order to select multiple items, a user would need to cmd+click/control+click each value.

Checkbox option

The checkbox option is viable, providing we make a few changes:

• Add the new checkbox field (boolean) to the Event node
• Set the field_listing field storage settings to allow for multiple items (unlimited)
• In the form display settings, configure the field_listing field widget to show only a single element (screenshot below--this is provided by a contrib module, limited_field_widgets.
• Adding a form alter to control the visiblity of the new checkbox
• Adding a pre-save entity hook to add the Outreach calendar to the field_listing.
• A small amount of css to meet styles in Figma.

Pros: easy to implement
Cons: adds another field to the CMS; somewhat of a black box--Outreach Hub only users will have no awareness this is happening; the fact that field_listing contains more values than is present could lead to some confusion.

Entity Browser option

We also looked at using Entity Browser on the exiting field_listing field en lieu of an additional field. Since Entity Browser is used in many places in the site, there are no notable UX concerns. To accommodate automatically setting the National Outreach Calendar, we looked at using the 'default value' (see screenshot). While this does solve some of the checkbox concerns, it is very difficult to navigate setting the default value contextually based on user section.

Pros: easy to implement (in basic form); leveraged all over in the CMS (not a new paradigm); no 'hidden' event listing assignments.
Cons: very difficult to contextually apply the default value. After spending the better part of half-a day trying to work that out, I have made little progress.

[chri5tia]

Status Update 10/2/23
We sync'd up as a team and made a decision to go the checkbox route instead of the entity browser. Code is working and the next step is to write cypress tests and do functional testing.

[jilladams]

Thread re: change management: https://dsva.slack.com/archives/C52CL1PKQ/p1696357745318219

Need to talk test plan / roll out before this work merges.

[jilladams]

We need to:

• create a test event with the new fix in tugboat
• Check and see what breadcrumbs do by default, including impact to content build
  • Maybe helpful to understand what FE is doing to determine breadcrumbs on an event
• Vet that with Dave to determine if Content IA and Accessibility: decide how single VAMC + Outreach events should be treated #13532 is blocking

[dsasser]

Breadcrumb test update:

❌ Adding an event to 2 event listings will cause, in the case of Lovell at least, a 404 to be returned on 1 of the 2 listing pages, when clicking on the test event. I will be testing other facility types, as well as unpacking how the urls are being re-written, but this would suggest we have a launch blocking issue, ostensibly in vets-website.

Tugboat

I rebuilt the tugboat we were using for demo'ing this issue, prior to doing any testing, to confirm that there were no errant content changes I wasn't expecting. During the rebuild, I noticed that the log was showing MANY broking link errors, and it was preventing the build from completing. Given this, I decided to do two things:

1. Setup a test locally, and
2. Setup a fresh tugboat, after merging in the latest code from main into the feature branch

The new tugboat instance is here.

The latest content relase is still pending, so I moved onto test locally. I'll update here once I have a confirmed if the tugboat env works identically as locally (as expected).

Local

I created a test event using the Lovell Health Care event listing, and the Outreach checkbox. The new event appeared on both listing pages (/outreach-and-events/events/ and /lovell-federal-health-care-va/events/ respectively).

From the Outreach and Events page, the link to the event was: /lovell-federal-health-care/events/61945

Following this link gave:

From the Lovell Events page, the link to the event was: /lovell-federal-health-care-va/events/61945

Following this link gave:

Breadcrumb code

Breadcrumbs for Drupal pages are rendered with the breadcrumbs.drupal.liquid template, included from the event.drupal.liquid template.

In the breadcrumb template, this code is at play:

    {% if deriveBreadcrumbsFromUrl == true %}
      {% assign crumbs = entityUrl.breadcrumb | deriveLastBreadcrumbFromPath: title, entityUrl.path, replaceLastItem %}
    {% endif %}

This code uses the custom Liquid filter deriveLastBreadcrumbFromPath, which leverages the url in order to create the breadcrumb.

[dsasser]

I tested the Alaska Heath Care facility, and the 404 mentioned above is not present. The test event appears on on both the Alaska Health Care facility, and the Outreach and Events page. The breadcrumb, as expected, follows the URL:

Home -> Alaska health care Events -> Lorem Ipsum Test Event

See:
https://web-thu3raipnqtrntaczkhou6vtskp73ajc.demo.cms.va.gov/alaska-health-care/events/
https://web-thu3raipnqtrntaczkhou6vtskp73ajc.demo.cms.va.gov/outreach-and-events/events/

So it would seem we have a Lovell-only issue with regards to posting a single Event to multiple Event Listings.

[jilladams]

#13532 is blocking merging this work. For now we are going to: add a feature toggle (just on/off) and hide the checkbox, in order to merge/ship. We will need a follow up ticket to either modify the toggle to show to a subset of users when it's on, or turn on, or just remove it.

[chri5tia]

Status Update 10/5/23

As of before this morning's scrum update, cypress test was added and functional to test different scenarios regarding this feature. Draft PR was created.

Today, Daniel and I co-worked to created a feature toggle for this outreach calendar checkbox due to the breadcrumb issue. As of right now there is something that needs to be debugged with it so that is what I will be working on next between now and next scrum update.

Adding the feature toggle also means revising the cypress test, which means strategizing.

The PR for this ticket adds outreach calendar checkbox cypress tests by utilizing the existing step definition i_create_a_node.js. This step definition instructs filling out all the important form fields for the event form. The existing step definition code, now and prior, saves the form. Now that we have added the feature toggle to hide the checkbox when toggled off, the test will fail. The existing structure limits accommodating toggling on the feature first, and other scenarios, so that the tests will pass.

Below are ideas to improve this step definition to make it more versatile. In the meantime, we'll likely just need to add instructions to turn on the feature toggle into i_create_a_node.js before testing the creation of the event node. I am still thinking through the feasibility of that strategy.

Events Cypress Testing For the future

Problem statement: When testing the event form, I have to write testing to fill out required fields when trying out different scenarios. This creates similar code in more than once place, which can lead to tech debt and confusion.

Idea:
Consider changing the node create step definition (i_create_a_node.js to not include saving the form, saving that for a separate step, (or totally moving the event part from that to i_fill_in_node_details, but not having similar code in two places), so that we can add different scenarios that all rely on filling out the required and other details without creating duplicitous test content; add scenarios to events.feature and similar:

Example:

  Scenario: Users can publish an event to the National Outreach Calendar
    Given I am logged in as a user with the "content_admin" role
    When I create an "event" node
    And I check the "Publish to the National Outreach Calendar" checkbox
    And I save the node
    Then the event node should be created successfully.
    And I should see "Outreach Calendar"

  Scenario: Users who can only publish to National Outreach Calendar do not see the "Publish to the National Outreach Calendar" checkbox
    Given I am logged in as a user with the "content_admin" role
    When my workbench access sections are set to "7"
    And I create an "event" node
    Then I should not see a "Publish to the National Outreach Calendar" checkbox
    When I save the node
    Then I should see "Outreach Calendar"

Also, then we can revise the first Scenario as such:

  Scenario: Log in and create an event successfully.
    Given I am logged in as a user with the "content_admin" role
    When I create a "event" node
    And I save the node
    Then the event node should be created successfully.

Noting that we do not currently have the Then step for node creation tests.

We could add a step definition for node_should_be_created_successfully which checks for the success message and (then goes back and checks for the revision log entry and whatever else).

Also add (a|an) for create a node step.

TL;DR

PR: #15552

Next steps:

• fix feature toggle
• fix cypress test for added feature toggle
• breadcrumb analysis and fix

Future:

• Maybe cut some tickets about event cypress test structure improvements

[chri5tia]

• Also need to look at the platform/file_upload.feature cypress test which now fails due to changes to the events form.

[jilladams]

Poked at Lovell use case for sanity. Screensots in doobly doo -- all working and we should review as part of CAIA IA step.

VA Lovell listing

Tricare Lovell listing

Outreach events

Event page, approach from VA Lovell

Event page, approach from Tricare Lovell

Event page from Outreach events

Uses Federal health care VA breadcrumb.

(The inconsistencies in punctuation / capitalization between Event Listings and Events are the same in prod, so not part of our work here. Looking for a ticket and will file one if it doesn't exist.)

[chri5tia]

Status Update 10/6/23

• Updated cypress test to include feature toggle under different user roles
• Fixed feature toggle so that the checkbox part of the form can be turned off when we don't want it
• This is ready to merge pending PO sign off, PM and a11y review

[chri5tia]

Status update 10/9/23

• PR is merged

Notes for future work

• Per @dsasser, consider changing step definition for feature toggle to run a drush command so that if it's used in the future, the feature file doesn't have to include steps to log in as admin and then log out and then log in as test user.

[dsasser]

@laflannery can you confirm (I think you did this in various places, but wanted to document here) that the CMS changes are good from an a11y perspective?

[laflannery]

@dsasser I I just reviewed on stage and have no issues. This is good on my end

[jilladams]

Noting: I created #15627 to track any follow up required from talking to CAIA, and to track enabling the Feature toggle when the time comes.

[jilladams]

Work was merged to prod and worked fine on Events, but: broke other things.
We are mid-trying to revert.

#15641 tracks the related defect that will allow re-merge.