Add has_required_plan to product info and implement it in Search

[leogermani]

This PR starts to check whether the site's current plan (or purchase) supports the product.

The first product we are checking is "Search", by using the search package.

Changes proposed in this Pull Request:

• Add has_required_plan to product info and implement it in Search

Jetpack product discussion

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

N/A

Testing instructions:

• Go to My Jetpack
• Inspect the global myJetpackInitialState var
• Verify that all products have has_required_plan equals true except from Search
• Buy a plan or product that include Search
• Check again and verify that Search is now also true

[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: March 1, 2022.
• Scheduled code freeze: February 22, 2022.

---

Backup plugin:

• Next scheduled release: March 1, 2022.
• Scheduled code freeze: February 21, 2022.

[retrofox]

I wonder about has_required_plan prop name. What do you think compared with is_plan_required? Minor suggestion btw.

[leogermani]

I wonder about has_required_plan prop name. What do you think compared with is_plan_required? Minor suggestion btw.

is_plan_required is a good one to tell if the product requires a paid plan or not. The value will be hard coded. has_required_plan checks if the site has already bought the required plan if is_plan_required.

Makes sense?

[retrofox]

I wonder about has_required_plan prop name. What do you think compared with is_plan_required? Minor suggestion btw.

is_plan_required is a good one to tell if the product requires a paid plan or not. The value will be hard coded. has_required_plan checks if the site has already bought the required plan if is_plan_required.

Makes sense?

yes, it seems to be a matter of verb tense :-)

[retrofox]

something we've been talking about. I thought.
I though we could check whether the product requires a plan at top of this method:

Suggested change

	public static function get_status() {
	if ( static::is_active() ) {
	$status = 'active';
	if ( ! static::has_required_plan() ) {
	$status = 'needs_purchase';
	}
	public static function get_status() {
	if ( ! static::has_required_plan() ) {
	$status = 'needs_purchase';
	} elseif ( static::is_active() ) {
	$status = 'active';

It's ok to me, just wanted to put in code the way that we'll have to take to deal with the product activation flow.

[leogermani]

has_required_plan will return true by default. If the product doesn't need a plan, it will return true.

But I agree that could be useful to have another property that specifically says if the product is free or not

[retrofox]

LGTM.
👍

[jsnmoon]

Is Search_PLan a typo? Looks like it ought to be Search_Plan 🙂

[leogermani]

wow, I wonder how it didnt throw any errors

[jeherve]

Since the Search package is quite big, I wonder if there would be a way to do this without adding the whole package as a new dependency to the My Jetpack package? By doing so, we'll end up shipping the Search feature in multiple standalone features.

[leogermani]

Since the Search package is quite big, I wonder if there would be a way to do this without adding the whole package as a new dependency to the My Jetpack package? By doing so, we'll end up shipping the Search feature in multiple standalone features.

It might be a bit big in MB for the package (around 4,9M?) but it should not influence what's loaded at runtime as it will only load the classes we actually use...

We could duplicate some of the things in My Jetpack, but I think in the long each product will provide its own class to handle how it will behave in the My Jetpack page, with all the labels, possible states, actions, etc.

Anyway we are still in the early stages. If you think this is a blocker we can think of an alternative, otherwise it seems like a good way to go for now.

[leogermani]

@jeherve I'm giving it a second thought, maybe it's not a bad idea to just copy and paste what we need for the MVP, and hold more dependencies and abstractions for later.

Also, the Search package is still under development and might change and break things:

p1644012854589339-slack-C82FZ5T4G?thread_ts=1644003501.536539&cid=C82FZ5T4G

So I'll probably revisit it and exclude the dependency