Generate Password 2.0.0 stable release

I'd like to add ^8.9 to the core_version_requirement, effectively replacing the 8.x-1.x branch and allowing site upgrades all the way from D8 to D10 without needing to also update this module.

I'm in the process of getting all the new features into the 2.x branch, and I don't wish to duplicate that work into the 8.x-1.x branch. Once 2.x is stable, it should also be marked suggested and 8.x-1.x downgraded from that status. Give it a period and then mark it unsupported. Would a month do?

Issues for release:

• Add ^8.9 as a core version
• ✨ Add Action Plugin to set a random password for existing user(s) Fixed
• ✨ Optionally hide the password field for admins Fixed
• 📌 Implement hook_help() Fixed
• 📌 Automated Drupal 10 compatibility fixes RTBC
• 💬 Add Readme.md file for the Documentation Fixed
• 🐛 Fatal error when try to register after instalation of generate password module Fixed
• ✨ Allow other modules to specify which forms should work with this module (multiple add user forms) Fixed
• Confirm no D10 issues; try not to push past 8.9 until D9 EOL+some.

This plan seems great to me. I think a period of 2-3 months might be better before people get warnings in their site. Is there any reason to remove support from 8.x faster than 3 months?

One more thought - maybe the decision can depend in part on how many new issues (especially bugs) are reported? If there are few bugs reported that would argue for dropping support sooner.

3 months sounds fine. No real reason to speed it up unless everyone switches over in a hurry. Setting a schedule would be good.

For 2.x branch
- Finish adding these features + bug fixes
- +1 week. Make a RC
- +1 month no complaints, stable release

For 8.x-1.x branch
- Upon 2.x stable release:
- Remove recommend
- Make a 8.x-1.x release just with the existing tiny changes in that branch, plus a notice that it will soon be unsupported and it's easy upgrade to 2.x branch - hook requirements warning? A bit cheeky. At least with an update it might trigger people to see "oh there's a new version to get"
- +2-3 months: Mark as unsupported

Seems like a great plan to me. Thanks for all your work on this module!

I just added 📌 Tidy up Settings UI Fixed to the list of issues but I also have another 2 in mind.

• Add a password generator service, using the same interface as Drupal Core - DrupalPasswordInterface
  • Add option to use that password service in place of drupal core - either full replacement of service class, or decorate.
• Remove hook_password facility. If you want to use Genpass for password generation, replace the drupal core's generator. Any module that wants to do the same, can write their own service to replace core's generator. There's no need for this module to provide the facility any more.

This is available since Drupal 8 and the password service instead of user_password() function.

The reason to use the replacement password service would be so that Genpass is actually used for all of the password generation, which is what is implied by the settings page, but it in only in use when a password field would normally be on the form. When email verification is enabled, only drupal core's generator is currently used. By outright replacing it, Genpass is used in all situations.

Not sure that password display can always happen if desired. The token should still.

A couple of additional changes that have been credited against this issue:

Change default install option for "genpass_mode" (User password entry) from PASSWORD_OPTIONAL (1) to PASSWORD_RESTRICTED (2). This lines up with D9 standard install which sets "email verification" on by default. This is the only option the lines up with the expected behaviour.

Change the genpass_algorithm_modules() to use a different method. This doesn't really matter at this point as I'm posting issues to remove these bits of code completely anyway.

Attempting to 📌 Add PasswordGeneratorInterface based service. Remove hook_password Fixed has encountered the problem that I am replacing a service that was only introduced in D9.1. I have tried to make it configurable and work back with 8.9 by making it optional, and providing just a stand-alone service for the earlier versions, but it simply doesn't work. (See the issue for more details)

Given this also removes all of the code that was part of the fallback to 8.9, this puts a very solid rock in the road to fork off and create a distinctly different 2.0.x release which really is D9.1+ and D10 only. Trying to keep D8 is just too hard, plus it's not supported anyway. Good-bye D8 support in this release.

This does mean I would then update the plan to keep the 8.x-1.x release, but mark it not recommended instead after a 2.x release. There would be a 1.2 release to fix the known bug in it.

Q: Should Genpass put itself in place of Core's DefaultPasswordGenerator by default? At present Genpass is only used on Admin user create/User Register forms; all other password generation slips through to core.

Q: Should Genpass put itself in place of Core's DefaultPasswordGenerator by default? At present Genpass is only used on Admin user create/User Register forms; all other password generation slips through to core.

I think that would make sense. There have been issues over the years about making genpass work reliably for users created in a variety of ways, so putting it in place of core by default makes sense to me.

Remaining task is ✨ Allow other modules to specify which forms should work with this module (multiple add user forms) Fixed .

All other tasks and issues are in the branches for 7.x-1.x, 8.x-1.x (still in feature branch), and 2.0.x releases.

Sorry, it seems that 7.x-2.x is languishing. It's a different zero config version.

Last issue has been merged into dev. The dev-2.x branch is now all the code to include in a tagged 2.0.0 release. Should it be 2.0.0-rc1 instead due to the lack of feedback so far?

Updated proposed release notes in issue summary.

I would go for 2.0.0. You can always release a 2.0.1 if there's a bug :)

Thanks for all the good work!

Release has been made.

3 at the same time! What could go wrong?

Automatically closed - issue fixed for 2 weeks with no activity.