User creation via API is a mess!

[Nikki_Locke]

Recent changes to default settings have completely messed up user creation.

1. normalize_emails setting is on by default, which means it is no longer possible to create a user with a + address (e.g. nikki+testuser@example.com).
2. hide_email_address_taken is on by default, which means it is no longer possible to determine the user id from the return of the create user API call.
3. The create user API call returns success even if the specified user already exists, or the email address is duplicate (so the user didn’t get created)
4. The create user API call lies about whether the user is active or not (the active flag does not agree with the message)
5. The Get User By Email call no longer works (admin/users/list/all with email=the user’s email). It returns null for an address containing +, even if normalize_emails and hide_email_address_taken are both off

Can this be fixed so it works consistently and correctly, please?

[Canapin (Coin-coin le Canapin)]

For the record, some of those were discussed here:

User creation API: ‘active’ attribute set to True but returns False in response

[A screenshot of a website settings page with a red box highlighting the "normalize emails" setting. (Captioned by AI)] Yes, it seems that the reason for the failure was the flag normalize_email:true it’s true by default. As I turned it off the users got created… However, the API is not considering the normalize_emails flag and is returning success eventhough the user never got created or activated for that matter Should I report this in discourse github ?

[pfaffman (Jay Pfaffman)]

@Nikki_Locke

normalize_emails setting is on by default

So change it back?

@Nikki_Locke

hide_email_address_taken is on by default,

So change it back.

@Nikki_Locke

The create user API call returns success even if the specified user already exists

That’s the problem with security; it inconveniences mostly the Good People.

@Nikki_Locke

The Get User By Email call no longer works (admin/users/list/all with email=the user’s email). It returns null for an address containing +, even if normalize_emails and hide_email_address_taken are both off

That (and maybe number 4) sounds like a bug, regression, or unexpected edge case.