- π¦πΊAustralia elc
Given how this is used, this is a simpler solution which just sets the password and saves the user account. The simple message is printed if the optional 2nd param is set to true. It doesn't have to be as complex as what was proposed as we don't have to use the same API internally, and doing so added unnecessary complexity.
However, the fboauth module from which this patch request came should really just be calling genpass_generate and then setting the password there as it is already in the process of updating values on a user account at the time.
I'm of the mind that this should be marked as closed, won't fix and that the actual setting of the password and saving of the user should be handled by the other modue. This module provides the secure password as part of their creation of an account.
- Status changed to Closed: won't fix
over 1 year ago 1:22am 5 September 2023 - π¦πΊAustralia elc
This is being changed to Closed (won't fix).
If a clear usage scenario can be stated where this module should be responsible for the creation and saving of the user entity, outside of integrating itself into the "Add user" and user registration forms, then please re-open the issue.
In this case, the source of the patch request is the fboauth module which is already creating the user entity itself - it should be calling genpass_generate, or in newer versions the service password_generator to get a password and then saving the user entity. The logic and control is there, and that's where the entity should be saved.