Commit 1129fdc3 authored by Rich's avatar Rich
Browse files

WIP: initial notes/thoughts

parent 7a1921f8
## Release 4.0 (in planning)
This is a big change.
### Separation of notification and eligibility periods
In v3 a declaration and a log of having been given a declaration were one and
the same. We had a Gift Aid custom field set for Contacts and each record was
a declaration. Or sort of.
Previously there was some merging or not-storing of new declarations if
they matched the last declaration, and sometimes there was a changing of
existing declarations. This meant there was no reliable audit trail,
should you need to prove that you acted under instruction about
eligibility. The most egregious case was if you had a signed 'yes'
declaration on 1 Jan 2018 and then later another 'yes and past 4 years'
declaration on 1 Jan 2020, the 3.x version would not store two
declarations, but instead just edit the start date of the first. This
means the scanned declaration no longer tallies with the data; it means
any context data relevant to the second declaration is lost.
The new method is simpler to reason about:
- **Every declaration (no/yes/yes past 4) is stored as an activity** So you
will have a full log of what they have told you and when. The date of the
activity is the date the declaration was provided, not the date the person
became eligible (or not). Note that it is the donor's responsibility to
inform the charity about their eligibility, not the charities, so we always
assume the latest thing they told us is correct.
- **Eligibility Periods are stored as custom fields**. Each
record has a `eligible_from` and an `eligible_to` date, the latter may be
NULL to indicate an ongoing eligibility. These are only used to describe the
ranges the person was eligible; they do not need to link to the way the
declaration was made and are independent of those.
- On a contribution form, a 'yes' declaration is handled:
1. store it as an activity, using today's date.
2. delete any periods whose start date is in the future.
3. if we're in a period already, make sure its end date is NULL
4. if we're not in a period, create one by entering the relevant
start date (i.e. today or 4 years ago).
- On a contribution form, a 'no' declaration is handled:
1. (same) store it as an activity, using today's date.
2. (same) delete any periods whose start date is in the future.
3. if we're in a period already, set its end date to yesterday.
- If a declaration is received some other way (e.g. paper or phone) a staff
member can record whatever details they wish in a new activity. They can
then edit the eligibility periods directly in an easier way since there
are far fewer fields to deal with.
- Internally: the logic of whether a contribution is eligible for
including in a batch is now done with SQL like this pseudo code:
SELECT COUNT(*) > 0 AS isEligible
FROM eligible_periods
WHERE isForThisContact
AND eligible_from_date <= contribution date
AND (eligible_to_date IS NULL OR eligible_to_date >= contribution date)
This should speed up matching for batching significantly.
### V3 to V4 upgrade
1. Create a new custom field group with multiple rows per contact called
`ukgiftaid_eligible_period` with fields for `eligible_from`,
`eligible_to` (NULL), `contact_id`.
2. Disable the declaration fieldset
3. Create a "GiftAid eligibility update" activity type. This is mostly
descriptive and for human consumption. We'll use some stock subjects to
describe yes/no/yes past 4, but most details will go in the Details
4. Copy/move all old declaration records to activities, using `start_date`
as the activity's date.
5. Create a new field on the custom fieldset for Contributions which will
be used in place of the old declaration field (y/n/yes past 4) for
inclusion in profiles for contribution forms.
6. Populate the new custom fieldset with minimal records required to
describe eligibility periods from the old declarations.
7. Alter the GA profile to include the new Contributions field instead of
the old declaration one.
## Release 3.3.11
* Use "Primary" address instead of "Home" address for declarations.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment