Site administrators want the option to offer Profile forms which handle both creating and/or updating contact records regardless of whether the person filling out the form is a CMS user AND regardless of whether they are currently authenticated. (Current behavior when a duplicate contact is detected on submit is to throw a duplicate error and abort the processing.)
Allowing unauthenticated people to update existing contact records has significant risks, so we need to make this new behavior conditional by Profile.
1. New boolean (tinyint) column for civicrm_uf_group (Profile Settings) : is_update_dupe. Default is false.
2. New field for Add/Edit Profile Settings: "Update on Duplicate Match"
3. When processing profile/create forms, IF a duplicate match is found check the value of this flag. If is_update_dupe = false, return the duplicate contact error message ("... account exists...") and abort (current process). If true, update the first matching contact with the values from the Profile form.
- This new processing rule applies regardless of whether there is an authenticated user session - and therefore should handle the scenario described below.
- The is_update_dupe=true processing is how we currently handle the matching contact case when an online contribution is processed.
— Original post from D Geilhufe -------------
Organization has 5000 records in DB. Send email to all 5000 asking them to provide their postal code if they are interested in participating in a training in their town. Also publicize link to profile on websites, etc. Hyperlink to a CiviCRM profile that collects email address and postal code using the /edit/ option.
Some visitors are in the DB already. Some are not.
Goal: Allow every visitor to successfully complete an email postal code submission.
Scenario 1: User in the database, but not logged into user framework.
Entry fails. User not directed to login, just gets error message about duplicate record.
Scenario 2: User in database and logged in to user framework
Entry succeeds, editing existing postal code if any.
Scenario 3: User not in the database.
Entry succeeds and creates a new record.
We need a solution for Senario 1. My suggestions:
(1) Turn off dup checking on a per-profile basis. This allows you to capture duplicate information into a specific group and then latter merge the information back into the "official" DB via duplicate checking/merge functionality.
(2) In addition to /create/ and /edit/ offer an /update/ URL. If you use the /update/ profile URL, data is simply updated in the db if there is a duplicate.
I vote for (2).