Bring back an option for Add Users / New user the old way #19772
About twice a week we get an email asking for the old way. Could this be present as an option?
" The new 'send an invite' for my client to choose their own password isn't necessary and just adds extra painful steps."
"My clients access their stats without ever needing to know their password as they access them in the admin area of their Content Management System which is where I put in the integration to Matomo for them. It also generates a lot of emails for me which are unecessary saying they have accepted their invitation etc - they haven't - I have accepted for them as I'm jumping through email hoops to just set a password! Annoying!"
The text was updated successfully, but these errors were encountered:
It's obviously a better security practice to have users set their own password in a secure session rather than have someone else enter a password for them and then send it (insecurely) to them. It sounds like this might not be the best approach for every scenario though.
Perhaps invite user should be the default but with an additional option (with a warning about security risks) so that an administrator can directly create the user and set a password? (maybe Matomo should suggest a quality password?). This option could then also be disabled by a config setting for sites that need to enforce high security.
A non technical user asks
"I try to create a new user but this person never receives an activation email. I tried to return and even to recreate the user but it does not change anything. I am not a developer and I am not the person who installed Matomo within the company. We don't manage ourself the exchange server of mail but I can tell you that we also use MailInblack as a solution to filter the mails and the account creation mail doesn't even reach them while it did for others.
@jane-twizel this might be something we could work with Product Team on to define and deliver. If it wasn't a bit of a trade off between security and usability we might be treating this as a regression since the feature makes some valid use cases no longer possible.
There is another use-case that doesn't work anymore. If you're using the LoginLDAP plugin, and you e.g. want to create "external" accounts for the web/seo/marketing agency (which are not in your LDAP), then you'd have to enable the Login plugin.
But you can't use both plugins at the same time ("Warning: Both the Login and LoginLdap plugins are enabled! This will cause logins for LDAP users to fail, please disable the Login plugin.").
Just in case it is helpful in thinking about the User Experience, here is a sysadmin with their specific details:
Sometimes this command works: "./console core:test-email firstname.lastname@example.org"
Old way is also better for us for the following 2 reasons: