Feed the Symfony dashboard's Zone Two hook with a sales chart

[nicosomb]

Questions	Answers
Description?	Adds hookDisplayAdminDashboardZoneTwo(), the modern counterpart of hookDashboardZoneTwo(), so this module also feeds the migrated (Symfony) Back Office Dashboard. Reuses the existing getData()/refineData() computation as-is and serializes the sales trend as a plain Chart.js config, following the contract from PrestaShop/PrestaShop#42431. Legacy hooks are untouched — the module still works unmodified on the legacy dashboard. Version bumped 2.1.3 → 2.2.0 (minor, backward compatible with 8.2.0+).
Type?	new feature
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#41971.
How to test?	1. On a shop with PrestaShop/PrestaShop#42431 and the dashboard feature flag enabled, install/reset this module. 2. Open the BO Dashboard: a sales-trend line chart renders in Zone Two, colored via the core PrestaShop palette.

Draft PoC for the #41971 spike — a minor release, deliberately kept compatible with older PrestaShop versions alongside 9.3.

[ps-jarvis]

This pull request seems to contain new translation strings. I have summarized them below to ease up review:

• Admin.Global
  • Sales trend

(Note: this is an automated message, but answering it will reach a real human)

[mattgoud]

Tested locally against PrestaShop/PrestaShop#42431 with the dashboard flag on. The sales trend chart renders in zone two and picks up the brand palette without any module-side JS, and the legacy dashboardZoneTwo path is untouched. This is the cleanest of the four module PRs, and reusing getData() / refineData() as-is is the right call.

One blocker and a few small things.

Blocker: no upgrade script, so no existing shop will ever get the hook

install() only runs on a fresh install. On a shop that already has dashtrends 2.1.3, nothing registers displayAdminDashboardZoneTwo.

Reproduced locally: old version installed, 2.2.0 files dropped on disk, then the upgrade path replayed (ModuleManager::upgradeMigration() minus the download step):

dashtrends   db=2.1.3   disk=2.2.0   needUpgrade=NO

No hook row, and Module::upgradeModuleVersion() is never called so ps_module.version stays on 2.1.3 forever, meaning the Module Manager keeps offering an update that does nothing.

autoupgrade behaves the same way: ModuleMigration::needMigration() returns false when upgrade/*.php is empty, it logs "Module does not need to be migrated", and then calls saveVersionInDb() anyway. So after a core upgrade the shop reports 2.2.0 while the hook is still not registered, with no way back other than uninstall/reinstall (losing the configuration). This is not something autoupgrade can fix on its own: core upgrade SQL never inserts into ps_hook_module, it only cleans orphans.

The module already has the pattern (upgrade/upgrade-2.1.0.php does unregisterHook(...)), so it just needs:

// upgrade/upgrade-2.2.0.php
function upgrade_module_2_2_0($object)
{
    return $object->registerHook('displayAdminDashboardZoneTwo');
}

Sales trend is a new string in a core catalogue

ps-jarvis flagged it, and it is indeed absent from translations/en-US/AdminGlobal.en-US.xlf. A module cannot add entries to core catalogues (those come from Crowdin on the core side), so it will stay untranslated forever. It belongs in Modules.Dashtrends.Admin. Sales in Admin.Global is fine, that one exists.

Smaller points

• height="80" is ignored. Chart.js is responsive by default and recomputes the height from aspectRatio. Measured on this branch, the canvas renders at 322px. A sized wrapper plus maintainAspectRatio: false is needed if the intent was a compact chart.
• No currency formatting. The JSON-only contract has no callbacks, so the sales figures show as raw numbers with no currency. Worth raising on PrestaShop/PrestaShop#42431 rather than working around it here.
• $this->dashboard_data as implicit state. hookDisplayAdminDashboardZoneTwo() assigns the property and getSalesChartConfig() reads it back. Passing the refined data as an argument would keep the new code free of the legacy pattern.
• json_encode(..., JSON_HEX_TAG | JSON_HEX_AMP) is the right thing to do; I have suggested on the core PR that this belongs in a shared Twig macro so no module has to remember it.

[mattgoud]

height="80" has no effect: Chart.js runs responsive by default and recomputes the canvas height from aspectRatio. On this branch the canvas ends up at 322px. If you want a compact chart, it needs a wrapper with a fixed height plus 'maintainAspectRatio' => false in the options.