innocenceproject / collective.salesforce.fundraising Goto Github PK

The Campaign Timeline shows where the campaign is at in comparison to its start and end dates. The element is only displayed if there is a configured Start Date for the campaign. If there is no configured end date, instead show a counter of how many days have elapsed since the start of the campaign. If the current time is before the Start Date, the element should display the number of days until the campaign starts. If the current time is after the End Date, the element should show that the campaign has now ended.

There are 2 ways this could happen:

1. The Donation Fundraisers portlet currently does no checking if the user already has a personal campaign page for the campaign before showing the link.
2. If a user created a page, then returns but does not log in, they will see the link to create a personal campaign page. Clicking it will bring them to the login page, then back to the form. Instead, once a user has logged in, they should be redirected to their campaign if one exists.

The Campaign Goal element shows the current status of the campaign towards reaching its goal. It is only shown on a campaign with a set goal and which has raised above a configured threshold.

After getting really excited that Authorize.net's DPM would eliminate any PCI issues, I discovered that it doesn't work with ARB or CIM. Thus, there's now way with DPM to handle recurring donations.

I settled on using Recurly (http://www.recurly.com) which seems pretty reasonable option. Their recurly.js library and the python library published on pypi make a PCI compliant integration to manage recurring billing pretty easy. Since they charge 1.25% plus $.10 on top of merchant account fees, it still makes sense to use Authorize.net's DPM for one time donations. There's a $69/month minimum.

A goal of the system was to keep credit card data far enough away from the system to allow for PCI SAQ A. Using DPM and Recurly seems to accomplish that goal.

Initiating recurring donations in Recurly requires the following changes on the python side:

• Control panel fields for subdomain, api key, and private key
• Control panel field for plan code. * NOTE: This should probably be changed to be set per campaign for great flexibility
• A view method to generate a signature for the javascript which is passed through the view's template. The method just needs the plan name and the recurly python library
• A view to receive the post callback after successful subscription creation. This method receives a token via post. The recurly python library can then be used to fetch the subscription details from the Recurly API and redirect the user to the thank you page.

On the javascript side, loading the Recurly form is pretty simple. You pass some config variables and a jquery selector of where to place the form and the form is injected into the page's html. The form html is very elegantly structured with good selectors allowing for easy customization.

There is a Salesforce integration available from Recurly but it is an additional monthly charge. I still need to figure out how to integrate the payments and subscription profiles.

The recurly.js library also allows for creation of Update Subscription forms allowing users to update their billing information from your website while keeping all credit card data flowing through PCI Level 1 channels. Integrating subscription updating should be on the list as well.

Currently, doing a copy in Plone of a Fundraising Campaign creates another campaign with the same sf_object_id and doesn't create a new campaign in Salesforce. This should be handled better as it would also not be good to have 2 Fundraising Campaign objects with the same sf_object_id as much of the code assume a lookup by sf_object_id will only return one result.

I have no explanation for why this is the case, but it requires a reindex of the catalog after reinstall

The initial design of the system was based around collective.salesforce.content with the assumption that campaigns would originate from Salesforce and be pushed to Plone. However, in practice, it has proven to be much easier to manage campaigns from the Plone side. There is no longer functionality which relies on collective.salesforce.fundraising.

Part of this implementation should include a way to sync campaign values (total donations, donation count, etc) from Salesforce to Plone.

not used currently but still a requirement for some reason

Create a simple diazo theme product optimized for running collective.salesforce.fundraising as a standalone fundraising site. The theme should use the non-proprietary portions of ip.theme.fundraising including the responsive design styles and provide a baseline for building a fundraising oriented theme.

Currently, a Donor Quote has its own image field that's not really integrated with anything else. In order to increase the odds of having a good image with a quote which makes it much more effective, we should add the following:

• When adding a quote, automatically use the user's Portrait from their profile if available allowing the user to override the portrait with a new file if they wish
• If a new image is uploaded, store it as the user's Portrait (this is a bit subjective but seems to make sense in the context of the system)
• Add a site default profile pic to fall back to if no image is found

The beatbox library is starting to have errors which seem related to recent changes in the Salesforce API. No one is maintaining the library. It uses SOAP. The new simple-salesforce library is much cleaner and uses the REST api. Switch to it.

If the fundraising.js script is marked for compression in portal_javascripts, running in non-development mode causes a syntax error about missing }.

Easiest solution is to change installer to mark fundraising.js for no compression

The Donor Quotes page element displays a randomly selected (possibly rotating) Donor Quote for the current campaign. If no quote exists and the campaign is a Personal Fundraising Campaign, quotes are selected from the parent Fundraising Campaign. If no quotes are found for the Fundraising Campaign, the element is not displayed.

I'm thinking it probably makes sense to create two packages from this:

• collective.rpx.auth
• collective.rpx.share

The share package would contain all the methods for initializing the javascript sharing widget with a custom title, description, url, image, and initial user comment (can be edited by the user). This is a much more flexible alternative to using the Facebook meta tags as you can have different messages pointing to the same page. The drawback is that the end user must grant rights to your FB app.

Add a new view on a campaign that lists all its donor quotes in a paginated list. Create a public view of each quote with the donation form below the quote. Include a share button on the donor quote page, mainly for the donor to share their quote with friends.

This will allow for any display template to be used on the page while still retaining the fundraising functionality.

What the title says

When you add a personal campaign, it's not obvious that you need to publish it before anonymous visitors can see it. Should we make it get published immediately?

In a related question, is there any reason for the green edit bar to appear for people who are only logged in to add personal campaigns? Should I find a way to hide it for them?

When attempting to edit donor quote, the Title field is required but not relevant and the Description field is not relevant though not required. The Campaign Salesforce ID field is also not being populated causing an error on edit as it's required.

Currently, after a donation, a Person object is created in the background automatically with a random password which is never sent to the donor. The donor never sees the password or even knows they have a user account on the site in the background. This was done to make it easier to sync Contacts via add/edit event handlers on Person.

However, the new Donation object captures all the data needed to sync with Contacts making the creation of a Person object unnecessary.

For now, the Person object should remain for the purpose of personal fundraising.

With DPM, auth.net's servers post back the transaction info which is used to create the Salesforce data. Since the source info is cached in a cookie in the client's browser, the postback from auth.net's servers doesn't have the cookie. Thus, while the client's browser has the correct source info, it's not available at the time of creation in Salesforce.

The source url and campaign should be passed as custom fields in the DPM form and parsed out of the postback from auth.net.

The default form tabs when creating a new Fundraising Campaign is being split as a string instead of as a list producing one letter per line as opposed to one line per line.

The Thank You page is shown to a donor after they have donated. They are presented with a configurable Thank You message for the campaign as well as with options to amplify their donation by taking the following actions:

• Share with friends
• Create a Personal Fundraising Campaign
• Provide a Donor Quote along with an optional photo and name

The Campaign Counts element shows counts relevant to the campaign such as the number of donations, the number of personal fundraisers, ???

Since the form embed code is inserted inline, it can block the page from loading if formstack is taking a while to respond. We could avoid this by inserting the embed code using javascript after the page has loaded.

It appears that collective.salesforce.content is syncing the personal campaigns first which results in an error if the parent Fundraising Campaign hasn't been created yet. This makes sense since personal campaigns are stored inside their parent.

Current, it creates a new user if none is found. Since any site using this package for personal fundraising would want to have registration enabled anyhow, I'm not treating this as the highest priority

Recurly integration was implemented with the old method of directly writing to Salesforce rather than writing donation data to Plone. That method is no longer recommended. The new method was implemented as part of Stripe integration.

It seems as though Recurly may be useful in more international use cases such as the Plone Foundation and thus should be brought forward to the new process (unlike Authorize.net DPM which should be removed soon).

Or, a more elegant solution but for now, this would work as a hack. The code expects to be able to place people objects inside /people

The Fundraising Campaign type should have fields allowing the admin to set messages used on views as well as default values presented to the user for personalization. The following fields are needed:

• Thank You: The content body of the Thank You page thanking the donor. Should provide a sensible default text
• Personal Campaign - Thank You: The default for the Thank You field when creating a personal campaign
• Personal Campaign - Pitch: The default for the Pitch field when creating a personal campaign

Invalid card object: must be a dictionary or string

Caused by multiple tokens being sent to backend as a list instead of a single token as a string. Tokens from failed requests should be removed on failure.

Simple implementation when syncing the Donation (Opportunity)

Currently, a Personal Campaign Page sets the creator correctly if created from Plone. However, if the campaign is setup in Salesforce, the creator will be the user running the collective.salesforce.content sync rather than the actual user. On sync, the email of the contact should be used to set up the creator on the new object in Plone.

This is a lower priority as I don't anticipate a need to create personal fundraisers from Salesforce.

Many nonprofits support multiple donation funds allocated towards different purposes. The system should support optionally assigning a donation campaign to a fund.

This change was brought about by 2 requests. First, we wanted to be able to show on the receipt if a donation was allocated to a specific fund. Second, we wanted to allow a donor to donate a recurring donation to more than one fund which was currently not possible as the Recurly integration assumes there is only 1 plan for recurring.

The concept of this feature proposal is that a nonprofit maintains a general fund with no specific allocation as well as possibly maintaining dedicated funds for donations allocated to specific uses. Since most nonprofits would prefer donations to a general fund due to the flexibility, it is assumed that most campaigns will be towards the general fund. Keeping with the philosophy of launching a normal campaign as fast as possible, if a campaign is towards the general fund, no value has to be provided for Fund when creating a campaign. A value only needs to be provided if making a non-standard campaign (i.e. a campaign designated to a specific fund).

The following changes need to happen to achieve this functionality:

• Add new Fund__c field to Campaign in Salesforce
• Map the Fund__c field in Salesforce to the "fund" field on Fundraising Campaign
• Add a field to Fundraising Campaign for Recurly Plan Code. If no value is provided, use the global value in registry
• If Recurly is enabled, create a new plan via the Recurly API whenever a new fund name is found and add the new plan's code to the Recurly Plan Code field on the campaign
• Include Fund on the donation receipt if a fund was specified.

Authorize.net's Direct Post Method is designed to allow developers to build custom html forms with the user experience they want for their users while still keeping credit card data from being transmitted by the developer's system and thus avoid PCI headaches. DPM requires the form contain fields with a transaction fingerprint generated by server side code. The fingerprint is a combination of the API Login ID, transaction id (generated by developer), current UTC timestamp, and amount of transaction. The form fields must also conform to the field names for the DPM service. When the form is submitted, the submissions goes straight from the user's browser to Authorize.net without ever contacting the host system. Authorize.net then calls a callback url to notify the host system of the transaction ad expects a response back with where to redirect the user. Once the response is received, Authorize.net issues a redirect to the client's browser. The client's browser should remain on the host's url and never show authorize.net in the process yet remains fully PCI compliant.

DPM also has full support for Automated Recurring Billing (ARB).

Full docs here:
http://developer.authorize.net/guides/DPM/wwhelp/wwhimpl/js/html/wwhelp.htm

Requirements:

• A view for fundraising campaigns and personal campaign pages to render the form. The form html should come from the prototype developed for ip.theme.fundraising.
• Register and include all css and js from ip.theme.fundraising relevant to the donation form.
• A view to render the transaction fingerprint. DPM normally assumes a shopping cart type checkout process where items are selected, then the checkout page is called for payment details on the selected items. Since the cart is not changed on the payment page, the fingerprint can come from the server at time of rendering the form. However, in the donation form, the amount and payment details can be edited in the same place. Javascript should call this view whenever the amount field changes to get a new fingerprint and insert the fingerprint values into the appropriate fields on the form. While this ajax call is taking place, the form should not be able to be submitted to avoid submission with an incorrect fingerprint.
• Since the form will never send back data, I don't think it makes sense to use a form framework for this. The form doesn't need to know its state. Validation can be handled for most fields via javascript so it occurs client side.
• A callback view where Authorize.net will submit payment details (minus cc info) and expect a url in return where the user's browser should be redirected.
• Figure out where in this process to upsert the appropriate Salesforce Contact, Opportunity, OpportunityContactRole, and CampaignMember

One open question is how to handle errors such as invalid credit card numbers. I'm sure the documentation covers this in the response sent to the callback url, but I haven't found it yet in my scanning of the docs.

This needs to be researched and defined in more detail, but the general idea is to keep control at the parent level as much as possible to allow changing all personal campaign pages inside a campaign in one place where appropriate. Also, use the override pattern wherever possible rather than storing default text with each instance.

Currently, the Fundraising Campaign is designed to be created first in Salesforce and then appear in Plone after collective.salesforce.content syncs the Fundraising Campaign type.

Given that there is additional content to edit on the Plone side when setting up a campaign, it makes sense to allow for creating a campaign from the Plone side and having the corresponding Salesforce Campaign automatically created.

This should allow default text to be changed in one place for all campaigns using the default text.

Build an integration with the HEPdata web services to enabled lookup of employer matching donations on the Thank You page

Leading up to the launch of the Innocence Project's new fundraising site, a lot of css and javascript development was done to improve the user experience. However, much of that work was put into css and js files in the private ip.theme.fundraising package.

The js and css that are relevant to the open source package should be moved into the open source package.

The owner of a Personal Fundraising Campaign can access this page to help them promote their campaign to their network of people. Each Fundraising Campaign will have sharing messages configured by the administrator with a title, description, and image. Users can select from a message to send, then select where to send it (Facebook, Twitter, Email).

i.e. it's showing 66% even for a personal campaign that hasn't had any donations yet

A campaign running in test mode should show a big warning message that it is in test mode.

The new Janrain share widget is out and has a much nicer UI as well as better functionality. Specifically, users can now select their friends from social networks and post directly to their friends wall. Also, if you have a Pro account, you can share via email in the same widget.

It doesn't show up under Add Items despite the fact that it's in the allowed types

When pulling up the edit form on a Fundraising Campaign to enter the fundraising content for the campaign, the values in the Goal, Total Raised, and Direct Total Raised fields are shown with commas and a trailing .0 which causes validation errors when saving. This can be worked around by removing the commas and the .0 but it's a pain.

I verified that even after setting the values manually on the object in Plone and not running the SF sync after the change, the same problem occurs. Thus, I think it's something inside of Plone rather than a type mapping issue in collective.salesforce.content.

Create the post_fundraising_payment view available on the site root. The view should accept a campaign_id and an amount.

The amount should be added to the campaign's donations_total and donations_count fields to instantly display the donation's amount added to the campaign's total in Plone. The next sync from SF will overwrite this value with a more precise value (i.e. including offline donations and refunds since the last sync). If the campaign is a child of another campaign, also add the amount to the donations_total and donations_count fields of the parent campaign (assume only a 2 level campaign hierarchy).

Then, redirect the user to the campaign's thank-you view

The Thank You Page is currently hard coded. It would be nice to use a viewlet manager to allow easier configuration of what shows on the page and in what order.

This page allows a Personal Fundraiser to view a list of who has donated to their campaign. The goal is to encourage the fundraiser to send personal thank you emails to their donors. Fundraisers should be able to see who they have sent to and who they have not sent to. The status is manually changed by the fundraiser after they have sent an email.