Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-18T00:47:30Zhttps://lab.civicrm.org/dev/core/-/issues/1197Participants counted even when marked as "0" on price set line item2023-06-18T00:47:30ZphilmorbruParticipants counted even when marked as "0" on price set line item[This issue was originally reported in Jira as [CRM-20784](https://issues.civicrm.org/jira/browse/CRM-20784). Bringing it here to make sure it doesn't get lost as it continues to be a bug in 5.13.5]
When creating a price set, you can se...[This issue was originally reported in Jira as [CRM-20784](https://issues.civicrm.org/jira/browse/CRM-20784). Bringing it here to make sure it doesn't get lost as it continues to be a bug in 5.13.5]
When creating a price set, you can set the number of participants who should be counted for that price option. In this use case, I was setting up a price option for a table (with a participant count of 8) and for a table guest (with a participant count of 0). This way, the person purchasing the table could choose whether or not to register the actual names and emails of the additional table guests without paying more or having them count toward the total number. When testing, the table price option worked as expected, counting 8 participants, but the table guest still counted as 1. If there's an option to set the participant count to 0, then it should not calculate accordingly in the Actual Participant Count.https://lab.civicrm.org/dev/core/-/issues/1195Links in PayPal Standard recurring contribution confirmation email don’t work2023-11-23T07:47:01ZBobSLinks in PayPal Standard recurring contribution confirmation email don’t workRef: https://lab.civicrm.org/dev/core/issues/760
Contribution confirmation emails for recurring PayPal Standard contributions contain three links that are non-functional.
**Link 1: “This is a recurring contribution. You can cancel futu...Ref: https://lab.civicrm.org/dev/core/issues/760
Contribution confirmation emails for recurring PayPal Standard contributions contain three links that are non-functional.
**Link 1: “This is a recurring contribution. You can cancel future contributions by visiting this web page.”**
* Two questions are shown which seem inappropriate for a front-end page:
1. Send cancellation request to PayPal Standard ?
2. Notify Contributor?
* On submit:
* If Send Cancellation = Yes:
* Green-background status message: "The recurring contribution could not be cancelled."
* No change to recurring status in Civi or PayPal.
* If Send Cancellation = No:
* Green-background status message: “The recurring contribution of 5.20, every 1 month has been cancelled.”
* Contact record shows recurring contribution is cancelled
* Merchant and donor PayPal accounts continue to show active recurring transaction.
**Link 2: “You can update billing details for this recurring contribution by visiting this web page.”**
* There are only Save and Cancel buttons, but no form fields.
* Submit: "There was some problem updating the billing details"
**Link 3: “You can update recurring contribution amount or change the number of installments for this recurring contribution by visiting this web page.”**
* Recurrence Period is indicated as "(every )" rather than ‘(every month)”.
* If not logged in:
* Popup: "Access is denied. Ensure that you are still logged in and have permission to access this feature."
* On submit: Blank screen.
* If logged in:
* On submit:
* Displays Find Contributions page with no error indicated.
* No change observed in either merchant or donor PayPal accounts. Both show an active recurring payment.
**Analysis**
(I’ll focus on link 2 as an example, and assume that none of these 3 links should appear as their functions are unsupported by PayPal (?) for PayPal Standard payments)
1. Sending of confirmation email is initiated by Paypal performing an IPN POST.
2. CRM_Contribute_BAO_Contribution->composeMessageArray calls CRM_Core_Payment_PayPalImpl->subscriptionURL to form the problematic URLs.
3. CRM_Core_Payment_PayPalImpl->subscriptionURL attempts to determine if the payment processor supports each operation by doing, for example “if (!$this->supports('updateSubscriptionBillingInfo'))” which in turn returns method_exists($this, supportsUpdateSubscriptionBillingInfo).
4. CRM_Core_Payment (parent class of CRM_Core_Payment_PayPalImpl) does indeed contain function supportsUpdateSubscriptionBillingInfo which returns “method_exists(CRM_Utils_System::getClassName($this), 'updateSubscriptionBillingInfo')”.
5. CRM_Core_Payment_PayPalImpl does include function updateSubscriptionBillingInfo, although it begins with “if ($this->isPayPalType($this::PAYPAL_PRO)) “ and therefore simply returns false for PayPal Standard or Express
6. Template "Contributions - Receipt (on-line)" includes the problematic URL section based on the existence of $updateSubscriptionBillingUrl (for example).
**Conclusion**
* Step 3 seems to be a problem as it tests only for the existence of supportsUpdateSubscriptionBillingInfo (found in the parent class) rather than calling that function to get a meaningful result.
* Step 4 seems to be a problem because while the function 'updateSubscriptionBillingInfo' does indeed exist, it does nothing if the payment processor is PayPal Standard.
Behavior confirmed in 5.13.4 and in master (5.18.alpha1).https://lab.civicrm.org/dev/core/-/issues/1191CiviCRM reaching MySQL join limit2023-11-26T16:41:52ZJGauntCiviCRM reaching MySQL join limitI've seen a similar error on a few websites where there is a lot of custom data which can throw up a few issues and it was mentioned I should write up an issue here to see whether it is a common issue in the community.
All current versi...I've seen a similar error on a few websites where there is a lot of custom data which can throw up a few issues and it was mentioned I should write up an issue here to see whether it is a common issue in the community.
All current versions of MySQL and MariaDB have a join limit of 61 and Civi needs to join a lot of tables together (dependant on how much custom data you have). This can cause problems when you have a site with a lot of custom data sets as this join limit is reached which prevents Civi from working as expected.
An example of this would be yesterday where I tried to load up a contact's activities but, because of the amount of custom data sets on the site, I was given an AJAX error and could not view the contact's activities.
After doing a bit of debugging, I found out the reason was because the join limit of 61 had been reached.
I managed to resolve the issue by disabling some unused custom data sets but I am wondering if this is quite a common issue with some bigger sites.
My thinking is that as time goes on, the database will naturally get bigger as more is added to it and the issue will come up more and more.
Looking forward to hearing some thoughts and suggestions on this!https://lab.civicrm.org/dev/drupal/-/issues/81Drupal8: Large export results in logout2019-11-03T16:19:27ZJonGoldDrupal8: Large export results in logoutWhen you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces,...When you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces, more readable:
```
Warning: session_start(): Failed to decode session object. Session has been destroyed in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 149 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#1 [internal function]: _drupal_error_handler(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php(149): session_start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#5 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#6 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#15 {main}.
```
```
RuntimeException: Failed to start the session in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 150 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#6 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#12 {main}.
```
The first issue is a warning that the session is too large, and so it destroys the session (which causes a logout). The second issue is of "error" severity saying the session can't be found.
Here's someone else having a similar issue in Symfony (not Drupal8): https://github.com/symfony/symfony/issues/26623tottentottenhttps://lab.civicrm.org/dev/user-interface/-/issues/1Remove "Backend" from the Access CiviCRM permission label2019-08-15T06:52:49ZmarshRemove "Backend" from the Access CiviCRM permission labelon admin>people/permissions the name of Access CiviCRM has changed to "Access CiviCRM backend and API".
This is confusing for two reasons:
- backend infers something behind Civi, not Civi itself
- there are many references to Access Civ...on admin>people/permissions the name of Access CiviCRM has changed to "Access CiviCRM backend and API".
This is confusing for two reasons:
- backend infers something behind Civi, not Civi itself
- there are many references to Access CiviCRM in the notes on the page.
Would it be more prudent to change the label to "Access CiviCRM (and API)", or am I just being pedantic?https://lab.civicrm.org/dev/core/-/issues/1129Duplicate records on CRM_Report_Form_Member_Detail2022-09-26T00:11:17ZandyburnsDuplicate records on CRM_Report_Form_Member_DetailOn CRM_Report_Form_Member_Detail, the rows get duplicated. They are not actual duplicates, it is the same contact ID and they do not have duplicate memberships.
![5b7f716e](/uploads/6ae639a21fd22a9b5fc47c1d1edf66be/5b7f716e.png)
On 5.13.4On CRM_Report_Form_Member_Detail, the rows get duplicated. They are not actual duplicates, it is the same contact ID and they do not have duplicate memberships.
![5b7f716e](/uploads/6ae639a21fd22a9b5fc47c1d1edf66be/5b7f716e.png)
On 5.13.4https://lab.civicrm.org/dev/core/-/issues/1125Custom fieldsets participants added twice2023-02-15T15:13:29ZwdecraeneCustom fieldsets participants added twiceWhen editing a participant, some custom fieldsets are added twice to the participant edit form. When saving, only the data in the second fieldset is saved (so users think nothing happened when they added the data in the first instance of...When editing a participant, some custom fieldsets are added twice to the participant edit form. When saving, only the data in the second fieldset is saved (so users think nothing happened when they added the data in the first instance of the fieldset).
This only happens with fieldsets linked to a specific event type.
In templates/CRM/Event/Form/Participant.tpl:
```smarty
CRM.buildCustomData( '{$customDataType}', null, null );
{if $eventID}
CRM.buildCustomData( '{$customDataType}', {$eventID}, {$eventNameCustomDataTypeID} );
{/if}
{if $eventTypeID}
CRM.buildCustomData( '{$customDataType}', {$eventTypeID}, {$eventTypeCustomDataTypeID} );
{/if}
```
* First buildCustomData : adds all custom field sets, except those linked to a specific event id
* Second buildCustomData : adds all custom field sets linked to a event id
* Third buildCustomData : adds all custom field sets linked to a specific event type id
So the combination of the first and third one is the cause of fieldsets added twice.
Solution? Altering template, changing arguments, fixing getTree() in CRM/Core/BAO/CustomGroup.php, ... ?
See also
* https://issues.civicrm.org/jira/browse/CRM-10983
* https://issues.civicrm.org/jira/browse/CRM-20633https://lab.civicrm.org/dev/core/-/issues/1116Changing a civicase activity's label breaks the max_instances check2023-02-23T14:16:28ZDaveDChanging a civicase activity's label breaks the max_instances check1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. Create a case.
3. Change the activity type's label.
4. On manage case, create a second activity of that type.
5. You should get the ma...1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. Create a case.
3. Change the activity type's label.
4. On manage case, create a second activity of that type.
5. You should get the max_instances warning but it doesn't.https://lab.civicrm.org/dev/drupal/-/issues/76Proposal: Don't migrate drush commands to D82020-06-19T16:21:14ZJonGoldProposal: Don't migrate drush commands to D8CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush c...CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush civicrm-sql-cli`, `drush civicrm-sql-dump`) but there's a compelling argument to simply not rewriting drush and instead making sure that `cv` has feature parity.
For those who DO think we should continue to maintain the drush commands, I have a branch here: https://github.com/MegaphoneJon/civicrm-drupal-8
Klaas has also submitted a PR to add `drush civicrm-api` to this branch.https://lab.civicrm.org/dev/financial/-/issues/64Authorize.net - support future dated transactions via contribution page2019-09-10T17:28:18ZlcdwebAuthorize.net - support future dated transactions via contribution pageProvide an option to allow contribution pages implementing Authorize.net to expose a field where the user can select a future date for the transaction. This would be patterned after the iATS future date implementation.
* add A.net conf...Provide an option to allow contribution pages implementing Authorize.net to expose a field where the user can select a future date for the transaction. This would be patterned after the iATS future date implementation.
* add A.net config settings page where future date option can be enabled/disabled
* add config setting to select specific days of the month where the future date can be implemented. this is important for recurring payments, where the org may only want recurring payments to be triggered on specific days of the month
* expose a Contribution Transaction Date field to the contribution form (when option is enabled)
* modify processing to account for this field if active and used
Contrib page screenshot attached for reference.
![anet-futuredate](/uploads/94fefd56c909114e8758f367cbb6c1b2/anet-futuredate.png)
I'd like to see this included in core, and am looking for concept approval.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1083Non-deductible amount not working2023-12-21T11:11:54ZJoeMurrayNon-deductible amount not workingOn 5.14 and dmaster 5.16.alpha1 when a price set is configured with an option that includes a non-deductible amount, then a purchase is made of that option, the non-deductible amount is not appearing on the contribution.
Price Set Field...On 5.14 and dmaster 5.16.alpha1 when a price set is configured with an option that includes a non-deductible amount, then a purchase is made of that option, the non-deductible amount is not appearing on the contribution.
Price Set Field with non-deductible $5 on $10 price:
![2019-06-27_14-44-40](/uploads/3954b396bb81d67c5f01cf5c6464b85a/2019-06-27_14-44-40.png)
Contribution for $10 with $0 non-deductible:
![2019-06-27_14-43-59](/uploads/9c43a1a6c2a0381ed94c403901228821/2019-06-27_14-43-59.png)EdselopezEdselopezhttps://lab.civicrm.org/dev/drupal/-/issues/69Drupal8: Problem with user registration confirm email flow2020-09-18T09:50:52ZwannesderoyDrupal8: Problem with user registration confirm email flowIn our Drupal8 & CiviCRM setup we allow visitors to create accounts, with email verification. These users are created by CiviCRM when they sign up for a membership.
We encountered some issues around the registration process: the user wa...In our Drupal8 & CiviCRM setup we allow visitors to create accounts, with email verification. These users are created by CiviCRM when they sign up for a membership.
We encountered some issues around the registration process: the user was denied permission to the password form. And the onetime login link in the mail was always invalid.
In the CRM/Utils/System/Drupal8.php file we changed some of the user registration logic to be the same as the default Drupal 8 way.
1) First issue was that the user account was not set to 1 (active) when $verify_mail_conf was set to true. In default drupal this is the case.
2) Second issue was the user was logged in immediately after sending the verification mails, this should not happen when the verify_mail_conf setting is true. User may only be logged in when checking the mail and following the onetime login link.
[civicrm-core-d8-create-user-fix.patch](/uploads/876064009461686e9ef556adb5ae4676/civicrm-core-d8-create-user-fix.patch)https://lab.civicrm.org/dev/core/-/issues/1036Deprecate Tell a Friend2022-12-06T23:14:44ZAndie HuntDeprecate Tell a FriendWho tells their friends anymore? This really should be removed or deprecated.
@JonGold came up with this idea and @bgm thought it would be worth opening an issue for it.Who tells their friends anymore? This really should be removed or deprecated.
@JonGold came up with this idea and @bgm thought it would be worth opening an issue for it.https://lab.civicrm.org/dev/financial/-/issues/62PayPal Pro IPN doesn't record failed recurring payments2020-01-18T22:29:49ZJonGoldPayPal Pro IPN doesn't record failed recurring paymentsOnce upon a time, some payment processors recorded failed recurring payments, others didn't, based on the preference of the author.
These days, we've settled on "failed recurring payments should create a failed contribution entry" acros...Once upon a time, some payment processors recorded failed recurring payments, others didn't, based on the preference of the author.
These days, we've settled on "failed recurring payments should create a failed contribution entry" across the board, except PayPal Pro, which has the note "[// Also consider accepting 'Failed' like other processors.](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L248)".
I wrote a patch for this years ago, but at the time it wasn't settled that this was correct behavior. I recently had another client request this functionality, so I'm going to modernize the patch, put it in production, and submit it upstream if it looks good.JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/60Transaction IDs for a contribution that are initially null are always null2021-08-06T13:19:57ZfrancescbassasTransaction IDs for a contribution that are initially null are always nullThis ticket is the result of the inquiry in this other https://lab.civicrm.org/dev/core/issues/468
**"Normal behaviour"**
1. Create a contribution with transaction ID
![normal-1](/uploads/4208ac1852698fdf61e003d500174d31/normal-1.png...This ticket is the result of the inquiry in this other https://lab.civicrm.org/dev/core/issues/468
**"Normal behaviour"**
1. Create a contribution with transaction ID
![normal-1](/uploads/4208ac1852698fdf61e003d500174d31/normal-1.png)
2. Visualize contribution, transaction ID is present
![normal-2](/uploads/37bab7a87afad68b094dfa5eba16ee9b/normal-2.png)
3. Edit payment details and set a different transaction ID
![normal-3](/uploads/e04d3ed2b91215f593e403310c48b9ad/normal-3.png)
4. Visualize contribution, new transaction ID is appended to the old transaction ID
![normal-4](/uploads/19308ed662e8920da29e234c49c69608/normal-4.png)
**Buggy behaviour**
1. Create a contribution with transaction ID null
![null-1](/uploads/38cd6b38e9ccd16e852c5c7e0c51c3d6/null-1.png)
2. Edit payment details and set a transaction ID value
![null-2](/uploads/25f183f29ced11ae4398cfa8611ec31b/null-2.png)
3. Visualize contribution, transaction ID isn't present
![null-3](/uploads/de18a6e9656acbd6d29029b3c84023db/null-3.png)https://lab.civicrm.org/dev/financial/-/issues/57Payments - Where do we store IDs from payment processor?2022-01-04T06:27:07Zmattwiremjw@mjwconsult.co.ukPayments - Where do we store IDs from payment processor?On contributions there are two fields that can be used to store unique values - trxn_id and invoice_id. trxn_id is the only one that we can actually because the workflows ignore invoice_id in various places. For recurring contributions...On contributions there are two fields that can be used to store unique values - trxn_id and invoice_id. trxn_id is the only one that we can actually because the workflows ignore invoice_id in various places. For recurring contributions we have trxn_id and processor_id and here we have to set both to the same value because they are used inconsistently in the code. Then there are the individual payments which can store their own trxn_id.
Looking at Stripe we have:
* `charge_id` - changes each time a payment is attempted - matches best to `civicrm_financial_trxn.trxn_id` (but currently we save on civicrm_contribution.trxn_id).
* `invoice_id` - may have multiple charge_id's for example if a payment attempt fails and is retried. So this should really be the trxn_id on the contribution (we don't currently store it).
* `subscription_id` - for a recurring contribution this represents the plan so maps directly to `civicrm_contribution_recur` and could be saved in either `civicrm_contribution_recur.trxn_id` or `civicrm_contribution_recur.processor_id`.
The problem is that the way CiviCRM works internally (and API functions such as Contribution.completetransaction don't really allow us to work in the way we'd like).
UPDATE - the resolution here has been to
1) Add a field order_reference to the civicrm_financial_trxn table. The reason for adding is to this table even though it 'represents' the contribution / order is that it's possible not all payments on one contribution are by the same processor - hence it's up to the processor to manage this field
2) Matt felt that civicrm_financial_trxn.result_code met his needs for a descriptionmattwiremjw@mjwconsult.co.ukmattwiremjw@mjwconsult.co.ukhttps://lab.civicrm.org/dev/drupal/-/issues/64Drupal8/Backdrop: Bad URL on ACL page linking to CMS permissions2020-11-04T20:49:06ZJonGoldDrupal8/Backdrop: Bad URL on ACL page linking to CMS permissions`CRM_Admin_Page_Access::run()` attempts to generate a URL to the CMS permission page. It uses a switch to give a CMS-specific URL.
I wrote a Backdrop and D8-specific code, using `url()` and `\Drupal\Core\Url::fromUri()` respectively - ...`CRM_Admin_Page_Access::run()` attempts to generate a URL to the CMS permission page. It uses a switch to give a CMS-specific URL.
I wrote a Backdrop and D8-specific code, using `url()` and `\Drupal\Core\Url::fromUri()` respectively - but I think this is overcomplicated. Couldn't we just pass a string instead? Or is there some oddball situation (multi-site?) where you need to generate the URL using the Drupal-specific functions?JonGoldJonGoldhttps://lab.civicrm.org/dev/drupal/-/issues/62Possible rework on path checking on function civicrm_user_form_validate for 7...2021-02-05T10:40:39ZVangelisPPossible rework on path checking on function civicrm_user_form_validate for 7.x branchI have had some issues with a civicrm profile validation (even with the default `Name and Address`) when it was being exposed in the drupal user registration page after adding some ajax there.
Problem that appears when you ajaxify the ...I have had some issues with a civicrm profile validation (even with the default `Name and Address`) when it was being exposed in the drupal user registration page after adding some ajax there.
Problem that appears when you ajaxify the form itself, is that contents are getting replaced. When this happens, `civicrm_user_form_validate` doesn't work. Specifically, arg(0) & arg(1) are changing (see below).
Searching a little bit more, I have noticed on [line ~~681~~ 707](https://github.com/civicrm/civicrm-drupal/blob/7.x-master/civicrm.module#L707) that there's an arg() comparison so that Civi can understand what path users are coming from ([here](https://github.com/civicrm/civicrm-drupal/blob/7.x-master/civicrm.module#L694))
May I suggest (i can make a MR) instead of doing a path search using the arg() variable, check the form `#action` or `#user_category` instead, like:
* `$register = (($form['#action'] == '/user/register' || $form['#action'] == '/admin/people/create') ? TRUE : FALSE);`
or
* `$register = (($form['#user_category'] == 'account' || $form['#user_category'] == 'register')) ? TRUE : FALSE);` (This is taken from `user_account_form_validate` [function here](https://api.drupal.org/api/drupal/modules!user!user.module/function/user_account_form_validate/7.x))
This way, validation is always there, as long as the form `#action` or `#user_category` keeps the same name(s).
One relatively easy way to reproduce is this:
On a/any environment having Drupal 7.x:
* Download and enable [bootstrap](https://www.drupal.org/project/bootstrap) as the default theme
* Download and enable [bootstrap_login_modal](https://www.drupal.org/project/bootstrap_login_modal) which will add AJAX to the user login and user register form(s). This will also cause the non-validation issue i am referring to.
* Try to register yourself and don't add a first and last name, validation will not kick-in.
Now change the civicrm.module on line 681 with the above and re-try to register yourself. Validations will now work.
There is another issue there but it'm still looking at it: The warning comes back, eg. First name is a required field but the CiviCRM profile fields do not light up, they don't inherit the class `.has-error`.https://lab.civicrm.org/dev/core/-/issues/960Proposal: Change supervised dedupe rules to name(s) OR email2023-03-18T04:52:01ZJonGoldProposal: Change supervised dedupe rules to name(s) OR emailI've done countless Civi trainings on deduping, many at CiviCamps and other "official" places. And each time, I need to explain that "yes, unsupervised rules should be more strict than supervised rules. Also yes, the default individual...I've done countless Civi trainings on deduping, many at CiviCamps and other "official" places. And each time, I need to explain that "yes, unsupervised rules should be more strict than supervised rules. Also yes, the default individual supervised rule is far more strict than the default unsupervised rule."
Surely I'm not the only one who feels the same - and yet none of us noticed, because before Civi 5.3/CRM-20565, the supervised rule was basically unused.
Now, there's a code comment that says, [CRM-20565 - Need a good default matching rule before using the dedupe engine for checking on-the-fly.](https://github.com/civicrm/civicrm-core/blob/1eca040f3f6efa0a8a43575cd0a08bae242a95f3/templates/CRM/Contact/Form/Contact.tpl#L334).
I'm proposing we fix this by changing the default supervised rule. The current on-the-fly checking is both a) a default, and b) very poor UX.
I'm also proposing that we do this as the new default for everyone. I'm mindful of the changes to existing systems, and we should probably put in an upgrade note or something - but honestly anyone who's never changed the default supervised rules isn't very likely to be using them.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/928Membership and Auto-Renew issues2023-11-23T07:09:31Zmattwiremjw@mjwconsult.co.ukMembership and Auto-Renew issuesOverview
WORK IN PROGRESS Parts of this are gradually being extracted into smaller, easier to review PRs. Once this is fully reviewed and merged documentation will also need updating.
Ref: https://github.com/civicrm/civicrm-core/pull/123...Overview
WORK IN PROGRESS Parts of this are gradually being extracted into smaller, easier to review PRs. Once this is fully reviewed and merged documentation will also need updating.
Ref: https://github.com/civicrm/civicrm-core/pull/12315
This is mostly code cleanup and an attempt to understand exactly what happens when a membership is automatically renewed!
# Fixes (and this needs adding to Civi docs somewhere as it's currently undocumented and unclear what it does):
## Before
* Membership will be renewed when contribution is in ANY state except "Pending."
* All parameters of recurring contribution are ignored, ie installments, frequency mismatch (eg. monthly recurring, annual membership) so every new contribution will trigger a membership renewal.
* When repeattransaction is called ONLY the membership linked to the original contribution will be renewed (if the contribution is in the correct state (ie. Completed - see Before/After)). loadRelatedObjects only loads one membership but the code is expected all memberships to be loaded so does handle multiple memberships if passed in.
## After
* Membership will be renewed ONLY when contribution is in state "Completed".
* Membership will be renewed ONLY if the recurring and membership type frequencies match. Installments parameter has no effect.
* When repeattransaction is called: If the contribution has a recurring contribution ID then ALL memberships linked to that recurring contribution will be renewed. If the contribution has no recurring contribution then the membership linked to the original contribution will be renewed (if the contribution is in the correct state (ie. Completed - see Before/After) AND the other conditions are met (ie. state, frequency)).
## Documentation (After)
* Membership will be renewed ONLY when contribution is in state "Completed" - https://github.com/civicrm/civicrm-core/pull/12315 (5.5.0)
* Membership will be renewed ONLY if the recurring and membership type frequencies match (Installments are ignored).
* When repeattransaction is called any linked memberships will be renewed if the contribution is in the correct state. If there is a recurring contribution then the frequencies must also match (installments are ignored).
* A recurring contribution can be linked to multiple memberships and all memberships will be updated/renewed if all other conditions are met - https://github.com/civicrm/civicrm-core/pull/12542 (pending merge)