Closed (fixed)
Project:
Gift Aid management
Version:
1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
8 Jul 2025 at 16:02 UTC
Updated:
28 Dec 2025 at 10:54 UTC
Jump to comment: Most recent
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
jonathanshawI have wondered about things like this. For example, whether the declaration is valid depends on it having 5 key pieces of information, and an explanation, and evidence. One could imagine all kinds of UIs to get staff to verify the presence/absence of all the key ingredients and behind the scenes compute validity based on that.
However, the conclusion I've come to is that the right UI depends enormously on the particular circumstances of the declaration. So it's best left for sites that want this to set it up using custom fields/widgets on a custom declaration type specific to their organisation's workflow. As you point out, it's dangerously easy for any UI to be largely ignored by staff on autopilot, so it needs to be carefully suited to the circumstances.
What the guidance says is "in order for a Gift Aid declaration to be valid, the charity must give and be able to demonstrate it has given an adequate explanation to the donor of the personal tax implications associated with making a Gift Aid donation".
3 things of significance here:
- to "demonstrate" an explanation has been given sounds to me exactly like evidence, which we already have a mechanism for with the evidence field.
- in 99% of cases that evidence of the explanation will be the same thing (paper, audio recording, web form) as the evidence of the declaration
- the explanation could actually be on the confirmation email, so it could be missin initially
Therefore I don't think "explanation" makes sense as a base field on the declaration, because it's rarely necessary to treat evidence of explanation sperately from evidence of declaration & confirmation, and sites that want to do something more elabarate for a particularly tricky declaration type easily can.
Comment #3
adamps commentedI guess there are two possible options: have a base field, and hide it when it's not needed, or add a bundle field whenever it's needed. For the 2 web self-declare cases, the explanation text isn't in the evidence, so we would need the bundle field.
I had also considered that we could track the confirmation email wording or template version. I recall that the guidelines said something about "demonstrating that the email had been sent according to a particular template" being acceptable.
Comment #4
jonathanshawOr we follow #3534245: Change handling of web evidence and additional evidence for the web cases to capture the explanation.
I don't really have a good sense of the best solution here, base field, bundle field or evidence. My slight inclination is to think bundle field is the right solution, because it makes it clear that the field is only relevant to those bundles that use it.
If the bundle field was configurable, maybe other declaration types could add it smoothly if it was right for them.
I think it would be a good idea to have a "confirmation email" evidence type that has the date sent, address sent to, full text, etc. and always capture that.
Comment #5
adamps commentedWe agreed to keep the base field, but hide it by default on the form.
Comment #6
adamps commentedComment #8
adamps commented