UsersController.updateUser and ProfilesController.updateProfileById in application/backend/src/controllers/ let an admin (OrganisationAdmin or StudyAdmin) update any of a user's or participant's fields — email, firstName, lastName, role, dob, mobile, address, next of kin, and so on. Neither endpoint sends any notification to the affected user (old or new email).
The user has no way to know their info was changed. If it's the email that got changed, they only find out when their next login attempt with the old address returns "invalid credentials".
Users cannot self-change their own email today. ProfilesController.updateCurrentProfile only writes firstName and lastName to the User table even when the body includes an email, so email changes are admin-only. That makes silent admin changes more concerning than they would be in a system where users can also update their own email.
Related to #928 which flags the same silent behaviour on password reset completion.
Suggested fix: on any admin-initiated change to a user's profile, send a notification email. At minimum on email changes, notify both the old and new addresses ("Your CTRL email was changed. If this wasn't you, contact support."). Other field changes can either share a single generic "your profile was updated by an admin" notification or notify per-field, depending on how noisy the team wants it.
UsersController.updateUserandProfilesController.updateProfileByIdinapplication/backend/src/controllers/let an admin (OrganisationAdmin or StudyAdmin) update any of a user's or participant's fields —email,firstName,lastName,role,dob,mobile, address, next of kin, and so on. Neither endpoint sends any notification to the affected user (old or new email).The user has no way to know their info was changed. If it's the email that got changed, they only find out when their next login attempt with the old address returns "invalid credentials".
Users cannot self-change their own email today.
ProfilesController.updateCurrentProfileonly writesfirstNameandlastNameto the User table even when the body includes an email, so email changes are admin-only. That makes silent admin changes more concerning than they would be in a system where users can also update their own email.Related to #928 which flags the same silent behaviour on password reset completion.
Suggested fix: on any admin-initiated change to a user's profile, send a notification email. At minimum on email changes, notify both the old and new addresses ("Your CTRL email was changed. If this wasn't you, contact support."). Other field changes can either share a single generic "your profile was updated by an admin" notification or notify per-field, depending on how noisy the team wants it.