Allow 'on behalf of' form to use a profile

Summary: Replace the hard-coded OnBehalfForm form with a reserved profile which supports Contact, Organization, Contribution and Membership fields (including custom fields for each of those record types).

Implementation
===============
1. Insert new reserved profile (uf_group):

• title: "On Behalf Of Organization"
• name: "on_behalf_organization"
• type: Contact, Organization, Contribution, Membership
• default fields for this profile: Organization Name, Primary Phone, Primary Email, Street Address, City, Postal Code, Country, State / Province

2. Modify form building and postProcess code for Online Contribution pages to replace CRM_Contact_BAO_Contact_Utils::buildOnBehalfForm with the reserved profile fields

• Note that there will potentially be 1-2 profiles embedded in 'Main' which are bound to the individual who is submitting the form AND then the new reserved profile which is bound to the on-behalf organization and it's contribution / membership. Post process will be creating or updating the following records:
• individual contact (form submitter)
• organization contact (on behalf profile)
• contribution by org contact (main form + on behalf profile contribution fields)
• membership for org contact (main form + on behalf profile membership fields)

• • • IMPORTANT *** For this iteration, we will separate out the logic for "Related Contact" editing (CRM_Contact_Form_RelatedContact) and leave that as is (using hard-coded form). However we'd like to fix that code as well to use profiles (we'd need 3 additional reserved profiles since all 3 contact types need to be handled). Keep track of time on this issue and if we have sufficient time after completing the On Behalf implementation (including new tests), then we can re-evaluate and potentially also handle the Related Contact form.

3. We need to handle several cases related to self-service membership renewals when On Behalf is enabled:
3.1 IF we have a logged in (or authenticated via checksum) user with an existing permissioned relationships to one or more organizations that have a membership supported by that page's membership block.
3.1.1 If user has exactly 1 permissioned relationship with an organization that has an existing membership, we should set the following defaults to simplify the UI for them:

• • check the OnBehalf box
  • Hide the "Create New / Select Existing" radio button and replace with read-only field:
    "Renew Membership for: $organization_display_name" and prefill on_behalf_organization profile fields with values for that organization / membership.
  • Add link "Create new organization" next to that field. When clicked clear profile fields and hide the read-only field which was displaying the existing organization name.

3.1.2 If user has > 1 permissioned relationships with organizations OR the organization(s) they are permissioned on do not currently have any memberships - we can retain the existing interface (radio button Create New / Select Existing). However let's reverse the order of those options and set "Select Existing" as the default since it is most likely that they are submitting this for an organization they are already related to.

3.2 Anonymous user submitting an on-behalf membership for an organization that matches an existing organization that has a membership.

• In this case we should renew the membership (and change membership type if a different type has been selected). I think we handle this one properly already, but we need to verify

— Original Post ----
There has been quite a lot of demand for the ability to select a profile for organisation when the 'on behalf of' form is presented -e.g.

http://forum.civicrm.org/index.php?topic=13440.new;topicseen#new

This would allow the administrator to determine which fields (including custom fields) they wish to gather for an organisation signing up for a contribution or membership.

People have been writing work arounds (e.g. the work Web Access did for Stoob which I believe is documented on the wiki) and custom hooks but ideally this would be configurable as part of core civicrm & I am logging it so that it is 'on the roadmap' as suggested in the forum.

I am aware that the priority of this will depend on people submitting code / donations / sponsorship and invite people to add comments here if they are prepared to do so.