volto
volto copied to clipboard
You can't add a user if email login is set in security
Describe the bug You can't add a user if email login is set in security settings
To Reproduce Steps to reproduce the behavior:
- Set email login in control panel > security
- Add user
- if put the email in the user name field you will get an error saying it needs to be left blank. If you leave it blank you get an error that it's required.
Expected behavior No login name field is displayed when adding a user and a user can be added
Screenshots If applicable, add screenshots to help explain your problem.
Software (please complete the following information):
- OS: [e.g. iOS]
- Browser [e.g. chrome, safari]
- Volto Version 16
- Plone Version 6
- Plone REST API Version [e.g. 7.0.1]
Additional context Related issue is that the login dialog doesn't change to ask for email address instead of login name when login by email is turned on
might get fixed as part of #5952 ?
A quick fix might be to remove the clientside validation on the username field if there is currently no easy way to know the security settings when that form is rendered? OR quick serverside fix might be to allow a username that matches the email address.
The form already fetches the usergroup control panel settings. I haven't looked at the details but I would guess it's not hard to make it also fetch the security settings.
Is this why the user name field does not have the required asterisk?
if you leave it blank you get an error that it's required.
This shouldn't happen see: https://github.com/plone/plone.restapi/blob/5cf1418e928f143ef1b42fdc3e4ed72a3126e9dd/src/plone/restapi/services/users/add.py#L69-L71
What version of plone.restapi
are you using?
It appears that this is mostly a Volto 16 issue, as in Volto 17 we use the userschema to display the fields where the username field isn't required so can be skipped over. I've included screenshots below showing the difference in an out-the-box Volto experience
Add user form in Volto 16
Add user form in Volto 17
However, it still isn't ideal that this field is display. I did look into adding the use_email_as_login
option to the userschema, but I don't this makes sense as the userschema can be used elsewhere and the option isn't really linked to users. I think it would make sense to include the use_email_as_login
as part of the @site
endpoint as it's more of a global setting which could make sense to be used elsewhere (for example, in the Login form as mentioned in the issue description). This would also be a suitable place for the other public security settings like enable_self_reg
.
@djay @davisagli Any thoughts on this?