CRM-14488 Reserved Profiles should not require the Standalone Form option to be checked

    Details

    • Type: Improvement
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.5
    • Fix Version/s: 4.5
    • Component/s: CiviCRM Profile
    • Labels:
      None

      Description

      Currently profiles used in reserved forms (e.g New Individual, New Household, etc.) need to have the 'Standalone Form and Listing' checkbox TRUE. (This means they have a row in uf_join table where module='Profile')

      However, this means these forms can be exposed unintentionally to spam-bots. We'll prevent unintentional exposure of these reserved profile forms by allowing their internal use WITHOUT the 'Profile' module property.

      Implementation
      ===========
      1. Update new installation meta-data to remove the 'Standalone Form and Listing' property from all reserved profiles (uf_group where is_reserved = 1).

      2. Modify the code which checks whether a profile form can be loaded in create mode to check for either module=Profile OR (is_reserved is true AND user has "add contacts" permission.

      NOTE: I don't think we should change the settings for reserved profiles in the upgrade because folks may be INTENTIONALLY using these profiles as standalone forms.

        Attachments

          Activity

          [CRM-14488] Reserved Profiles should not require the Standalone Form option to be checked
          David Greenberg added a comment -

          The current fix causes profiles which SHOULD be available for 'Standalone' create and edit to throw a fatal error if they have > 1 row in uf_join table.

          To recreate, try and access sample profile gid=1 in create mode:
          (/civicrm/profile/create?gid=1&reset=1)

          David Greenberg added a comment -

          Changes to fix issue when profiles have > 1 row in uf_join table:
          https://github.com/civicrm/civicrm-core/pull/3092

          David Greenberg added a comment -

          The 'Overlay Summary' reserved profile(s) used for back-office on-hover 'VIEW' is throwing a fatal error on CRM_Core_BAO_UFGroup::getFields() - see screenshot

          The $fields array is returning empty now.

          Need to tweak that code to handle the "OK to display is_reserved profile even though it's setting is NOT "Used For = Standalone form or directory" (e.g. there's no row in uf_join w/ module=Profile for that ufgroup).

          Kurund Jalmi added a comment -
          David Greenberg added a comment -

          Summary overlay now works properly. Retested the Reserved condition (New Individual), and the multiple uf_join row condition and all looks good.

            People

            • Assignee:
              David Greenberg
              Reporter:
              David Greenberg

              Dates

              • Created:
                Updated:
                Resolved: