Hi there everybody,

we are using the iRedAdmin Pro version 5.6. About 6 weeks ago, we upgraded from 5.5 and didn't see any issues, until today.

We are using the REST API provided by iRedAdmin Pro in order to reset user passwords (Mail User > Update profile of an existing mail user). This was done by sending a PUT request with the field password=<newpass> to /api/user/<account>. So far so good, worked for months. But since our update to iRedAdmin 5.6, it seems that the behavior of the API has changed, we got multiple complains that users who reset their password cannot login to their accounts.

After some troubleshooting we found out that the reason for this was that the users accounts were disabled. We could not explain this at first but after some more research we found the reason for it: Apparently, since the new version 5.6, when the field accountStatus=active is not send in the request, the account is automatically disabled, propably because the default value is "disabled". This did not happened before. We could re-produce this via basic curl requests:

Login:
curl -X POST -c cookie.txt -d "username=<username>&password=<password>" /iredadmin/api/login

Account password gets changed AND is disabled:
curl -X PUT -i -b cookie.txt -d "password=<newpass>" /iredadmin/api/user/<mail>

Account password gets changed AND it stays/becomes active:
curl -X PUT -i -b cookie.txt -d "password=<newpass>&accountStatus=active" /iredadmin/api/user/<mail>

We got a hint by looking at the admin event logs. Since the update, the events for User modifications contain 4 additional fields which we never set, neither before nor after: active: 0, language: "", employeeid: "" and transport: "" (See attachment api_calls_comparison.png). We believe the root cause to be "active: 0" as this makes the most sense and in our reproduction of the error, this fields value was set to 1 when the API call contained accountStatus=active (see attachment api_calls_reproduced.png).

When we updated in November and troubleshooting today, we checked the release notes and API documentation but could not find any mentions of this changes. In fact, the API documentation does not disclose the information what fields are mendatory and what the default values of the fields are if they are omitted. The provided sample values are more confusing in that regard since one could think that those are the default vaules, for accountStatus the example value is active which, as we saw, is the opposite from what is actually happening.

I consider this a potential dangerous change to not mention it or mark it as important, since, as happened with us, accounts can become unintentionally modified or made temporarily unusable. Also, if feels very unintuitive to change the password of a user and to disable it at the same time since the most common use cases to change the passwords are if a user forgot it or they set an initial one. In both cases, the user wants to login right afterwards.

My questions regarding this are:

* Was this mentioned somewhere else were I just missed it?
* Is there a more detailed API documentation regarding default values, changes, etc.?
* Is this potentially a bug?
* Can I change the default values of fields which are omitted in API requests?
* Can the API bahavior in general be changed so that only fields are modified which are set within the request?

Thanks a lot everybody