-
-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating new User requires Email support #763
Comments
👍 Please note that UserFrosting checks to make sure that a user does not have an empty password when they try to log in. So, right now when an admin creates a new user, it sets the password to I think we could just have the option to manually set a password when the admin creates the account (actually, this used to be the only way in V3 😱 ) We could bring this back, along with a "suggest password" tool that generates and displays a random value to the admin. Obviously this is not a good choice to use in production, but I can see how this would be useful in development/testing. |
As discussed in chat earlier, a solution would be to merge the existing "create user" with "change user password" form. When creating a user, the admin could select to enter a password or use the default email mechanism. |
I concur, This was something Alex and I discussed. I forgot to add the comment here. However, it has been incorporated into my PR here #764 |
Fixed in #1017 |
When creating a user in the admin dashboard UF currently enforces the use of email. If your config is missing or incorrect the creation of the user fails. This can be an issue for development as the developer may have chosen to not setup email support. I do this frequently for a few reasons.
Solution
Allow the user to be created with an option to not send an email. In which case a random password would be generated. A second possible solution, if email was opted out, create the user and leave the password blank. The user would remain inactive and the admin would have to manually (re)set the password and then enable the user.
This would of course leave 'flag_verified' as negative and flag_enabled as negative to start. However, if email was opted out, simply mark 'flag_verified' as 1 for true. Manually enabling the account would set the 'flag_disabled' to 1.
This would allow for for expansion into a 'customer' type model or simply easier on the developer lol.
The text was updated successfully, but these errors were encountered: