ukgiftaid issueshttps://lab.civicrm.org/extensions/ukgiftaid/-/issues2022-03-11T17:28:46Zhttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/1Dates need reworking, inc. Handling of adding a "Yes past 4" declaration assu...2022-03-11T17:28:46ZRichDates need reworking, inc. Handling of adding a "Yes past 4" declaration assumes today, ignores start_dateNote: this imported from https://github.com/mattwire/uk.co.compucorp.civicrm.giftaid/issues/28 and https://github.com/mattwire/uk.co.compucorp.civicrm.giftaid/issues/15 since they were going in the same direction.
When a yes and past 4 ...Note: this imported from https://github.com/mattwire/uk.co.compucorp.civicrm.giftaid/issues/28 and https://github.com/mattwire/uk.co.compucorp.civicrm.giftaid/issues/15 since they were going in the same direction.
When a yes and past 4 years declaration is added, it's supposed to trump an existing yes donation that's within the "past 4 years" period.
This period should be the 4 years leading up to `start_date` but is actually the 4 years leading up to the current date.
This is also related to [github issue 15](https://github.com/mattwire/uk.co.compucorp.civicrm.giftaid/issues/15) because it's a case when we muddy the definition of what a declaration record's purpose is.
@mattwire said
> Ok. I think the sensible next step is to add a "valid from" date into the declarations and an upgrader/api to back-calculate for existing declarations. That will help us simplify some of the code going forward because we can just check if Yes/Yes4years and read the "valid from" date instead of working out the 4 year interval each time we check elibility.
@artfulrobot said
> Agreed. (I also hope to move the logic into SQL one day, which should significantly speed up searches).
>
> In an ideal world I might rename the fields:
>
> - `given_date` - Date declaration was given (currently `start_date`)
> - `valid_from_date` - Date person tells us they were eligible from. So on a contribution form, this is limited to the day they hit submit, or exactly 4 years previously. But on the back end, it would be possible to correct it with actual dates.
> - `valid_to_date` - Date person tells us they are not eligible (like `end_date`). I'd suggest that this
>
> However, this will definitely upset any other code (+views/rules) that used the old names, and will make it much harder to maintain an upgrade path from the compucorp one. So maybe I just add a `valid_from_date` as you suggest, and leave `start_date` somewhat misleadingly as the date the declr was given.
>
> Also, I've not tested the existng pattern yet, but I'd suggest that the period that is valid is, in [mathematical notation](https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_endpoints)
>
> `[ valid_from_date, end_date [` or `[ valid_from_date, end_date )` meaning that if an end date is 17 May, then contributions on 17 may are NOT covered. This gives us a way to set the valid period to zero, which could be useful - e.g. we got a NO declaration today and tomorrow we got a YES - 4 YEARS one which overrules the NO completely.
### Merged other issue
The custom fieldset that stores declarations is used for a mix of purposes, which leads to information that can't be audited without guesswork.
The 2 purposes it's used for are:
1. Storing exact transactional details about a received declaration - for example 'source' and a scanned copy of the declaration.
2. Storing state data that can be used to determine eligibility over time periods.
So if someone (e.g. HMRC) says: show us when this person declared their eligibility, things get difficult.
Example:
- 1 Jan 2019 Person makes first ever donation, says they're eligible for now (and going forward). Source is "donate for X".
- 1 March 2019 Claim is made
- 1 Sep 2019 Person moves house
- 1 Jan 2020 Person makes another donation, says they're eligible now and since 4 years ago.
This will result in a single declaration which will have:
- 1 Jan 2020 as the date
- the *source* (and possibly scanned signature) from the original declaration
It is now impossible to say what happened: apparently there was a declaration made in Jan 2020 but the the source of that shows a campaign from a year before it and an address they no longer live at, even though we have an updated address for them now in their contact record. The scanned signed declaration doesn't seem to fit either, perhaps the scan doesn't say anything about "past 4 years", so that looks like an error.
My opinions on this are that:
## Every declaration should be kept
Don't merge two+ declarations. Do store multiple declarations if multiple declarations have been given. Each one backs up the veracity of the information and this gives a full and accurate record of what the donor declared.
## Declarations should have clearer dates
"Start Date" is used but does not describe the start of a period of eligibility, in the case of "and 4 years prior" declarations. It's actually the date that one of the declarations was made.
I think declarations should have three dates:
- Date declaration received
- Date declaration is valid from (i.e. typically date received or 4 years before, but outside of the simplified yes/no eligibility forms, it ought to be possible to record a declaration for any given period)
- Date declaration is valid until (usually NULL to mean until further notice).
## Addresses should not be stored with declarations, but should be kept with claims.
I might be wrong about this one, but here's my understanding: HMRC checks people included in GA claims by comparing their current known address for tax purposes with the one submitted. So the one that gets submitted should be the most up-to-date address, not the address they had when they signed the declaration.
Duplicating address data in declaration records seems to cause more problems that it solves and I can't see HMRC being interested in old addresses.
I think it's a nice feature to record a copy of the address that was used for a claim, though, since then if HMRC come asking "*you've said they live at X but this doesn't look right to us*" then we can say "*Ah, yes, they *did* live at X at the time we claimed, but they're now at Y*".
@mattwire said
> @artfulrobot I agree the way these are stored (and how easy they are to change/overwrite) is not great and should be reworked/improved. I've separated most of the code that handles declarations into it's own class `CRM_Civigiftaid_Declaration` which should hopefully make refactoring/improvements easier.
>
I think declarations should have three dates..
>
> Agree. This would also simplify the code quite significantly because you could just look at the valid from date instead of checking if it was "Yes, past 4 years" or just "Yes". It would also be quite an easy thing to update via an upgrader step.4.0RichRichhttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/19Find contribution with batch name bring no result2023-09-12T17:43:22ZtapashFind contribution with batch name bring no resultIt appeared to have worked till 3.4.4. Batches created prior to that bring result. But not with the latest release.It appeared to have worked till 3.4.4. Batches created prior to that bring result. But not with the latest release.https://lab.civicrm.org/extensions/ukgiftaid/-/issues/20API method to get data from the declaration that corresponds to a contribution2022-02-13T23:47:30ZcapoAPI method to get data from the declaration that corresponds to a contributionAs part of #16, I wrote an API method: `getcontributioneligibility` that facilitates reading fields from the declaration that corresponds to a contribution. There is already a merge request associated: !17.
#### Usage Example
The main ...As part of #16, I wrote an API method: `getcontributioneligibility` that facilitates reading fields from the declaration that corresponds to a contribution. There is already a merge request associated: !17.
#### Usage Example
The main use case of the new API method is to be able to add information from the Gift Aid declaration that corresponds to a contribution, when designing a receipt template. The goal is to write templates that can be used to both print receipts for new contributions or reprint them for old ones.
```smarty
{crmAPI var='contribution_giftaid_declaration' entity='GiftAid' action='getcontributioneligibility'
sequential=0 contribution_id=$contributionID}
{crmAPI var='contribution_eligible' entity='OptionValue' action='get'
sequential=1 return='label' value=$contribution_giftaid_declaration.values.eligible_for_gift_aid
option_group_id='eligibility_declaration_options'}
{assign var='eligible' value=$contribution_eligible.values.0.label}
{if isset($eligible)}
<tr>
<td {$labelStyle}>
{ts}Eligible for Gift Aid?{/ts}
</td>
<td {$valueStyle}>
{$eligible}
</td>
</tr>
{/if}
```https://lab.civicrm.org/extensions/ukgiftaid/-/issues/23Contribution with both eligible & ineligible financial types in price set2022-03-31T09:03:46ZTomCrawshawContribution with both eligible & ineligible financial types in price setI have created a contribution page using a price set which has 2 fields of different financial types: one is eligible for GA and the other is NOT. The contribution page works fine and the line items are separately recorded, but when I tr...I have created a contribution page using a price set which has 2 fields of different financial types: one is eligible for GA and the other is NOT. The contribution page works fine and the line items are separately recorded, but when I try to add the contribution to a batch the whole contribution is rejected as "not valid". Should the GA extension work at the line item level, or does it always treat a contribution as one FT?https://lab.civicrm.org/extensions/ukgiftaid/-/issues/24Obtaining declaration from standalone profile doesn’t update all necessary fi...2023-08-02T02:39:07ZtapashObtaining declaration from standalone profile doesn’t update all necessary fields.I am trying to obtain giftaid declaration by sending donors a checksum link of a profile where all necessary fields are present like home address, postcode, name etc.
When the form is submitted, all is recorded within declaration is ye...I am trying to obtain giftaid declaration by sending donors a checksum link of a profile where all necessary fields are present like home address, postcode, name etc.
When the form is submitted, all is recorded within declaration is yes/no/4 year fields. No other fields ( date, address) get populated like it does during a contribution submission.
@mattwire is this how it supposed to work? Is there a way to make it work from a standalone profile? Thankshttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/33Civicrm Gift Aid Extension Doesn't provide for single donation2022-08-24T17:04:31ZRichardACivicrm Gift Aid Extension Doesn't provide for single donationWhen using the Gift Aid extension for civicrm, there are currently three options for a user to choose from on the Gift Aid Declaration - Yes, today and in future, yes, today and last four years, and No. There is no option for the user to...When using the Gift Aid extension for civicrm, there are currently three options for a user to choose from on the Gift Aid Declaration - Yes, today and in future, yes, today and last four years, and No. There is no option for the user to just choose 'this donation only', which is a valid option under HMRC rules. Please update the code to provide this option, along with the appropriate behaviour for this option.
Using Civicrm version 5.52.2 and Gift Aid Extension version 3.5.1 (Wordpress)https://lab.civicrm.org/extensions/ukgiftaid/-/issues/34Report results in fatal error if contribution column is not not selected.2022-09-26T13:46:48ZKurund JalmiReport results in fatal error if contribution column is not not selected.This bug might have been introduced during this fix: https://lab.civicrm.org/extensions/ukgiftaid/-/merge_requests/29/diffsThis bug might have been introduced during this fix: https://lab.civicrm.org/extensions/ukgiftaid/-/merge_requests/29/diffsKurund JalmiKurund Jalmihttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/35Set contribution eligibility based on financial type AND contact declaration2023-09-11T21:59:32ZrebeccatregennaSet contribution eligibility based on financial type AND contact declaration### Current state
At present the extension solely relies on what financial types are configured to be eligible for Gift Aid to calculate and set the below on contribution records for online donations:
- Eligible for Gift Aid?
- Amount
...### Current state
At present the extension solely relies on what financial types are configured to be eligible for Gift Aid to calculate and set the below on contribution records for online donations:
- Eligible for Gift Aid?
- Amount
- Gift Aid Amount
### Proposed changes
We propose a change in the extension to set the contribution ‘Eligible for Gift Aid’ field to ‘Yes’/’No’ based on **Financial type AND contact declaration**
```mermaid
graph TD;
A[Contribution is added]-->B[Financial type eligible for Gift Aid]
B -- No -->C[Set contribution git aid eligibility to 'no', gift aid amount '0']
B -- Yes -->D[Check contact declaration]
D -- 'No' declaration -->C[Set contribution git aid eligibility to 'no', gift aid amount '0']
D -- 'Yes' declaration-->E[Set contribution git aid eligibility to 'yes', calculate gift aid amount]
```
### Considerations
The current behaviour may be suitable for other organisations so an alternative option would be to enhance the extension by introduction configuration options to set the contribution ‘Eligible for Gift Aid’ field to ‘Yes’/’No’ based on:
- Financial type eligibility only
- Financial type AND contact declarationhttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/36Feature: SearchKit actions for Add to/Remove from batch2023-05-16T15:31:31ZufundoFeature: SearchKit actions for Add to/Remove from batchIt would be really neat to get the search actions for "Add to batch" and "Remove from batch" working with a SearchKit listing of contributions.
I've had a go adding a URL route to the existing search task in order to get picked up as a ...It would be really neat to get the search actions for "Add to batch" and "Remove from batch" working with a SearchKit listing of contributions.
I've had a go adding a URL route to the existing search task in order to get picked up as a ["legacy search task"](https://docs.civicrm.org/dev/en/latest/searchkit/tasks/#legacy-search-tasks) and it doesn't quite work.
First I think there is an issue with the controller class being hard-coded for SearchKit contribution tasks (in this line: https://github.com/civicrm/civicrm-core/blob/6f61a39b3cfb45c3a56b2557203660c69ff2bdab/ext/search_kit/Civi/Api4/Action/SearchDisplay/GetSearchTasks.php#L196 )
Then I think `CRM_Civigiftaid_Form_Task_AddToBatch` needs some tweaks to load nicely with the contribution ids passed as a request param.
Hoping to find some more time this week to get as far as an MR.ufundoufundohttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/37Existing "Yes" declaration not transitioning to "No"2023-08-02T06:16:55ZmikantchapExisting "Yes" declaration not transitioning to "No"PHP 7.4.33
Drupal Version 9.5.8
CiviCRM 5.58.1.
UK Gift Aid 3.5.2
Via a donation, created a 'Yes, today and in the future' declaration.
Then did a second donation, with 'No'.
The certificate is not changed to a 'No'.PHP 7.4.33
Drupal Version 9.5.8
CiviCRM 5.58.1.
UK Gift Aid 3.5.2
Via a donation, created a 'Yes, today and in the future' declaration.
Then did a second donation, with 'No'.
The certificate is not changed to a 'No'.https://lab.civicrm.org/extensions/ukgiftaid/-/issues/38Strange logic around Contributions without LineItems2023-07-10T14:49:51ZRichStrange logic around Contributions without LineItemsThe code that checks the eligibility of a contribution at:
https://lab.civicrm.org/extensions/ukgiftaid/-/blob/87d0fc09baf70463386de74bfc05fa9177a14ba9/CRM/Civigiftaid/SetContributionGiftAidEligibility.php#L97
...handles missing line i...The code that checks the eligibility of a contribution at:
https://lab.civicrm.org/extensions/ukgiftaid/-/blob/87d0fc09baf70463386de74bfc05fa9177a14ba9/CRM/Civigiftaid/SetContributionGiftAidEligibility.php#L97
...handles missing line items (comment references https://lab.civicrm.org/extensions/ukgiftaid/-/issues/9) by using the contribution's `financial_type_id`
However, except in the case that all financial types are considered eligible, the calculation of amount gift-aidable is always done on line items.
So the work-around linked above will possibly do random things:
- ✔ if no line items were returned because it's api3 and quirky but they do exist, and the financial type ID on the contribution is elgible, then the totals should be correct.
- ✖ if no line items were returned because it's api3 and quirky but they do exist, and the financial type ID on the contribution is ineligible, then the totals will be wrong; always zero.
- :expressionless: if no line items were returned because there aren't any (this should be considered broken data) then the contribution's financial type is used; the ga amounts are always 0, leading to possibilities like £10 contrib, is eligible, amount eligible: £0.
I came across this while trying to write a phpunit test.https://lab.civicrm.org/extensions/ukgiftaid/-/issues/40Receipting is wrong when transitioning from Yes to NO2023-08-02T06:25:02ZtapashReceipting is wrong when transitioning from Yes to NO@mattwire I was able to determine this from a clean install of CiviCRM and latest version of the extension.
When transitioning from Yes to NO declaration the contribution which was selected as NO, shows "YES" on the email receipt.
Alth...@mattwire I was able to determine this from a clean install of CiviCRM and latest version of the extension.
When transitioning from Yes to NO declaration the contribution which was selected as NO, shows "YES" on the email receipt.
Although it doesnt break functionally in the backend, the donor may question the integrity of the system and gets confused. Because he has selected NO, but the receipt is declaring as YES.
![Screenshot_2023-08-02_at_11.52.09](/uploads/a0e4f0f6c2b80907809fbbebfde70dc6/Screenshot_2023-08-02_at_11.52.09.png)https://lab.civicrm.org/extensions/ukgiftaid/-/issues/41Given date is updated when first payment is received2023-10-10T13:41:18ZPradeep Nayakpradpnayak@gmail.comGiven date is updated when first payment is receivedThe gift aid declaration date given is being generated as the date the first contribution is taken rather than the date they’ve agreed to gift aid.
Joined on 11/07/2023, when the gift aid declaration was given. However, the gift aid dat...The gift aid declaration date given is being generated as the date the first contribution is taken rather than the date they’ve agreed to gift aid.
Joined on 11/07/2023, when the gift aid declaration was given. However, the gift aid date has been filled in as 01/08/2023, when their first contribution was taken.
Payment processor: Smart debit or Go Cardless
**Expected system behaviour**
The gift aid date is the date the declaration is given
**Actual system behaviour**
The gift aid date is when the first contribution is takenhttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/42PHP 8 error on Remove from Gift Aid batch2024-03-28T17:01:05ZdavejPHP 8 error on Remove from Gift Aid batchOn PHP 8.1, we got a PHP error on the _Remove from Gift Aid batch_ task. This resulted in the remove from batch form being only partially rendered, unstyled and not usable. The PHP error:
```
TypeError: count(): Argument #1 ($value) must...On PHP 8.1, we got a PHP error on the _Remove from Gift Aid batch_ task. This resulted in the remove from batch form being only partially rendered, unstyled and not usable. The PHP error:
```
TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in include() (line 54 of .../files/civicrm/templates_c/en_GB/%%1D/1D7/1D7FFE0E%%RemoveFromBatch.tpl.php).
```
PR to follow.
**Versions**
- UK Gift Aid 3.5.3
- CiviCRM 5.65.2
- Drupal 10.2.2
- PHP 8.1.27