Emailing Contacts a link to Contribute Page so users details already filled in

[petednz]

So following on from the Post http://forum.civicrm.org/index.php/topic,3905.15.html that helped us to sort out how to send an email with the checksum token so the recipient can click the link in their email and go direct to a Profile that is pre-filled with their Contact Details.

Now I am curious to know if anyone has found a work around for doing similar when sending people to a contribution page.

Scenario: we want to send out a fundraising email, and make it as easy as possible for people to donate without having to login or re-enter their contact details.

So the Contribution Page contains a Profile that shows their Contact Details (and they can update these if need be).

ie we need to send an email with a link such as

http://www3.greens.org.nz/civicrm/contribute/transact?reset=1&id=11

but that achieves what this link does for going direct to a Profile

http://www3.greens.org.nz/civicrm/profile/edit?gid=39&reset=1&{contact.checksum}

[Chris Burgess]

So I pulled some code from CRM_Profile_Edit_Main::preProcess() and threw it into CRM_Contribute_Form_Contribution_Main::preProcess()

And it seems to work. It was disturbingly easy, so I'd like to know what I've done wrong, please!

I added this block after parent::preProcess() in CRM_Contribute_Form_Contribution_Main::preProcess(). All it does is look for a cid (I had to use param "cid" for the contact_id because contribute forms use param "id", which the checksum code does also) and then use $session->set() if the checksum matches.

This appears to work on some quick tests here, but there's a good chance I'm missing something.

However I'd love to get it tested thoroughly, so we can add the facility to link people directly from civimail to a contribute form and have them be automatically logged in.

Code: [Select]

            // make sure we have right permission to edit this user
            $session =& CRM_Core_Session::singleton();
            $userID = $session->get( 'userID' );
            $id = CRM_Utils_Request::retrieve( 'cid', 'Positive', $this, false, $userID );

            require_once 'CRM/Contact/BAO/Contact.php';
            if ( $id != $userID ) {
                if ( ! CRM_Contact_BAO_Contact::permissionedContact( $id, CRM_Core_Permission::EDIT ) ) {
                    // check if this is of the format cs=XXX
                    $cs = CRM_Utils_Request::retrieve( 'cs', 'String' , $this, false );
                    if ( ! CRM_Contact_BAO_Contact::validChecksum( $id, $cs ) ) {
                        $config =& CRM_Core_Config::singleton( );
                        CRM_Core_Error::statusBounce( ts( 'You do not have permission to edit this contact record. Contact the site administrator if you need assistance.' ),
                                                     $config->userFrameworkBaseURL );
                    }
    else {
    $session->set( 'userID', $id ) ;
    }
                }
            }

Very keen for feedback on this! Quite excited that we may have a part of the solution for this one

[Chris Burgess]

This has raised a couple of questions for me,

1. If it's as generic as adding a $session->set('userID', 123); when there's a checksum match, perhaps I could move it into a separate location (eg a Drupal module which gets called for any page, provided that we see $_GET['cs'] and $_GET['contact_id']) and have the entire of CiviCRM become checksum-aware, rather than just profiles. Does this raise any issues?

2. We need to address the fact that checksum functionality uses $_GET['id'], but that this same parameter has different meanings elsewhere throughout the system. For more general use, we'd need this to be a uniquely named parameter so there are no such conflicts. Any thoughts on this?

[Donald Lobo]

1. U probably still want this restricted to a few pages only (frontend pages only?) since its not the most secure solution

2. might want to abstract the code put it into a BAO class, so all frontend pages can use it. The caller can indicate what should be used for contact id (cid?)

lobo

[Chris Burgess]

Thanks Lobo

Our checksum code for the Contribution page is persistent, which allows the visitor to move on to other profile pages and update their details after completing the contribution. The Profile checksum code doesn't do this. The reason for this change is that, unlike the checksum code in CRM_Profile_Form_Edit::preProcess(), our checksum code in CRM_Contribute_Form_Contribution_Main::preProcess() uses $session->set() to store the user ID after the checksum is validated.

So, after visiting the checksum link to a contribution page, the user is able to use other profiles - so don't need to send them back to another checksum page before they visit the next profile. We're happy that our users are able to use one checksum link to visit the site (via a profile, contribute or event page) - it means we can send them through multiple profiles to update various parts of their contact details.

BUT ... perhaps there's a good reason that the existing code in CRM_Profile_Form_Edit::preProcess() doesn't do this. Is it by design that the checksum only takes effect for the first page?

If so - can someone outline the reasons that setting userID into the session might be a bad idea?

And if not - are CiviCRM team interested in having us generalise the change and submit it for inclusion?

[Donald Lobo]

The main drawback of setting the userID in the session is for "public" computers that allow multiple folks access to it. Once the userID is set, the person can edit/view some amount of information via profiles/dashboard which might not be intended behavior. We'll need to figure out how and when to reset it, and also make the userID a "time-to-live" mark etc (something like amazon's "Not Donald A. Lobo, click here"))

any thoughts/ideas on this?

lobo

[Donald Lobo]

chris:

can u please file an issue and a patch for this against trunk. We'll review and incorporate it in 2.2

thanx

lobo

[Chris Burgess]

http://issues.civicrm.org/jira/browse/CRM-3853