[rennf93]

Closes #16

Every setting now lives under one EspoCRM config param, guardCore: enabled plus everything that 1.0.0 kept in guard, Redis settings included. Nothing the extension owns sits at the root next to other extensions' keys any more. The docs now say data/config-internal.php, where EspoCRM stores and rewrites level system params. Version 1.1.0.

Behavior

• guardCore is declared at level system, like guardEnabled and guard, so the Settings API never returns any of them.

• Middleware reads guardCore and throws loudly in three cases:

  • guardCore is not a map;
  • enabled is not a bool;
  • settings are split between guardCore and the old keys while either side says enabled.

  The disabled path still only reads config.

• The old guardEnabled / guard keep working and log one deprecation warning when the guard is built.

• New AfterInstall (runs on install and upgrade) moves the old keys into guardCore and removes them. It changes nothing in these cases:

  • a fresh install;
  • a config that is already migrated;
  • a guard that is not a map;
  • old keys kept in data/config-override.php or data/config-internal-override.php (EspoCRM never writes those, so they stay and keep working with the warning).

• On upgrade, EspoCRM uninstalls the old version with skipAfterScript (Actions/Extension/Install.php:210-216), so the old uninstall script does not wipe the config.

• Fixed, also present in 1.0.0: before EspoCRM 9.3, ConfigWriter removes a level system param from config-internal.php only (ConfigWriter.php at 9.0.0, lines 143-153). Uninstall therefore left guardEnabled and guard in data/config.php, where they lose their system level. Both scripts now set each key to null before removing it. That moves the key out of config.php on every EspoCRM version.

Verification

• make lint: exit 0, PHPStan level 8 no errors.
• REDIS_HOST=127.0.0.1 REDIS_PORT=6538 make local-test on EspoCRM stable (PHP 8.5.12) and on 9.0.0 (PHP 8.3.36): OK (84 tests, 214 assertions), COVERAGE: 100.00% lines (GATE: PASS), exit 0 on both.
• New tests run both scripts against EspoCRM's real Config and ConfigWriter in a scratch directory and assert the file contents. They cover keys in config.php, in config-internal.php, split across both, in an override file, a fresh install, a second run and the uninstall. Negative control on 9.0.0: without the set-before-remove line, 4 of 11 fail ("guardEnabled left in config.php").
• Real upgrade from the published v1.0.0 zip (sha256 checked) on espocrm/espocrm:10.0.10-apache and espocrm/espocrm:9.2.7:
  • old keys in data/config.php before the upgrade;
  • guardCore in data/config-internal.php and no old key anywhere after it;
  • a SQL-injection query got 400 before and after the upgrade;
  • after uninstall, no guard key in either file.
• pre-commit run on the 35 changed files: exit 0. mkdocs build --strict: exit 0. make extension plus check-extension-zip.sh: zip ok: guard-core-1.1.0.zip, 438221 bytes, 206 entries, with scripts/AfterInstall.php and scripts/AfterUninstall.php in it.

Not run: an upgrade test on a 9.0.x image (9.2.7 is the newest affected tag that exists).