ukgiftaid issueshttps://lab.civicrm.org/extensions/ukgiftaid/-/issues2024-03-28T17:01:05Zhttps://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.27https://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/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/39Add Api4 Contribution.UpgradeGiftAid action - missing2023-07-31T17:31:33Zmattwiremjw@mjwconsult.co.ukAdd Api4 Contribution.UpgradeGiftAid action - missing@artfulrobot To track https://lab.civicrm.org/extensions/ukgiftaid/-/merge_requests/39#note_149537@artfulrobot To track https://lab.civicrm.org/extensions/ukgiftaid/-/merge_requests/39#note_149537https://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/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/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/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/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/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/32API Giftaid.updatedeclarations overwrites existing declaration address with c...2022-06-30T16:41:13Zaydunsaidan.saunders@squiffle.ukAPI Giftaid.updatedeclarations overwrites existing declaration address with current address`Giftaid.updatedeclarations` overwrites an existing declaration address with the current address of the contact. The documentation says it updates missing addresses so I assumed that it would fill in missing addresses but not change exi...`Giftaid.updatedeclarations` overwrites an existing declaration address with the current address of the contact. The documentation says it updates missing addresses so I assumed that it would fill in missing addresses but not change existing ones on declarations.
Do you agree it should only be updating missing addresses?
Separately, but in the same function - why does it specifically disable logging before making these updates? I'd prefer to be able to track all changes in the log.https://lab.civicrm.org/extensions/ukgiftaid/-/issues/31Address format wrong in report2023-02-07T13:54:22Zaydunsaidan.saunders@squiffle.ukAddress format wrong in reportIn the report, the address should be shown as "the house name or number and the postcode".
`CRM_Civigiftaid_Declaration::getDonorAddress()` returns a `house` field as the first part of the stored address up to a comma. This would wor...In the report, the address should be shown as "the house name or number and the postcode".
`CRM_Civigiftaid_Declaration::getDonorAddress()` returns a `house` field as the first part of the stored address up to a comma. This would work if the stored address was structured correctly.
But `getAddressAndPostalCode()` and `getFormattedAddress()` that are used to set the address on the declaration do not attempt to extract the house name or number.
There was some work on this in https://lab.civicrm.org/extensions/ukgiftaid/-/commit/7325f5dcf0d3cdf7189ba76c661ca5d254be1cfc
There was a regexp in `getHouseNo()` attempting to extract the house name/number but it was removed in that commit.
It seems the intent was to move the house number matching to the point where the address is stored on the declaration, rather than when the address is read from the declaration. But I don't see that the house name/number extraction made it to the declaration setting stage.
Before attempting to fix this, I'd like some confirmation that the intention is that the address stored on the declaration is a single string formatted such that the house name/number required for the report is the first part of the address up to a comma.https://lab.civicrm.org/extensions/ukgiftaid/-/issues/30two different currencies2022-06-16T08:49:21Zdavephassalltwo different currenciesWe are unable to create a batch and get the message "you can not add items of two different currencies to a single contribution batch". We are using UK Gift Aid 3.5.1 and civicrm 5.47.3 and all of our data is in sterling.
Thank youWe are unable to create a batch and get the message "you can not add items of two different currencies to a single contribution batch". We are using UK Gift Aid 3.5.1 and civicrm 5.47.3 and all of our data is in sterling.
Thank youhttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/29Installation fails with "'name,label,description' is not a valid option for f...2023-02-07T13:56:32Zaydunsaidan.saunders@squiffle.ukInstallation fails with "'name,label,description' is not a valid option for field option_value_fields" on 5.49+Attempting to install the extension fails with "'name,label,description' is not a valid option for field option_value_fields"
5.49 sets `option_value_fields` to `name,label,description`. The code assumes that values retrieved via api3 ...Attempting to install the extension fails with "'name,label,description' is not a valid option for field option_value_fields"
5.49 sets `option_value_fields` to `name,label,description`. The code assumes that values retrieved via api3 `get` can be fed directly to api3 `create`... which is not always true.https://lab.civicrm.org/extensions/ukgiftaid/-/issues/28Tests failing with 3.52022-05-23T11:25:20ZRichTests failing with 3.5Run on Civi 5.48.2: (with output from `phpunit7 --testdox`)
```
Summary of non-successful tests:
CRM_Civigiftaid_Declaration
✘ Set declaration logic with data set #0
│
│ Test set: existing no, adding a yes (also tests omitted ...Run on Civi 5.48.2: (with output from `phpunit7 --testdox`)
```
Summary of non-successful tests:
CRM_Civigiftaid_Declaration
✘ Set declaration logic with data set #0
│
│ Test set: existing no, adding a yes (also tests omitted given_date and provided given_date)
│ Failed asserting that actual size 1 matches expected size 2.
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:163
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
✘ Set declaration logic with data set #1
│
│ Test set: existing no, adding a yes past 4
│ Failed asserting that actual size 1 matches expected size 2.
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:163
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
✘ Set declaration logic with data set #3
│
│ Test set: existing yes, adding a no
│ Failed asserting that actual size 1 matches expected size 2.
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:163
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
✘ Set declaration logic with data set #4
│
│ Test set: existing yes past 4, adding a no
│ Failed asserting that actual size 1 matches expected size 2.
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:163
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
✘ Set declaration logic with data set #5
│
│ Test set: existing yes, adding a yes: Expect declr 1 to have reason_ended =
│ Failed asserting that two strings are equal.
│ --- Expected
│ +++ Actual
│ @@ @@
│ -''
│ +'(MISSING)'
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:189
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
✘ Set declaration logic with data set #6
│
│ Test set: existing yes, adding a yes past 4, but existing declaration is older than 4 years ago: Expect declr 1 to have reason_ended =
│ Failed asserting that two strings are equal.
│ --- Expected
│ +++ Actual
│ @@ @@
│ -''
│ +'(MISSING)'
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:189
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
✘ Set declaration logic with data set #7
│
│ Test set: existing yes, adding a yes past 4, but existing declaration is not older than 4 years ago Expect declr 1 to have start_date >= 2022-05-11 11:13:23
│ Failed asserting that '2020-05-01 00:00:00' is equal to '2022-05-11 11:13:23' or is greater than '2022-05-11 11:13:23'.
│
│ /buildkit/build/current/web/sites/default/files/civicrm/ext/ukgiftaid/tests/phpunit/CRM/Civigiftaid/DeclarationTest.php:184
│ /buildkit/extern/phpunit7/phpunit7.phar:615
│
FAILURES!
Tests: 30, Assertions: 191, Failures: 7.
```
EDIT: **This seems to be around the getPartialDeclaration logic in setDeclaration().**https://lab.civicrm.org/extensions/ukgiftaid/-/issues/27Add option value for new pseudoconstant2021-12-21T14:41:54ZeileenAdd option value for new pseudoconstant@mattwire @artfulrobot there is now an option group for the values that can be used in civicrm_entity_batch.entity_table.
From 5.42 on you will need an option value in this option group to support how giftaid uses this table
In order t...@mattwire @artfulrobot there is now an option group for the values that can be used in civicrm_entity_batch.entity_table.
From 5.42 on you will need an option value in this option group to support how giftaid uses this table
In order to support earlier versions you could use `ensureOptionGroupExists` with the same parameters as in https://lab.civicrm.org/dev/core/-/commit/b6d0c5b8efdc729fd1c63d3f25e1076d4acf9aa2 or conditionally add the option value if it DOES exist
https://lab.civicrm.org/dev/core/-/issues/2682https://lab.civicrm.org/extensions/ukgiftaid/-/issues/26What permissions are required for this extension?2023-08-02T02:37:06ZtapashWhat permissions are required for this extension?Is there any specific permission required to get this extension work, particularly when the changes in declaration happen through a profile by an anonymous user? i.e. access to all custom field, profile listings, add profile, edit profi...Is there any specific permission required to get this extension work, particularly when the changes in declaration happen through a profile by an anonymous user? i.e. access to all custom field, profile listings, add profile, edit profile etc?
Would be very much appreciated if you could clarify please @mattwire @artfulrobot
Many thankshttps://lab.civicrm.org/extensions/ukgiftaid/-/issues/25Donation cannot be validated with “Yes past 4 years” declaration2021-03-24T13:35:00ZtapashDonation cannot be validated with “Yes past 4 years” declarationThis was a test case where a new declaration was created of “Yes past 4 years” with current date.
2 individual Donation, one marked with yes, another with past 4 years within eligible section of the contribution.
None of them could b...This was a test case where a new declaration was created of “Yes past 4 years” with current date.
2 individual Donation, one marked with yes, another with past 4 years within eligible section of the contribution.
None of them could be validated for submission with an error “ INVALID DONOR DETAILS : ADDRESS DATA, Missing first line of address; Postcode invalid“, which is certainly not correct.
But if the declaration is changed to “Yes” and start date backdated to anywhere prior to contribution date, all works fine and batch could be submitted without any issues. I am on latest CiviCRM version, not sure if this has worked previously though. @mattwirehttps://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/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?