Components: Add Threats DataView

[nateweller]

Resolves https://github.com/Automattic/jetpack-scan-team/issues/1512

Proposed changes:

• Adds a ThreatsDataViews component for displaying threats identified by Jetpack Scan.
• Supports both table and list views.
• Adds a supporting Badge component.
• Updates the supporting ThreatSeverityBadge component to also use the new Badge component.
• Adds hover support to the supporting IconTooltip component.
• Adds types to the scan package, and implements them in the above components.

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

p1HpG7-uIo-p2

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

No

Testing instructions:

• Review the storybook: cd projects/js-packages/storybook && pnpm storybook:dev

Screenshots

[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 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.

---

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.

[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-view 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-view
  

  bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/components/threats-data-view
  

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

[dkmyta]

Looking absolutely fantastic!

Some super minor changes requested mostly surrounding text content and story config and data, otherwise, the bulk of this is ready to go!

Worth noting that there are still some things that we may want to address in other followups, for example:

• When a fixer is in-progress or in error state, we should hide or disable any actions.
• I believe it was confirmed that we should even hide the Actions button when none are available (rather than disable) - perhaps that could be suitable option for the previous point as well.
• We already have something in the works for adding bulk actions support, but if that doesn't move forward as planned (pending designs confirmation of whether we want to strictly keep to core functionality), we will want to update the logic here for the checkboxes (if they should display and when they should be active/disabled).

[dkmyta]

Not sure if this was done intentionally to confirm that we display results that do not have a valid id (which it appears to), but I believe this should be an integer ID as with the rest.

Additionally, this entry does not have a status so only shows up when all filters are removed but cannot have any actions performed on it.

[nateweller]

This story is mocking the free results, which do include a string id, which comes from the alphanumeric WPScan vulnerability ID. I've updated the Threat.id type to string | number because of that. Fixed the missing status as well: 6549f86

I've also updated the Threat type to use conditional properties more generally - i.e. do not expect every threat to have every property to always have a value set, remove the manual setting of null for irrelevant properties: b6dbf92

We can probably improve the Threat type further with unions/discriminations for specific threat types and/or data sources. I can include that in the follow up PR that adjusts how the threats data is provided from the server side. 👍

[dkmyta]

Just a general note on these types, in Protect we have a much more extensive set of types in fixers.ts that considers all the varying possible statuses. It seems we don't require this to function here but will that change once we are handling actual Scan API responses? Or are these two just similar but for completely separate purposes and wont have any overlap?

[nateweller]

I've only moved over the necessary types used by the dataviews component in this PR – the component doesn't work with the fixers API response directly, it only needs the FixerStatus and ThreatFixStatus types for rendering the auto-fix column.

I do eventually bring in the rest of the FixersStatus types here in the follow-up PR 👍

[nateweller]

Looking into the failing JS tests 👀

[nateweller]

Tests fixed via 79804d5 👍

[nateweller]

Thanks for the review @dkmyta!

I have merged your suggestions and responded to any inline comments.

Worth noting that there are still some things that we may want to address in other followups, for example:

• When a fixer is in-progress or in error state, we should hide or disable any actions.
• I believe it was confirmed that we should even hide the Actions button when none are available (rather than disable) - perhaps that could be suitable option for the previous point as well.
• We already have something in the works for adding bulk actions support, but if that doesn't move forward as planned (pending designs confirmation of whether we want to strictly keep to core functionality), we will want to update the logic here for the checkboxes (if they should display and when they should be active/disabled).

Good points re: follow-ups! We can address disabling threat actions when integrating the component, using the isThreatEligibleFor[Action] props. Other items may be dependent on core support and design choices, like checkbox visibility. I think where we're at now is a good start 👍

[dkmyta]

LGTM!

[manzoorwanijk]

Do these threats specific components belong to the generic components package? May be they belong to the scan JS package?

CC: @Automattic/jetpack-garage

[manzoorwanijk]

The reason for that is these components and thus the dataviews component may be bundled to all the consumer plugins that import components package.

[anomiex]

Do these threats specific components belong to the generic components package?

Personally I'd say no. I think the components package should have stick to things that would be very widely useful. But I can't speak for all of Garage on this, that's just my own view.

You might also ask @Automattic/jetpack-agora, I think they still do work on the package.

[nateweller]

@manzoorwanijk @anomiex @Automattic/jetpack-agora

We have initially included these components here as:

• they are candidates for re-use across Jetpack projects (notably the Jetpack and Protect plugins)
• there are existing product/feature specific components in the package (BoostScoreBar, BoostScoreGraph, etc)
• These threat components rely on other Jetpack components (Button, Badge, Text) so we would need the scan package to depend on components. The components package extends the tsconfig.base.json config, and the use of "moduleResolution": "bundler" is incompatible with the scan package's current use of tsconfig.tsc.json. Though we could address this somehow I'm sure.

To avoid weighing down the main components package, we can definitely look into the possibility of distributing these components elsewhere.

[anomiex]

The components package extends the tsconfig.base.json config, and the use of "moduleResolution": "bundler" is incompatible with the scan package's current use of tsconfig.tsc.json. Though we could address this somehow I'm sure.

Probably just switching the import statements to use .js extensions (and explicit index.js instead of directory includes) would be sufficient.

OTOH, fully switching it to generate a build directory, along the lines of what #40299 did for scan, wouldn't be a bad thing for someone to do. It'd make the package more usable outside the monorepo.