The user hat_trick reported an issue with the REST API user creation, where a new user wasn’t appearing in the database despite a successful response. supermathie pointed out that the active:false response indicates the user already existed, especially if normalize_emails is enabled. RGJ referenced a similar issue, highlighting that the API doesn’t properly account for normalize_emails, leading to misleading success messages. tgxworld acknowledged a documentation error and corrected it, noting that the active parameter only works with admin API keys. hat_trick confirmed the issue was due to an existing user with the same email address, which was not visible in their search due to filtering by username and creation date.
I realised that there is an error in our API docs. The active param is only permitted when an API key associated to an admin user is used and has been the case since 2016.
It still doesn’t address the original problem of the message being misleading for admins though.
○ → curl -X POST -H "api-key: $API_KEY" -H 'api-username: michael' https://try.discourse.org/users.json --json "$(jo email=michael+test@contoso.com username=michaeltest password=$PASSWORD active=true approved=true)"
{"success":true,"active":true,"message":"Your account is activated and ready to use."}
○ → curl -X POST -H "api-key: $API_KEY" -H 'api-username: michael' https://try.discourse.org/users.json --json "$(jo email=michael+test2@contoso.com username=michaeltest2 password=$PASSWORD active=true approved=true)"
{"success":true,"active":false,"message":"Your account is activated and ready to use."}
^ only a single user was created above
I’m inferring a lot of obfuscation was put into the /users.json path to deter spammers etc. but this seems to be making things difficult for admins as well. I wonder if we should add an explicit admin path to separate the two (normal account creation vs. admin account creation) which will allow the admin function to be unobfuscated.