Doing this in the RestHelperService is what’s causing the error. That service is not version specific, so when you run the tests it tests against the earliest supported version (OpenMRS 1.9) which does not support the user email property.
This issue should be fixed by adding a method to the user service in core that will allow looking-up a user by email address without authentication (although, honestly, I feel a little iffy about that; in my view, the right implementation of this would be to submit the email address to some kind of daemon service that can do the look-up and send a password reset email if the user if found… Otherwise, we’re creating an API that will allow an unauthenticated user to enumerate all the users in an OpenMRS instance…)
I didn’t really think this all the way through, but I’d probably imagine just having a service class that uses a table as a message queue and something like a scheduled task that consumes them… That could actually go in it’s own module. IIRC, @mseaton was looking into a standard authentication module for OpenMRS where this might be a good fit. It definitely doesn’t go in the REST module.
Dear @mseaton, I was inquiring if I should transfer the endpoint from rest service module to authentication module. Also do we have email notifications implemented anywhere, I want to create a background thread which will sending out a reset password link to the user’s mail within the authentication module
I wasn’t on the TAC call where this was discussed, so would be good to recap what was decided. Did we decide this should live in the authentication module and not in core?
The absolutely simplest thing to do in the short term would be to add an (or fix an existing) endpoint in the REST module for requesting a password reset, where this endpoint would use a limited set of proxy privileges to look up the user and, if there is a valid email account associated with the user, set an activation key and sends the user and email with this.
This avoids the problematic, and undesirable, option of allowing unauthenticated access to what users are in the system, while allowing a targeted, specific use case to work without throwing an authentication error.