Redefine when revenue information is displayed on All Websites Dashboard

[mneudert]

Description:

In the current All Websites Dashboard (AWD), the revenue information is always shown, unless the Goals plugin is disabled.

For the redesigned AWD, this condition will be changed to only display revenue information if:

• the Goals plugin is enabled
• and
  • at least one website is an ecommerce website
  • or at least one goal has a non-zero default revenue
  • or at least one goal is flagged with "use event value as revenue"

This check is done on a per-user basis, a user needs at least view access to any site that would quality for displaying revenue information.

---

The API Goals.getGoals was fixed to properly return goals for multiple sites. The goal list was indexed by idgoal, but that value is not unique across sites, so if two sites had idgoal = 1, you would only get one result instead of two. The API was changed to NOT index the return list with any defined keys to work around this limitation. Requesting goals for a single site will still return them indexed by idgoal.

Fetching 40k goals across 10k sites took a varying time between 500ms and 1250ms in my development environment according to XHProf (around 50% of the total runtime), with most of the time spent in Goals\API::formatGoal(). The API will not be called if there is at least one ecommerce site available.

Without XHProf active, the response times were always hovering between 175ms and 200ms locally (according to curl), and around 75ms to 100ms without any of the new checks.

If necessary, we can add an (internal?) Goals.hasAtLeastOneGoalWithRevenue($idSites) that could take care of that check in a single database query and circumvent the goal formatting. We can also take this approach if the change to Goals.getGoals qualifies as a breaking change and can not be done in a feature release, even though it is also a fix.

---

Fixes #5045
Refs DEV-15665

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

[github-actions]

This issue is in "needs review" but there has been no activity for 7 days. ping @matomo-org/core-reviewers

[caddoo]

I can't quite understand why you would want this different behavior if there is a single goal or multiple? What's the problem with always setting the array index as the ID goal?

[michalkleiner]

@caddoo backward compatibility. It's a public API change, we would need to wait until Matomo 6 ideally, or have a prominent message in the changelog about his. So with this compromise we agreed that's palatable if we keep the behaviour for a all sites and update it for a single site where the list of goals won't change with the index, but it would change if we indexed it in the list for all sites.

[sgiehl]

All tests are passing 🥳