thinkshout / redhen_donation Goto Github PK

Donations are fieldable entities. Donation Types are the bundle for Donations.

Donations should extend ContentEntityBase and have the following properties:

• donation_id -- unique numeric ID, primary entity ID
• entity_type -- Type of entity that the donation was made from (usually "Node")
• entity_id -- ID of the entity the donation was made on
• pledged -- integer amount (in cents) promised for this donation (usually same as "received", but not always, if any of the payments are pending)
• received -- calculated field. Sums all donation payments associated with
• created -- timestamp
• updated -- timestamp
• donor_entity_type
• donor_entity_id

Paths should follow predictable patterns:

Donations should be listed at
reports -> redhen donations

Donations should also be listed on the content where they were created. So, if a node is able to take donations, it will have a tab next to its "edit" tab called "Donations", which itself has 2 tabs: a listing tab and a settings tab.

Dev

• Create Donation entity
• Add properties to donation entity
• Remove standard "add" page for donations (they can only be added from Donation-enabled entities)

Generating notices on FH.

http://cgit.drupalcode.org/redhen_donation/tree/lib/redhen_donation.metadata.inc#n117

Also, the getter callback for transaction_entity has a typo in transaction.

On lines 890 and 922. No clear reason.

fork the redhen_dev repo
base on https://github.com/thinkshout/drupal-project
Include a working version of redhen_donation 8.x-1.x branch created in #14

This is a FieldFormatter that outputs the contents of a Donation Type Field (#17) as a from form creating the appropriate type of Donation. Note that most examples of FieldFormatters will NOT be outputting Forms, this is an unusual usage.

Initialized at src/Plugin/Field/FieldFormatter/DonationForm.php

Dev

• Create a FieldFormatter plugin donation_form.
• Add configuration for the formatter that lets you select a Form Mode from the available Form Modes on the system.
• Customize output to output a Donation Form for a Donation of the type set on the field using the Form mode configured on the formatter.

This ticket is complete when

• A fieldable entity, like a Node, with "Donation Type" field outputs a donation form when this formatter is selected.

Declared several times, but never used.

Donation capability is provided via field api. A "Donation Type" field provides a picklist on the edit screen to choose from the Donation Type bundles on the system. If one is selected, then the field itself displays as a donation form.

Dev

• Create a FieldType plugin redhen_donation_type similar to List String
  • remove the "allowed values" config options that List String provides. Allowed values validation is simply "does this donation record type exist"
  • Include a raw value display formatter option
• Create a FieldWidget plugin redhen_donation_type that displays as a drop-down, listing Donation Record Types, and allow its use on the FieldType created.

Note: Creation of a custom field formatter to output this field as a donation form will take place in a separate ticket.

This ticket is complete when

• A fieldable entity, like a Node, can add a "Donation Type" field.
• The "Donation Type" field appears on the node edit form as a drop-down list including a blank option (unless the field is marked "required") and an option for each of the Donation Type bundles that have been created on the system
• Saving a value in one of these fields retains the value the next time you view or edit the entity

It just returns an empty array.

I'm not sure, but I believe the intent is to issue a break not a continue in the following:

  foreach ($payment_methods as $payment_method) {
    if ($payment_method['payment_method'] == $form_state['values']['payment_method']) {
      $currency = $payment_method['currency'];
      continue;
    }
  }

Donation configuration options should be available on individual Donation-enabled content entities.

These configuration options include suggested amounts, confirmation message, confirmation page, maximum and minimum donation amounts, and the label for the submit button.

Dev

Create Settings

• Customize the Donation Type field from #17 to include additional value columns (see date and addressfield for examples:
  • Amount Entry Style* (picklist: Radios, Drop-down, Text)
  • Amount Entry Label* (text, accept html)
  • Suggested Amounts* (structure like picklist field value options: allows numbers or the word "other" as key options)
  • Minimum Amount
  • Maximum Amount
  • Submit Button Label*
  • Confirmation Page
  • Confirmation Message
• Add the fields above to the Donation Type Field Widget in a default-collapsed attached section called "Donation Settings"
• In field widget validation, check Suggested Amounts to confirm all Keys in Key/Value pairs are either numeric or the word "other"

Implement Settings behaviors

• Customize Donation Form based on these field settings.
  • On DonationForm (src/Form/DonationForm.php) buildForm function, ask for an optional argument which is "field settings". If Donation is not new, get the source entity based on the Donation's entity source and pull the settings in from there.
  • In Donation Field Formatter (#18), pass the field settings in a variable to the DonationForm buildForm button.
  • Use the field settings to customize the donation form. Min/max block donations outside their range. "Other" provide a picklist value with a manual input. Confirmation Page redirects. Confirmation Message creates a drupal message.

This ticket is complete when

• An entity with a "Donation Type" field sees all these extra settings on their edit form when a Donation Type is selected.
• Settings are saved and persistent (and editable)
• Every setting changes the behavior on the donation form as expected

And also shows as disabled on the donations page.

Create a rules trigger for a donation being made which triggers on successful donation. Provide the donation entity as a variable (this should also give rules access to current user and the parent entity).

This rules patch may be needed: https://www.drupal.org/project/rules/issues/2724129
Depending on progress on this ticket: https://www.drupal.org/project/rules/issues/2471481

Create a test rule to make sure an email trigger can be generated this way.

Write up instructions for generating email notifications in the Readme, including "rules is required" and a reference to the patch, if needed.

Create the branch for this work (8.x-1.x), scaffold a drupal 8 "redhen_donation" module.

• Use drupal:generate

The donation tool should ideally be able to accept payments using whatever payment processor the site owner desires. This will require unique API implementations for each payment processor, and we will start with a small subset of these available.

We are building our own plugin definition because the Drupal 8 payment landscape does not offer us what we need, although it would be nice if it did. More here: https://docs.google.com/document/d/1SXZjeTZlqSR4QOX4woqpq8Dt0jJhW_0WlzHy8vks4n4/edit

Dev

1. Review the document above, and briefly review whether the Drupal payment landscape might now offer something we could use instead of rolling our own plugin.
2. Define a Plugin Manager for "redhen payments"

Currently, RedHen Donation requires tying the donation form down to a single product, and the product's price is ignored. A more "commercey" workflow would be to allow a site builder to configure a set of products with prices, and attach any number of those products to a donation form. Then when a user makes a donation, any number of products could be selected. (Depends on the configuration - maybe you want a single select, maybe a multi select or checkboxes, maybe you want some of them to be single and some to be multi in the same form.) RedHen Donation would add the prices up to form a donation "total" amount.

The detail about which product(s) were selected would need to be stored with the donation when the donation is processed, for further reporting about which "products" were donated for.

Original planning doc
Datastructure architecture

Brief

Redhen Donation for Drupal 7 was successful at some things, and not so successful at some things. Regardless, it will be useful to understand how the D7 version works, but you should note expect to be able to re-use significant amounts of code. The plan for Drupal 8 is to retain what 7 did well, while simplifying and modularizing.

The use of a custom bundle (Donation Type) and Entity (Donation) to define donation styles and then track donations was successful in providing record-keeping and flexibility. These we should keep.

The reliance on Drupal Commerce, especially on Commerce Products, Orders, and Line items, generally created more trouble than seemed valuable. We have different expectations and needs than Commerce, therefore we should remove it as a dependency, while structuring our work well enough to connect to Commerce, if needed, at a later date: commerce compatibility is not a priority for the initial release.

There was also often confusion in RD7 around the borders of a Donation. Was a Recurring donation multiple donations? Or a single Donation with multiple payments? What happened when a person’s name appeared differently on their Donation than they wanted it to appear in Redhen?

Since Donation forms are sensitive from a design perspective, RD7 also struggled with its “3-entity-forms”, where a Payment entity, a Contact Entity, and a Donation Entity were all being constructed at the same time.

Implementation Plan

Note the drawing here linked above.

Redhen Donation for Drupal 8 will define the following data structures and plugins:

1. A Donation Entity: All non-payment fields will be manually added to bundles of these, and a Payment Plugin selected.
2. A Payment Plugin type: potentially utilizing an existing Plugin Type for Payments. We will likely want to extend any payment type we reuse with an Interface defining special functions (like logging recurring payments)
3. A Payment Entity for logging payments: also potentially utilizing an existing Payment plugin but extending with Donation necessities
4. A field type and widget for selecting Donation Types on any fieldable entity.
5. Custom routes/tabs that get added to any Entity with a Donation Type field for displaying donations and for configuring donations.

Redhen Donation for Drupal 8 will contain a submodule called “Redhen Donation Contacts” which has Redhen Contact module as a dependency.

Redhen Donation Contacts will add a configuration option to the “configuring donations” route page that allows editors to map fields on the Donation Type to fields on an upserted Redhen Contact, and decide whether to overwrite existing values or not.

Redhen Donation Contacts will hook into incoming donations to upsert Redhen Contact information.

Note that Redhen Donation can operate without Redhen Donation Contacts.

To make the donation form display customizable, we need the basic elements of the donation to be re-arrangeable and re-orderable along with the fields on the donation. When customizing the Form Display for a Donation Type, you should see these elements along with all the fields on the Donation Type:

• Donation Amount
• Payment Widget

Make sure that these work, and interact with the DonationForm::buildForm() code as expected.

Donations are fieldable entities. Donation Types are the bundle for Donations. A "donation page" will be created by connecting a piece of content to a Donation Type, which determines what fields should be presented on the donation creation form.

Donation Types should extend ConfigEntityBase

Paths should follow predictable patterns:

Donation types should be administered & created at
admin -> structure -> redhen donation -> donation types

Dev

• Create Donation Type entity
• Create Donation entity
• Create Forms:
  • Donation Type Form
  • Donation Type delete form