Allow users to claim a contact

[TobiasLounsbury]

I have a site where I have pre-imported all the contacts from an old database. What the client wants now is for users to be able to create accounts and modify their data. The problem I have is that there are currently no credentials. So what they need is to be able to have a user go through a registration page (contribution page), select a username and password, supply their external ID and have the resulting UF Account tied to the existing contact record.

I created the contribution page, set it up to create a new drupal username/password combo, and a profile that contains the external_identifier field. When someone tries to "signup" It errors out saying the externalID is already in the database.

Is there a way of setting this up or a hook/series of hooks that I can use to:
 - Check if a contact has a UFMatch and if so return an error to the user saying this account already has a login with it
 - If it doesn't, create the drupal account, create the UF match and allow civi to proceed with creating a new membership record and updating the contact's info?
I'm assuming I will be using the formValidate hook and possibly the dedupeQuery hook, but I'm not sure in what combination or exactly where to start.

Unfortunately, creating the accounts ahead of time is not an option the client has given me, nor do they want to dedupe by hand every account that gets created.

Any advice? Thoughts on other ways to accomplish same thing etc?

[JonGold]

When creating a new Drupal user, a link will automatically be created to an existing CiviCRM user with the same e-mail address.  Will this meet your needs with no further work?

[TobiasLounsbury]

Unfortunately not. The data that is already imported contains an aggregate from data dumps over the last 20 years. Some rows contain a valid email, some contain no email, and some contain an old unused email. The matching needs to take place on the External ID which doesn't change and is present in all records.

[JonGold]

Hmm.  Two things:
Have you tried to set your unsupervised duplicate match rule to be the external_identifier?  Because it sounds like a proper duplicate match would resolve your issue.

I don't know if this is the best approach, but if the first approach isn't an option, then:
* on formValidate, make an API call to (contact, getsingle) on external_identifier.
* If you don't return any records, great!  The default behavior is the intended behavior.
* If you DO get a match, update those fields you're using to determine an unsupervised duplicate match such that this record will be duplicated.  Most importantly, blank the external_identifier field.

I'm 99% sure that formValidate runs before any dedupe function, which I assume runs in the form preProcess.  If it doesn't run beforehand, you might ditch the hook and move your check into Javascript.