This is actually a regression that breaks self-service merges of some unactivated accounts. See OOPS-d75371b4ac042f74db8ac30ce3f8e4b8 for a recent example.
But PersonSet.getByEmail was recently fixed to by default exclude NEW email addresses, and unactivated accounts' email addresses are NEW. So this fails to find a person. The issue and proper fix are covered by bug #1014917. We should perhaps for now change that getByEmail call to say filter_status=False.
Admins can work around this by manually setting the account to Active on +reviewaccount, and doing the merge through https://launchpad.net/people/+adminpeoplemerge after verifying ownership.
This is actually a regression that breaks self-service merges of some unactivated accounts. See OOPS-d75371b4ac042f74db8ac30ce3f8e4b8 for a recent example.
sendMergeReques tEmail does this:
dupe = getUtility( IPersonSet) .getByEmail( self.email)
replacements = {'dupename': "%s (%s)" % (dupe.displayname, dupe.name),
But PersonSet. getByEmail was recently fixed to by default exclude NEW email addresses, and unactivated accounts' email addresses are NEW. So this fails to find a person. The issue and proper fix are covered by bug #1014917. We should perhaps for now change that getByEmail call to say filter_ status= False.
Admins can work around this by manually setting the account to Active on +reviewaccount, and doing the merge through https:/ /launchpad. net/people/ +adminpeoplemer ge after verifying ownership.