Track user clicks on Links/Buttons in disconnect modal footer

[jim-coffey]

Changes proposed in this Pull Request:

• user should see no difference
• when clicking any link or button in the footer of the disconnect dialog - an event should be recorded so we can see how users are interacting with the modal options (see test plan for details)

Jetpack product discussion

n/a

Does this pull request change what data or activity we track or use?

We are tracking some more clicks but no major change to how or what we track.

Testing instructions:

You can see if tracking events are being triggered by looking for the tracking pixels in the Network and checking query parameters - filter network traffic by t.gif. Or enabling logging in the browser console, as detailed here PCYsg-nSS-p2. Or visit the internal live tracker website.

• with Jetpack development running locally
• open /wp-admin
• navigate to -> Jetpack -> Dashboard
• click 'Manage Site Connection'
• click the Jetpack connection link and check you see the jetpack_disconnect_dialog_click_learn_about event
• click the contact Jetpack support link and check you see the jetpack_disconnect_dialog_click_support event
• click the Stay Connected button and check the modal still closes and you see the jetpack_disconnect_dialog_click_stay_connected event
• reopen the modal, and click the Disconnect button and check you still disconnect and see the jetpack_disconnect_dialog_click_disconnect event

Repeat the above from the -> Plugins : Jetpack : Disconnect and Deactivate - the events are the same but the context of the tracking should be plugins rather than jetpack

For reference, the links and buttons are illustrated here:

Unit Tests

Unit Tests have been updated and can be checked by running pnpm t from the projects/js-packages/connection/ folder.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ⚠️ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: February 1, 2022.
• Scheduled code freeze: January 24, 2022.

---

Backup plugin:

• Next scheduled release: February 1, 2022.
• Scheduled code freeze: January 24, 2022.

[jboland88]

Looks good overall, added a few comments inline

Some small notes on the test plan:

You can see if tracking events are being triggered by looking for the tracking pixels in the Network and checking query parameters

Some more instruction on this could be helpful on this point, is there something to filter by in the Network panel that would show the requests that we are looking for?

A screenshot of this modal from a testing site would be a nice add to the test plan to show which links are being tested. I think the steps are descriptive for what to click/ observe, but a visual would help confirm the tester is looking at the right thing.

Since JS unit tests are being added/ modified, we'll want to be sure to include an instruction to confirm the tests are passing as part of the test plan. IIRC, to run tests for this package, you can run pnpm test from within the package directory.

[travisw]

It all works great. Nice work, Jim. I left a few inline questions and comments.

[jim-coffey]

It all works great. Nice work, Jim. I left a few inline questions and comments.

Hey @travisw - I'm probably missing something - but I can't see any comments from you 🤔

[travisw]

It all works great. Nice work, Jim. I left a few inline questions and comments.

Hey @travisw - I'm probably missing something - but I can't see any comments from you 🤔

Sorry Jim! I failed to click submit – just did that now.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello jim-coffey! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D73889-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[jboland88]

I think this looks good and tests well.
Added one suggestion around the unit tests, but not considering that a blocker.

[jeherve]

This tests well for me. 🚢
The js tests are failing at the moment, but it may be a false alert. I've relaunched the tests just now.

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D73889-code, and commit it.
Once you've done so, come back to this PR and add a comment with your changeset ID.

Thank you!

[samiff]

r239287-wpcom