ThreatsDataViews: History fields preset

[dkmyta]

Description

Adds custom fields when viewing Active threats and History (only in table view).

Proposed changes

• Display relevant fields dependant on dataFields and statusFilters
  • When current filter is included in statusFilters show auto-fix
  • When fixed, ignored, or historic (fixed and ignored) show first-detected, fixed-on, and hide auto-fix
  • Always show Status so you can distinguish between active/historic threats when viewing all only for the paid view
    • This could be further conditional to be hidden when only viewing current threats?
    • We may also want to include this field in list view for better clarity
• Show a more descriptive Auto-fix item in actions drop down only in list view, removing it from table view in favour of the Auto-fix field

Potential issues:

• If a user has no active threats and views all (either by removing all or adding all status filters), the auto-fix column will display even though they are technically viewing only historical threats.
• If a user is in a filter state where fields are not included (eg. no filters applied), they cannot apply such fields (eg. first-detected) manually from the settings.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

• https://github.com/Automattic/jetpack-scan-team/issues/1592

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

• No

Testing instructions:

• Review ThreatsDataViews storybooks
• Checkout this Protect branch on Jurassic Tube/Ninja
• Ensure that the toggle between Active threats and History applies the correct fields preset
• Ensure modifying filters also applies the correct field presets

Screenshots

Active threats:

History:

Action drop-down auto-fix in list view (now removed in table view):

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the add/components/threats-data-views-history-fields-preset branch.

  • For jetpack-mu-wpcom changes, also add define( 'JETPACK_MU_WPCOM_LOAD_VIA_BETA_PLUGIN', true ); to your wp-config.php file.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack add/components/threats-data-views-history-fields-preset
  

  bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/components/threats-data-views-history-fields-preset
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[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.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• 🔴 Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ 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.

---

🔴 Action required: Please add missing changelog entries for the following projects: projects/js-packages/components, projects/plugins/protect

Use the Jetpack CLI tool to generate changelog entries by running the following command: jetpack changelog add.
Guidelines: /docs/writing-a-good-changelog-entry.md

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Choose a review path based on your changes:
   • A. Team Review: add the "[Status] Needs Team Review" label
     • For most changes, including minor cross-team impacts.
     • Example: Updating a team-specific component or a small change to a shared library.
   • B. Crew Review: add the "[Status] Needs Review" label
     • For significant changes to core functionality.
     • Example: Major updates to a shared library or complex features.
   • C. Both: Start with Team, then request Crew
     • For complex changes or when you need extra confidence.
     • Example: Refactor affecting multiple systems.
3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

---

Protect plugin:

• Next scheduled release: none scheduled.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[nateweller]

I am curious if there's a possible alternative configuration that would allow us to still include the "first detected" field regardless of the current filters, but hide/show the particular field in the table view based on the current filters, instead of omitting the definition of the fields entirely. I'll follow up on this!

[dkmyta]

I had a similar hope, and did come across isVisible which I thought might be an option but seemed to not function as I expected it to.

[nateweller]

Could we use isVisible? Edit: ah, that might be a per-item method.

[nateweller]

I am working on a potential approach using the onChangeView callback, will share shortly!

[dkmyta]

Just a heads up that I did start with the onChangeView approach and it seemed to have its own limitations - IIRC there were challenges related to not being able to check the current view state against the changed view state because it was always outdated. Regardless, interested to see what you think might work reintroducing that take.