Support for Multiple Addresses about houdini

[wwahammy]

This will require the following changes:

• create a new address model associated with a supporter and any associated donations/tickets
• Add support for viewing the addresses in the Supporters view
• Output correct addresses in the supporters csv export output
• Show correct address in campaign gift view or campaign gift exports
• Add a migration which includes:
  • Move supporter addresses from supporter to the new model
  • Associate donations and tickets with the correct supporter address

[wwahammy]

Address model should have the following relationships:

Supporter -> 1 to Many  -> Address
Donation -> Many to 1 -> Address
Ticket -> Many to 1 -> Address

Address fields:

id: int
street1: string
street2:string
city: string
region: string
postal_code:string
country: string
supporter_id: int

[wwahammy]

Question: How should we handle phone numbers? Separate model?

[wwahammy]

Question: How should we handle emails? Separate model? Or ignore for now?

[brevityworks]

I would vote wait on refactoring phone numbers and emails. Addresses are prickly due to fulfillment, but I think we can take a bit of time with email and phone.

[wwahammy]

Does that mean when people add a new phone number or email as part of a donation, it should always override the saved one?

[wwahammy]

We're working on this task at #92.

[wwahammy]

Issue: supporters are currently geocoded to their address, mostly for showing on maps. How should we handle this?

[wwahammy]

After discussing further with @wendylbolm and @brevityworks, it's become clear that addresses in Houdini have varying needs. In particular, custom CRM addresses, when modified or added by the nonprofit has different characteristics than an address for donations, particularly when used as shipping addresses for campaign gifts, or tickets.

We propose addressing this problem by having two types of addresses internally to the system:

• transaction addresses and
• custom addresses

A transaction address internally always has a 1-to-1 relationship with a transaction record (a donation or a ticket). By doing so, this allows a nonprofit (or donor) to edit each transaction address individually without changing any other transaction addresses it matches with or any custom addresses it matches with.

A custom address is an address in the CRM that the nonprofit has added themselves through the UI or through an import.

In the CRM supporter record, all unique addresses (of both types) will be searchable and displayable.

If a nonprofit users wants to modify a transaction address from the supporter record, the UI will provide an ability to copy the data to a custom address to make it editable. Additionally, the UI will provide the ability for a nonprofit to go to the relevant transactions and edit the transaction addresses at each of the transactions.

Default addresses

For many purposes, a nonprofit wants a single address for a supporter that they can mail. For example, a nonprofit may want to send an annual report to their supporters. For these purposes, our CRM must support the ability to mark an address, either custom or transaction, as a default address. Additionally, this is the default address which is exported for CSV exports.

Setting a default address

When a supporter does not have any addresses (usually at creation) and an address is added, the new address becomes the supporters default address.

QUESTION: What happens if this default address is a transaction address and, at some point, the support deletes the info from it? Should the default address change? I think so.

Default addresses are then changed via a default address change strategy set at the nonprofit level in the non-profit settings panel:

• When the nonprofit changes which address is the default address. The nonprofit user goes to a CRM record and selects a particular address to become the default address This is the default strategy and appropriate for most nonprofits of small to medium size

For larger non-profits in which this is inappropriate or difficult to use, two other default address change strategies are available:

• Always set the default address to be the last used address. If a new transaction comes in or a custom address is added, the default address becomes that.
• Always set the default address to the first used address. The default address is never updated.

[wwahammy]

Question: When are two addresses considered identical?

• Are two addresses which vary by capitalization the same? For example are "101 N Morrison St" and "101 n morrison st" the same? And does this hold in every situation?
• Are two addresses which vary by punctuation the same? For example, are "101 N Morrison St" and "101 N Morrison St." the same? And does this hold in every situation?

[wwahammy]

The general feeling I've received is that we can strip leading and trailing spaces in considering whether two addresses are the same as well as disregarding differences by capitalization and punctuation.

[wwahammy]

One important additional to our logic model:
The default address will be set via join table called AddressTags which joins a:

• supporter
• address

Additionally, an AddressTag has tag field which is a string. This string will be titled "default" for default addresses. This allows us to, potentially, add other address tags in the future.

[wwahammy]

Let's say a nonprofit is using the manual default address strategy and they delete their current default CustomAddress for a supporter. Which one should be selected after the delete?

[wendylbolm]

Maybe there should be a popup that has the choices "Set another address as default." and "Leave blank."

[wwahammy]

At the UI level that makes sense although, I'm unsure on the flow.

That seems to suggest to me that the default (at the software level) is to simply leave it blank.

[brevityworks]

To clarify, are these the options?

• Leave blank
• Default to transaction address
• Force decision

[wwahammy]

To clarify, are these the options?

• Leave blank
• Default to transaction address
• Force decision

I'd assume if we default to transaction address we'd do the following in these situations:

• No transaction addresses exist: no default address
• Transaction addresses exist: we'd select the last one?

So those are the two wrinkles.

[brevityworks]

Yes, I think that's logical!

[wwahammy]

Tasks which must be completed:

• Create Supporter API
• Create Address API (for custom address creation and display and listing all addresses for nonprofit)
• Create Ticket API (for updating and adding addresses)
• Create Donation API (for updating and adding addresses)
• Create Default Supporter Address strategies
• Make sure InsertSupporter.create_or_update works
• Make sure InsertImport creates addresses as appropriate
• Make sure searches get addresses
• Make sure exports get the default address
• Update supporter display to include list of addresses and button for editing
• Create Update Address pop over with:
  • list of all addresses, showing which one is default
  • Allow nonprofit to select default address (if on Manual Strategy)
  • Allow nonprofit copy address from TransactionAddress to Custom Address
  • Allow nonprofit to create new CustomAddress
  • Allow nonprofit to update CustomAddress
• Make sure ticket creation form passes the Address to the ticket create call
• Make sure donation creation form passes the Address to the donation create call
• Decide how to handle the supporter address form issue

[wwahammy]

Moving the checkmarks to the pull request since that makes more sense.