Review government guidance

I have completed the review and converted the issue from a task to a plan.

I just noticed this charmer:

If a donor who’s made an oral declaration and been sent a written statement by the charity cancels their declaration within 30 days of being sent the written statement, the cancellation will have retrospective effect, so that it’ll be as if the declaration had never been made.

That retrospective effect needs careful consideration, I think it might be why I wanted written_record_sent_date despite it being technically redundant as you said. Because it would make it much easier to compute/display whether it was "safe" to claim a donation under a declaration.

Yes that's true

Add name and address required fields to the Declaration entity.

My thinking was that these belonged with the context, not per declaration. For example, on an order, the order's billing profile. Also, if a user changed their address, then that shouldn't have to be done on each declaration of that user. And if a user changed their address in the system for reasons unrelated to Gift Aid, then that should probably also be their new address for Gift Aid.

More generally though, we need to think about address complicance carefully:

If the charity is notified of a change in the donor’s name or address, it must keep a record of the updated information — this can be kept as an electronic copy such as a scanned document. The declaration itself does not need to be amended, but a record of the change should be kept on the charity’s database.

Add method (oral/written/self etc) and evidence (file attachments) fields to the Declaration entity

I was thinking to use bundles here, with different configured fields in different bundles. We should provide config for the common circumstances, but allow sites to modify further for their use case. As the fields aren't used programatically, it seemed better to allow configuration to do the work here?

and remove written_record_required from DeclarationType.
Add advised_of_liability field to the Declaration entity. If not advised, then written record is required.

I'm not sure. Oral seems to require a written record unless you have an audio recording of it? That's why I had this on the DeclarationType.

And AFAICS "advised of liability" is a requirement of any valid declaration at the point of declaration.

Add a page for a user to view/edit/create their own declarations and donations.

Yes, that's ✨ Fix GiftAidOverviewController Active although see 🌱 The problem of changes Active .

Enhance the declarations listings to cover everything needed for audit. Add some filters.

Nice.

Turn on revisions, perhaps require a revision log or generate automatically, write submission guidelines.

Yes, this is a very important area, linked to 🌱 The problem of changes Active .

Add a link from the order/donation to the declaration.

Yes. Or at least a Yes/no.

If possible add a link from the declaration to all the orders/donations. (3.28).

Out of scope for now.

Remove the restriction that declaration end date cannot be in the past (3.9.3).

This can be a form of cancellation with an existing declaration. See 🌱 The problem of changes Active .

Move the declaration form settings/building from GiftAidDeclaration to Charity to allow using the form elsewhere (e.g. the self-declaration page).

Code-reuse is good, but why Charity rather than a parent class I'm not sure.

Add support for tokens that refer to charity fields. Ensure that the charity name is included (3.9.2)

Twig us fields for free and is in many ways superior, so I'm happy to only support that.

Lots of good points, thanks. It's an important question about the address fields on the context or the declaration. Some considerations I thought of:

• the context might get deleted too soon
• some contexts don't inherently have an address (User) or might not have (Order can exist without one, for example if PayPal payment for virtual product)
• if the address is on the context, how would we display it on the declaration page?
• if the address is on the declaration which has revisions, it provides a common place to cover change of address auditing

And AFAICS "advised of liability" is a requirement of any valid declaration at the point of declaration.

I agree, but still two reasons.

• The audit process requires a record that this occurred. If we make a box for it, and the staff have to tick it, it makes them much more likely to remember, and should be more convincing to the auditor.
• We could receive an email saying "please add gift aid to my donations". We would naturally create a declaration at this point that is not yet valid because not advised. We could send a written record to remedy that.

Code-reuse is good, but why Charity rather than a parent class I'm not sure.

Mainly to allow it to be different per Charity. Perhaps not important.

I'm not sure. Oral seems to require a written record unless you have an audio recording of it? That's why I had this on the DeclarationType.

True, but this brings a risk that we force the site owner to double the number of declaration types: each one has a variant for oral and another for non-oral. I feel we should leave the site owner free to choose how they use declaration types. E.g. they might instead want declaration types to correspond to donation types: one for commerce, one for direct debit, one for a sponsorship form etc. If we have a field for "method" the software can calculate when a written record is required automatically (it would also be true if we are missing some information).

I would like to fix 🐛 Fix problems arising from "Consolidate tests" Active next as otherwise it leaves some potentially confusing loose ends (it's waiting for your review when you have a chance). After I suggest we have a discussion of both technical matters and issue prioritisation.

I created ✨ Record donor name & address Active for address handling and added it to 🌱 [META] Roadmap Active .

I like the discussion on "advised of liability", oral and bundles a lot. I'm still not sure what's right, but I think it's important and sensible discussion. Worth its own issue.

I split most of the "suggested changes" into the child issues, including a new one ✨ Enhancements to declaration entity Active

I have created 🌱 Product requirements Active as a replacement for this issue.