Profile Modifications to Support Linking UF_GROUP instances to Different Modules and Object Instances (e.g. Contribution Pages)

Overview
========
These modifications support the use of Profiles (uf_group instances) to 'extend' multiple edit and display contexts (including the current User Registration and User Account cases, CiviDonate Contribution pages and 3rd party modules).

Each Profile (uf_group instance) can be linked to one or more modules and / or entities - using the new uf_join table. For CiviDonate, we can have a many-to-many join - so uf_join will link a specific contribution_page instance to one or more uf_group instances.

We will re-factor the existing User Account, User Registration, and 'Profile' (search/listing/view) implementation by aggregating each these as 'modules' (display contexts) with one or more uf_join table entries.

Thus, uf_group instances aren't 'automatically' included in all display contexts - they are included based on the uf_join table entries.

• Any uf_group which is to be included in the User Registration form, will have an entry in uf_join with module='User Registration'.
• Any uf_group which is to be included in the User Account edit form/view page, will have an entry in uf_join with module='User Account'.
• For the profile/create and the profile search forms - we will use module="Profile".

The current admin UI (admin/uf/group) will still list all uf_group instances - and support maintenance of join table instances for the 3 user/profile related modules (details below). Management of links (uf_join table instances) used by other modules (e.g. CiviDonate's Contribution pages) will be handled by those modules.

uf_group weights will be migrated to uf_join - since display order may be relative to the display context. However, the UI may not support this level of granularity in all cases (details below).

Examples of selecting uf_groups by context:

• CiviDonate Contribution Page:
  SELECT uf_group_id FROM uf_join WHERE entity_table = 'civicrm_contribution_page' AND entity_id = '$contribution_page_id'

• User (Account) Registration (module does not use entity_table/id):
  SELECT uf_group_id FROM uf_join WHERE module = 'User Registration' ORDER BY weight

We will also move the configuration of duplicate-checking rules into it's own class and UI (uf_field.is_match will be eliminated). Details for this are covered in a separate Jira item (CRM-544).

Profile Modification Tasks
=====================
1. Update sample data

• insert 3 uf_join records in the sample data with uf_group_id = 1 (these will link to the sample 'Constitutent Information' profile)
• set module = 'User Registration' for the 1st record, module='User Account' for the 2nd, module='Profile' for the 3rd
• set weight = 1 for all 3 records
• populate uf_join.module = 'CiviDonate' for the two existing uf_join sample records (these have entity_table = civicrm_contribution_page)

2. Modify the form and page code for User Registration, My Account, and Profile (create and listings) so that each context only uses the uf_group instances marked with the corresponding 'module' name.

EXAMPLE: the uf_group instances (fieldsets) displayed from the user/register path are limited to the groups that have uf_join entries with module = 'User Registration'

3. Admin (display and update) of uf_join records
Modify the UI and processing in admin/uf/group to support add/delete/view of uf_join instances for the three existing use cases (register, user account, profile), and view only for other uf_join instances. Weight will be 'forced' to be the same for a given uf_group in any of the 3 possible uf_join instances.

3.1 New Profile / Edit Profile Settings (admin/uf/group?action=add / update)

• Create a new checkbox 'group' field for this screen (displays after Profile Name...
  Used for: [ x ] User Registration [ x ] View/Edit User Account [ x ] Profile (Add Contact and Search Listings)
• By default, all 3 are checked (when action=add)
• In 'update' mode, also display a read-only checkbox for each active row in uf_join that is owned by another module, e.g. [ x ] CiviDonate
• Form processing for this set of checkboxes needs to conditionally add or delete rows in uf_join depending on the values submitted.
• When action=add, default value of 'Weight:' field is derived from uf_join table:

select( MAX(weight)+1) as new_weight from uf_join where module='User Registration' or module='User Account' or module='Profile'

• When action=update, retrieve Weight: field value by getting MAX from uf_join:
  select MAX(weight) from uf_join where uf_group_id = $_this->id AND (module='User Registration' or module='User Account' or module='Profile')

• Form post-process should set uf_join.weight to the submitted field value for any inserted/updated uf_join records.

3.2 Profile Selector (uf/group?action=browse)

• Display uf_join modules linked to each uf_group in the table under a new selector column ('Used For'). Separate module names with a line break:

Profile Title Used For Status Weight
-----------------------------------------------------------------------------
Constituent Info User Registration Active 1
User Account
Profile
Contribution Pre CiviDonate Active 1

4. Eliminate the uf_field.is_register property / DB column / form field / selector column.

• This field level property is no longer needed. All uf_field contained in uf_group 'owned by' the User Registration 'module' are included in the form/page display.

5. Eliminate the uf_field.is_match property / DB column / form field / selector column. (Replacement functionality covered in CRM-544).