department-of-veterans-affairs / va.gov-cms

Editor-centered management for Veteran-centered content.
https://prod.cms.va.gov
GNU General Public License v2.0
98 stars 68 forks source link

Create Service for Banner Interactions and Data Retrieval (Story 3) #19450

Open Agile6MSkinner opened 2 weeks ago

Agile6MSkinner commented 2 weeks ago

Description

Develop a new service for managing banner interactions and storing the necessary data in production. This includes setting up initial database ACTIVE RECORD for storing alert banner data in the pSQL database, ensuring scalability and reliability for full deployment.

Sequence Note: This task can be done after story 2 and in parallel with story 4, but must be completed before Story 6.

Testing & QA

Roles / assignments

Acceptance criteria

dsasser commented 2 days ago

@SnowboardTechie I took a first attempt at content modeling for a Banner model that could work for both the MVP (VAMC banners w/o situation updates) and future alerts/banners.

I ended up with this schema (described as a FactoryBot object because it was handy):

FactoryBot.define do
  factory :banner do
    entity_id { 1 }
    entity_bundle { 'full_width_banner_alert' }
    headline { 'Important Alert!' }
    alert_type { 'warning' }
    show_close { false }
    content { '<p>This is a warning alert.</p>' }
    context {
      [
        {
          entity: {
            title: 'Operating status | VA Puget Sound health care',
            entityUrl: {
              path: '/puget-sound-health-care/operating-status'
            },
            fieldOffice: {
              entity: {
                fieldVamcEhrSystem: 'vista',
                title: 'VA Puget Sound health care',
                entityUrl: {
                  path: '/puget-sound-health-care'
                }
              }
            }
          }
        }
      ]
    }

    operating_status_cta { false }
    email_updates_button { false }
    find_facilities_cta { false }
    limit_subpage_inheritance { false }
  end
end

I think the most notable of the schema is in the "context" value. I didn't want too much in the way of facility/VAMC specific fields in the db (we ended up with a few booleans but they are optional) to keep Banners generic for other banner types in the future. And for VAMC banners, the path(s) that are used to determine display are housed within these related VAMC entities on the banner node in Drupal, and coming back as a json object in graphql:

          "fieldBannerAlertVamcs": [
            {
              "entity": {
                "title": "Operating status | VA Puget Sound health care",
                "entityUrl": {
                  "path": "/puget-sound-health-care/operating-status"
                },
                "fieldOffice": {
                  "entity": {
                    "fieldVamcEhrSystem": "vista",
                    "title": "VA Puget Sound health care",
                    "entityUrl": {
                      "path": "/puget-sound-health-care"
                    }
                  }
                }
              }
            }
          ],

So I created this 'context' field on the Banner ActiveRecord object, which has a storage type of 'jsonb' in the backend, to contain the VAMCs. In future banners, we can store other data as needed there. The API will then have a distinct way of determining if a banner should be displayed per banner type. This maps well to the related content types in Drupal. Hope this makes sense, holler if not.

dsasser commented 2 days ago

There are two PRs to track for this issue:

  1. VACMS-19450: Creates Banner Module department-of-veterans-affairs/vets-api#19056
  2. VACMS-19450: Banner model migration department-of-veterans-affairs/vets-api#19069

PR 1 adds the new schema to the postgres database. PR 2 is the remaining portion of the work for this issue.

dsasser commented 1 day ago

Mid-Sprint Update 10-24-24

Changes are in PR and have been approved by our team so we are waiting on Platform review at this time.