750145e663
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. |
||
|---|---|---|
| .. | ||
| captcha | ||
| generate | ||