CiviCRM Community Forums (archive)

Profiles are remarkably flexible and in this case I'm getting a bit lost in the flexibility, which suggests that I may be missing something.

On our Powerbase sites, we do not grant anonymous users access to the "CiviCRM: profile listings and forms" permission. As a result, the useful contact checksum feature doesn't work (this feature allows you to send an email to your contacts inviting them to update their own record). This outcome is quite understandable - the checksum feature depends on anonymous users accessing a pre-filled profile and being able to submit it. That logically falls in the "profile listing and forms" permission.

So, that led us to re-consider why we disable this permission for anonymous users.

We systematically disabled the permission when we discovered that several of our sites were inadvertently exposing data to anonymous users via profiles.

It can happen quite easily and goes something like this:

• Create a profile  that is just used for "Standalone Form or Directory" and call it "data entry profile"
• Create fields and carefully ensure that the fields are only visible for "User and User admin only" (say you want to use it for quick data entry)

Now, let many months pass of successfully using a secure form to help you do you work.

Next, discover the super useful feature of using a profile to display search results. Rather than re-creating a new profile, you find that the "data entry" profile would do the trick just perfectly. So you check off the "Search Values" check box and it now is available in advanced search!

Everything is still working fine - no problems and no security issues. However, if you decide you want to edit one of the fields in this profile, the visibility drop down menu will no longer provide "User and User admin only". Instead, the only option is "Public Pages and Listings". It's easy to not notice and simply hit save. If you do that, you have just exposed that field for potentially every record in your database to the world.

Is there a reason why a profile used for search results cannot have fields set to visibility: "User and user admin only"?

The code seems clear in it's intention (CRM/UF/Form/Field.php):

if (in_array('Search Profile', $otherModules)) {
      $visibleValues['Public Pages and Listings'] = 'Public Pages and Listings';
    }
    else {
      $visibleValues = CRM_Core_SelectValues::ufVisibility();
    }

If this could be changed, then I think the problem is solved.

On the other hand, given the complexity of profiles, perhaps there is a reason for it and we need to figure out another solution to this problem.

Any thoughts?

Thanks Dave for the link to http://issues.civicrm.org/jira/browse/CRM-10853 - that's great news.

I'll do some testing with removing that condition that prevents search views from using admin only fields and if it seems to work fine, i'll post an issue.

We = me, not sure if it's covered in the doc, but should be since that permission is a bit too wide open for most sites. Pretty sure we no longer make that a default permission. I don't think there's a way to mark it 'deprecated' with changing a bunch of code since we match on the actual permission title string - but might be worth looking at - or maybe just removing it. Lobo might have a better opinion on this.

4.2   CiviCRM: profile view   ? view just submitted profile?

Seems you also need 'profile view' to see the thank you page on submission of any profile. So essentially, you create is useless without view in most (all?) cases. I think it would make more sense for the thank you screen to exist within the create, or be a redirect to a different kind of page.

.. and the same will be true for profile edit permission in 4.3. The objective is that you can grant ONLY profile create to anonymous and ONLY profile edit to authenticated if you only want the ability for users to create their own record and edit their own record. 'Profile view' would then only be assigned if you are using profiles to create a searchable directory and you want folks who do NOT have 'view all contacts' to be able to view fields exposed by a specific profile for other contacts than their own.

Katy J is correct that in 4.2 'profile view' is required for the create workflow UNLESS you specify an alternate redirect URL in the profile settings (because default behavior is to redirect to profile/view after saving).