Password generator/validator classes (USER_PASSWORD_GENERATED,
modGeneratePassXxx extends ModeleGenPassword) could previously only live
under htdocs/core/modules/security/generate/ — every call site resolving
one by name hardcoded that path, so no third-party module could
contribute its own generator without patching core.
Reuse the modules_parts['models'] extension point already populated for
any enabled module declaring $this->module_parts['models'] = 1 (the same
mechanism every numbering-module scan in Dolibarr already uses — see e.g.
Facture::getNextNumRef()), and wire it into the password-generator scan
too:
- admin/security.php's generator listing now scans core plus every
enabled module declaring module_parts['models'], instead of only
core/modules/security/generate/.
- Added ModeleGenPassword::loadAndInstantiate($id, ...) in
modules_genpassword.php, a shared factory doing that same multi-root
resolution once, used by the four runtime call sites that previously
hardcoded the core-only path: User::setPassword(), getRandomPassword()
(security2.lib.php), FormSetupItem::generateInputFieldPassword()
(html.formsetup.class.php), and PasswordField::verifyFieldValue()
(passwordfield.class.php). getRandomPassword() falls back to the
'standard' generator (with a warning logged) if the configured
generator's class can't be resolved, rather than silently generating
and persisting an empty password.
Behavior for the built-in Standard/None/Perso generators is unchanged —
core is always the first root scanned, so it always wins for those ids.
750145e663