Profiles - Conditional Support for Updating Existing Contact Records WITHOUT User Authentication

Overview
=======
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.

Implementation
============
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.

NOTES:

• 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 -------------
Use case:
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).