Fixing branded checkout donorDetails

[dr-bizz]

Description

Helpscout: https://secure.helpscout.net/conversation/2439584263/1061424?folderId=7769710

On Unto a client noticed that when we're passing donorDetails to the branded checkout, the values are not being set.
(You set the donorDetails, by adding a window.donorDetails object with the values you want the branded-checkout to add to the form. I've put an example of how to do this below.)

I tested this on my local. The branded checkout grabbed the window.donorDetails object, but was not using its values. Upon further investigating, I found the <contact-info> component was only using the data from the window.donorDetails object if it was the initial load of the form.

The function loadDonorDetails worked out if it was the initial load by seeing if 2 properties were missing from a request to the cortex API, donorDetails.links.rel and donorDetails.links.donormatchesform.
If rel and donormatchesform were missing, it would use the window.donorDetails data.

My best guess is that over the last 4 years (When this code was first added), there was a change to the API, to always return rel and donormatchesform, resulting in the window.donorDetails data no longer be used.

Example:

window.donorDetails = {
        name: {
            title: '',
            givenName: 'First Name',
            middleInitial: '',
            familyName: 'Last Name',
            suffix: ''
        },
        email: '[email protected]'
}
<branded-checkout
      ...
      donor-details="donorDetails"
    ></branded-checkout>

More info here: https://github.com/CruGlobal/give-web#branded-checkout-config

Changes

As we don't want to undo the work on PR-745 #745, I had to ensure overrideDonorDetails only overwrites the this.donorDetails on the form's first load and after that only overwrites when donorDetails properties are empty.

• On initial load, use assign to merge the this.donorDetails returned from the API and overrideDonorDetails. Then set session data afterInitialLoad to prevent any edited fields from being overwritten if the component gets rendered again.
• If session data afterInitialLoad is set and overrideDonorDetails is defined, merge this.donorDetails returned from the API and overrideDonorDetails, favouring this.donorDetails to prevent unwanted overwrites

[canac]

@wrandall22 might want to look at this also, but it looks good to me. Great writeup about the cause of the error!

[dr-bizz]

Yes, I was going to wait until Bill approves it as Give currently has a code-freeze, and I want to ensure no further issues are caused.

[wrandall22]

The only other thing I'm wondering is about users who might go through branded checkout twice in the same browser session. I think before (prior to the EP upgrade), the donormatches link would not exist due to a logout call at the beginning of the process of branded checkout, but in this code, the session storage is not cleared. Maybe we can clear it in the same place that the logout call is made for branded checkout?

[dr-bizz]

No on the initial signout, we remove the initialLoadComplete session storage

[wrandall22]

At this point I think the code looks good, but waiting to hear from product owner about whether we should wait to deploy until after peak giving.

[dr-bizz]

That sounds good.

[wrandall22]

Did you get a chance to test this in staging?

[dr-bizz]

Yes, I have a branded checkout on my local, pulling in the staging branded checkout JS. I tested to make sure the names were coming through and that session storage initialLoadComplete gets removed when signout happens on load and added again after the initial load.

[dr-bizz]

Checked again in staging before pushing to Prod

[dr-bizz]

Updated staging manually