Type: New Feature
Affects Version/s: None
Fix Version/s: 1.3
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 (
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
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