CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-11-08T00:50:05Zhttps://lab.civicrm.org/dev/core/-/issues/4025Import Memberships: activity date set to date of import instead of Membership...2023-11-08T00:50:05ZcomposerjkImport Memberships: activity date set to date of import instead of Membership Start DateOverview
----------------------------------------
For _Memberships > Import Memberships_, I would expect that the _Activity Date_ for _Membership Signup_ would be the required _Membership Start Date_. Instead, when one views Activities,...Overview
----------------------------------------
For _Memberships > Import Memberships_, I would expect that the _Activity Date_ for _Membership Signup_ would be the required _Membership Start Date_. Instead, when one views Activities, the _Membership Signup_ activity date is the date/time of the import.
Query on chat.civicrm.org (no replies, yet): https://chat.civicrm.org/civicrm/pl/jgrmtpxr878w3fbtrm6iia4rsw
It looks like @petednz also mentioned this issue back in 2017: https://chat.civicrm.org/civicrm/pl/sbj5yeuccfr65yy9wwmam3mxte
Reproduction steps
----------------------------------------
1. _Memberships > Import Memberships_ for an existing contact with a Membership Start Date set to some date in the past.
1. View the Membership Signup activity, perhaps via _Search > Find Activities_.
Current behaviour
----------------------------------------
The listed Activity Date is the date of the import.
Expected behaviour
----------------------------------------
I would expect that the _Activity Date_ would be the _Membership Start Date_, similar to how the _Activity Date_ for a _Contribution_ is set to the _Payment Received Date_.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
- __CiviCRM:__ 5.56.0, 5.55.2, 5.55.0, 5.54.0
- __CMS:__ WordPress 6.1.1
- __PHP:__ 8.1.13 (fpm-fcgi)
- __Database:__ 10.3.31-MariaDB engine: InnoDB 10 row format: Dynamic
- __Webserver:__ nginx/1.20.2
- __OS:__ Linux
Comments
----------------------------------------
In my case, part of this is maintaining history. At some point, I hope to import data for membership archives going back 80 years. From @petednz's mention, it sounds like the _Membership Dashboard_ will also look wrong.https://lab.civicrm.org/dev/core/-/issues/2929Geocoding failures kill contributions2023-10-23T16:08:42ZandrewcormickdockeryGeocoding failures kill contributionsOverview
----------------------------------------
Last night between about 6pm and midnight AEDT, it appears that Nominatim (the Open Street Map API provider) had an intermittent outage. Some requests were receiving a 502 error. We hav...Overview
----------------------------------------
Last night between about 6pm and midnight AEDT, it appears that Nominatim (the Open Street Map API provider) had an intermittent outage. Some requests were receiving a 502 error. We have configured this as our Geocoding provider in CiviCRM under /civicrm/admin/setting/mapping?reset=1
People who were using CiviCRM in ways which caused the Geomapping provider to be called were receiving fatal errors as a result. This included people who were making donations (i.e. entering their address on the form which in turn was handed to the Geomapping provider for geocoding).
Current behaviour
----------------------------------------
When a request to the Geomapping provider fails (for example with a 502 error), the generating transaction within CiviCRM returns a fatal error and does not complete. This includes financial transactions, and indeed any administrative function that involves adding or updating a contact's address.
Expected behaviour
----------------------------------------
A Geomapping provider failure should never cause financial transactions to fail. I can't think of any reason why adding or updating an address should fail either. Fatal errors should only occur when an issue occurs which genuinely prevent a transaction from succeeding. A payment can still be processed regardless of whether that person's address can be geocoded or not. I expect a 502 Bad Gateway error from Nominatim would be logged, but never cause an address to fail to be added/updated. Obviously that would occur without the latitude/longitude being recorded. I can't even see the utility in informing the user. It's a system admin problem.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_
* __PHP:__ _7.3__
* __CMS:__ _Drupal 7.82_
* __Database:__ _MariaDB 10.4.21_
* __Web Server:__ _Nginx 1.10.3_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4547SearchKit: Edit in place for display name should be possible2023-09-03T00:16:46ZlarsssandergreenSearchKit: Edit in place for display name should be possibleIf you have a contact id in a SK display, enabling edit in place will show an autocomplete with contact names when clicked, but the field will show the contact id before clicking, which is confusing UI. On the other hand, a display name ...If you have a contact id in a SK display, enabling edit in place will show an autocomplete with contact names when clicked, but the field will show the contact id before clicking, which is confusing UI. On the other hand, a display name field shows the contact name as desired, but doesn't allow editing. So if you want to have an edit in place and show the contact name, you need both a contact id field and a display name field, which is confusing for the end user.
![image](/uploads/76c8542e1f32afac6074e817252e87ba/image.png)
Why should I click on the random integer on the right to edit the contact, instead of the name on the left?
Could we either make it possible to edit in place on the display name or make it possible to show the display name for the contact id field? Or maybe change the contact id field so it shows the display name by default, rename it to just contact, and add a separate field just for showing the contact id (which is probably a fairly rare need)?https://lab.civicrm.org/dev/core/-/issues/4533Searchkit: "Add new" button text2023-08-24T17:22:23Zmattwiremjw@mjwconsult.co.ukSearchkit: "Add new" button textWhen you enable the "Add New" button you cannot customise the text and it uses the entity name eg. "Add Activity". But if you want to link to a form that does something more specific eg. to create a signature on a petition it would be mu...When you enable the "Add New" button you cannot customise the text and it uses the entity name eg. "Add Activity". But if you want to link to a form that does something more specific eg. to create a signature on a petition it would be much clearer if this button could be customised to say eg. "Add Signature".https://lab.civicrm.org/dev/core/-/issues/4086`processor_id` and `trxn_id` is not properly being set on recurring contribut...2023-08-08T15:16:15Zbrienne`processor_id` and `trxn_id` is not properly being set on recurring contributions with PayPal ProOverview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these val...Overview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these values are not getting updated with the proper format (a shorter, alphanumeric string that starts with 'I-') that is sent back from PayPal.
This causes an immense issue if the user then wants to cancel their recurring contribution because even though it may seem canceled in CiviCRM, the payment is not canceled on PayPal's side, and so the user continues to be charged. This happens because the PayPalPro IPN is no longer being properly set in the CiviCRM database, so when the request to cancel the recurring payment profile goes to PayPal, it does not have the correct `processor_id` needed to cancel it.
Reproduction steps
----------------------------------------
0. If you don't already have one, set up a PayPal Pro Sandbox account that has DPRP enabled for testing recurring payments. Add the API credentials (found in **Activity > API Access > NVP/SOAP API integration**) of this sandbox account to CivCRM as a test payment processor.
* *Fair warning, this set up process with PayPal was not that easy, so if you don't have PayPal Pro, I wouldn't recommend trying this*
1. From your PayPal Pro Sandbox account settings, go to **Notifications**, then click **Update** on **Instant payment notifications**. If your site is not publicly accessible to the internet (i.e. a local dev site for testing), then set up a [webhook.site](https://webhook.site) listening endpoint.
1. Submit a new, recurring contribution (*while not logged in on CiviCRM and using a [PayPal generated credit card for testing](https://developer.paypal.com/tools/sandbox/card-testing/)*) using the PayPal Pro payment processor.
1. On the web UI of webhook.site, take a look at the `recurring_payment_id` for the POST request that has `'recurring_payment_profile_created'` as the `'txn_type'`.
1. In CiviCRM, either with the API explorer or however you look at the data in the databases, look at the `processor_id` and `trxn_id` in the `civicrm_contribution_recur` table.
1. You will find that these strings don't match.
Current behaviour
----------------------------------------
The `processor_id` and `trxn_id` are being set to long alphanumeric strings, such as 'e13d51f14f7fff9fb6923820022ebc77' upon submission of a recurring payment on a CiviCRM installation that is using PayPal Pro. These values are stored in the `civicrm_contribution_recur` table and become problematic for updating or canceling recurring payments.
Expected behaviour
----------------------------------------
The `processor_id` and `trxn_id` should be set to (and stored as) the PayPal Pro IPN that is generated when the `'txn_type'` is `'recurring_payment_profile_created'`. The PayPal Pro IPN is an alphanumeric string that notably starts with 'I-', such as 'I-818V5WCCXF2H'
Additional Info
----------------------------------------
Some backstory - a few years ago, `processor_id` was initially set to `NULL` and was later updated with the IPN. In that scenario, the logic that CiviCRM used (in `/CRM/Core/PaymentPayPalProIPN.php`) made sense, as it checked if that value was set and returned early if it was. However, [PR #21539](https://github.com/civicrm/civicrm-core/pull/21539) added `processor_id` to parameters that get passed to the `recur()` function in PayPalProIPN.php, so the code that sets the value of `processor_id` (and `trxn_id`) to the properly formatted IPN was not being reached.
@JonGold and I currently have a PR with a fix for this in the works, but are doing further testing with a client.
Given that this issue has been going on for a while (9 months, at least), there are many recurring contributions that have a malformed `processor_id`. The PR that will be submitted also includes a check for when `'txn_type'` is `'recurring_payment'` (i.e. subsequent recurring payments) to update the `processor_id` and `trxn_id` to the proper format, if needed.https://lab.civicrm.org/dev/core/-/issues/4477Pay later instructions for offline event registration2023-08-07T01:50:54ZlarsssandergreenPay later instructions for offline event registrationIf you register a contact for an event on the back end, you can select Pending (Pay later) as the participant status and Pending as the contribution status. However, despite what you might expect the pay later instructions for the event ...If you register a contact for an event on the back end, you can select Pending (Pay later) as the participant status and Pending as the contribution status. However, despite what you might expect the pay later instructions for the event will not be sent in the offline event registration email, as `$is_pay_later` does not exist for offline registrations.
Presumably because it is copy-pasted from the online template, the offline event registration template does contain two conditionals for `$is_pay_later` (and so we get PHP warnings).
Option one, we remove `$is_pay_later` from the offline registration template. Simplification! No more warnings.
Option two, if participant status is Pending (pay later) and contribution status is Pending and the pay later instructions text exists for the event, we add the pay later instructions to the email. This is nice because it does what the user probably expects and it gives the registrant useful information to complete the payment. The downside is we are further perpetuating the arguably bad pay later concept, though we don't directly use is_pay_later. There is also added complexity for something that is probably not that common.https://lab.civicrm.org/dev/core/-/issues/4470Allow disabling household contact type2023-08-04T03:59:56ZlarsssandergreenAllow disabling household contact typeCurrent proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disab...Current proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disabled, so at least disabling households shouldn't break anything. Organizations might be different though and less important to allow disabling. Maybe worth trying to allow disabling households first and then see.https://lab.civicrm.org/dev/core/-/issues/4320API: Should NOT operators return NULL values?2023-07-13T23:50:59ZlarsssandergreenAPI: Should NOT operators return NULL values?If you do != 5 in SQL, you'll get all rows that aren't 5, not including null values. This is the same in the API and SearchKit. I wonder if this is the desired behaviour? I would think the assumption would be that if I search for all Con...If you do != 5 in SQL, you'll get all rows that aren't 5, not including null values. This is the same in the API and SearchKit. I wonder if this is the desired behaviour? I would think the assumption would be that if I search for all Contributions where the Contribution Page is != 5, I would get all Contributions except those that have Contribution Page = 5 — but what I actually get is all Contributions that have a Contribution Page, but where that Contribution Page isn't 5.
In other words, I think you'd generally expect that if you search all Contributions where Contribution Page = 5 OR Contribution Page != 5, you'd just get all Contributions, but you only get Contributions with a Contribution Page. Obviously, your expectation might change based on your familiarity with SQL.
This is the same for NOT LIKE, NOT REGEX, and so on.
On the one hand, it's generally better to keep the behaviour of the API operators the same as SQL to avoid confusion. On the other hand, I'm having a hard time imagining a search you might want to make with a NOT that you wouldn't want to include null values, so this seems unhelpful and potentially frustrating. Is this something we should consider changing?https://lab.civicrm.org/dev/core/-/issues/4273Allow double opt-in email (and other emails that you don't want a reply from)...2023-07-05T23:48:40ZJamie Novick - CompucoAllow double opt-in email (and other emails that you don't want a reply from) to use a user configured "mail from" address**How it works currently:**
Currently CiviCRM forces the double opt in email to an email address which is:
the words "do not reply" + the domain of the site from your default mail account configured here: https://dmaster.demo.civicrm.o...**How it works currently:**
Currently CiviCRM forces the double opt in email to an email address which is:
the words "do not reply" + the domain of the site from your default mail account configured here: https://dmaster.demo.civicrm.org/civicrm/admin/mailSettings?reset=1
https://github.com/civicrm/civicrm-core/blob/6f14847526226279076f63cc472afc18f2ce27e6/CRM/Core/BAO/Domain.php#L364
**What is the issue?**
The problem with this is that the default mail account email domain (used for bounce handling), may not be the same domain that you want to use as the from address for your double opt in emails (or for any other email that you don't want a reply from).
**Proposed solution**
We already have a place to configure the available from addresses in the system. This is the option group here: https://dmaster.demo.civicrm.org/civicrm/admin/options/from_email_address?reset=1
As such I would suggest that:
1. We create a new setting on the CiviMail component settings (https://dmaster.demo.civicrm.org/civicrm/admin/setting/preferences/mailing?reset=1) (suggest this is below "Enable Double Opt-in for Profiles which use the "Add to Group" setting":
- called "Email From Address to use where a reply is not expected".
- Field type - single select,
- Options to show from available "Email From Addresses" here: https://dmaster.demo.civicrm.org/civicrm/admin/options/from_email_address?reset=1.
- Not required
- Help: "Specify an Email From Address to use when the system sends an email but a reply is not expected, for example when a user is sent an email for a double opt-in. Leaving this blank will use the default which will be do-not-reply@default_domain where the default_domain will be the email domain address of your default mailing account also used for bounce handling. You can add additional Email From Addresses here [link to admin/options/from_email_address?reset=1].
2. If an email address is specified in the setting above it should be used instead of the current hardcoded default value.
**Next steps**
We're happy to submit a PR for this so if we can get this concept approved we will submit a core PR asap.
Thankshttps://lab.civicrm.org/dev/core/-/issues/4397What should the Name and Address reserved general Individual dedupe rule do?2023-06-30T00:14:21ZlarsssandergreenWhat should the Name and Address reserved general Individual dedupe rule do?We have a reserved dedupe rule on new installs for Individuals called Name and Address.
What it actually does is matches contacts who have the same first name, last name and street address. What it claims to do is the following:
![image]...We have a reserved dedupe rule on new installs for Individuals called Name and Address.
What it actually does is matches contacts who have the same first name, last name and street address. What it claims to do is the following:
![image](/uploads/d427acb2b1c3ce07c994b68a2371ac62/image.png)
[This rule](https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_dedupe_rule/IndividualGeneral.sqldata.php) also includes suffix_id and middle_name with weights of 1, which cannot influence the matches (threshold 15, all other items have weight 5), so these don't do anything.
There is a [hard-coded query](https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/BAO/QueryBuilder/IndividualGeneral.php) for this rule that should match up with the above (right now we are querying middle_name, suffix and birthdate for no reason, which is kind of ironic since this query claims to be optimized).
None of this has changed in at least ten years.
Personally, I don't think matching on first, last and street address is useful (as street addresses are often written slightly differently so are not that likely to match). Maybe we should just eliminate this reserved dedupe rule, since I can't see that it is used for anything. If not, maybe we should make it more useful by making it just first and last name. Or maybe there is some reason this is useful as is and we should simply make this all consistent so it just matches on first, last and address and nothing more.https://lab.civicrm.org/dev/core/-/issues/4361Add Pay now link to Invoice template2023-06-28T06:58:22ZlarsssandergreenAdd Pay now link to Invoice templateIt would be nice to have the link to pay online included in the Invoice template. Currently, a user would have to guess this is possible, find the correct link on SE and add it to the template (then maintain it as the template is updated...It would be nice to have the link to pay online included in the Invoice template. Currently, a user would have to guess this is possible, find the correct link on SE and add it to the template (then maintain it as the template is updated).
I think if default_invoice_page is set, we could simply include a Pay Now link in the Payment Advice section (which is only shown if the Contribution is pending and pay later). If an org doesn't want to include a link for online payment, they can simply leave default_invoice_page empty (Edit: They cannot currently do this for newer installs, will have to make it possible). I think it would be very rare for an org to want to have a default_invoice_page for payments from the User Dashboard, but not to include a link for online payments in invoices (and in that case, they can edit the template).
Will do this and add docs if supported.https://lab.civicrm.org/dev/core/-/issues/4342It should be possible to remove a hidden smart group from recipients of a mai...2023-06-28T06:56:18ZlarsssandergreenIt should be possible to remove a hidden smart group from recipients of a mailing that has been copiedIf you create a mailing by copying another mailing that was sent to search results, it is impossible to remove the hidden smart group from the recipients of your new mailing. This can be frustrating, because your intent in copying a mail...If you create a mailing by copying another mailing that was sent to search results, it is impossible to remove the hidden smart group from the recipients of your new mailing. This can be frustrating, because your intent in copying a mailing may not have been to send it to the same contacts, rather to re-use the content. With Mosaico, you can't easily duplicate the content, so this is a pain.
Ideally, hidden smart groups would be mandatory for the original mailing and could be removed for copies. However, that isn't possible because mandatory groups are simply [included groups that are hidden](https://github.com/civicrm/civicrm-core/blob/f0648c892ab4795b9bec873c840e06009ea4800a/ang/crmMailing/BlockRecipients.html#L6).
Options I see:
1. Don't include hidden groups when copying a mailing. Would solve this issue, but then some users are going to expect identical recipients when they copy a mailing because they are copying the mailing in order to resend to the same recipients, changing the content.
1. Add a Copy without recipients option. This seems like it would add UI complexity for something pretty specific.
2. Allow hidden smart groups to be removed from mailings in general, with a confirmation. This feels like the best option to me. Maybe I've started a mailing from search results and later decide I don't want to send it to those search results. Clearly we want to prevent users from removing a hidden group by accident, but as an intentional decision the user confirms, I think this makes sense. Would have to look at how to handle the unsubscribe group in this case.https://lab.civicrm.org/dev/core/-/issues/4328Double opt-in requires traditional bounce handling to be enabled2023-06-28T06:55:29ZJonGoldDouble opt-in requires traditional bounce handling to be enabledOverview
----------------------------------------
The default double opt-in email says:
> You have a pending subscription to the {subscribe.group} mailing list. To confirm this subscription, reply to this email or click <a href="{subscri...Overview
----------------------------------------
The default double opt-in email says:
> You have a pending subscription to the {subscribe.group} mailing list. To confirm this subscription, reply to this email or click <a href="{subscribe.url}">here</a>.
However, "reply to this email" requires traditional bounce handling (with a bounce mailbox) to be set up. In this day and age that's less common compared to using a third party mailer that sends bounce notifications via API (to [Airmail](https://civicrm.org/extensions/airmail) or one of its many cousins).
Moreover, it's a usability issue to put "here" as the clickable text. It should be more like: "Please click here to <a href="{subscribe.url}">confirm your subscription.</a>.
I want to get concept approval - and also guidance on whether we should update existing templates or just new installs. Personally I think we should update any non-customized template.https://lab.civicrm.org/dev/core/-/issues/5CiviMail Mailing Accounts allow duplicate names, but breaks processing.2023-06-23T17:54:21ZjohnffCiviMail Mailing Accounts allow duplicate names, but breaks processing.If two CiviMail Mailing Accounts have the same name, even if they have different roles, only the first will be used in either case.
The offending line of code is somewhere in the path of: CRM_Utils_Mail_EmailProcessor::_process -> CRM_M...If two CiviMail Mailing Accounts have the same name, even if they have different roles, only the first will be used in either case.
The offending line of code is somewhere in the path of: CRM_Utils_Mail_EmailProcessor::_process -> CRM_Mailing_MailStore::getStore.
To replicate (Drupal, 4.7.27):
1. Create two mailing accounts.
The first one should be "Email to Activity" and have no username / password settings
The second should be "Bounce processing" and have username / password settings
(order of creation is important, and give them both the same name)
2. Run the scheduled job "fetch bounces".
3. In watchdog, observe the error "could not connect" using the credentials of email to activity processor, even though it should use the Bounce Processing one.
4. Clear the watchdog logs.
5. Rename them to have different names, then retry
6. Check the watchdogs, and observe no error.https://lab.civicrm.org/dev/core/-/issues/4297Do help links go after the label or after the field?2023-06-20T20:38:21ZlarsssandergreenDo help links go after the label or after the field?It seems like on some backend forms, the little help links are after the label, while in other places they are after the field itself. If we can agree on one or the other, I will adjust the templates so forms are consistent. My unscienti...It seems like on some backend forms, the little help links are after the label, while in other places they are after the field itself. If we can agree on one or the other, I will adjust the templates so forms are consistent. My unscientific survey indicates that we have about 2/3 after the label and 1/3 after the field right now.
Here's an example with both:
![image](/uploads/28270ce52cc725f384c3e4bcb368442a/image.png)
Additional consideration: When there is both a setting and a help, probably having one after the other would be not great.
![image](/uploads/2966630753c68c090d2a80269a488c34/image.png)
Also, there are a few with help at the end of the description
![image](/uploads/964d812410ed131320947dc6d7b0b7c5/image.png)
Some fields it has to be after the field because there is no label
![image](/uploads/d2f943517edf44b307599502855c4346/image.png)
Checkboxes are always after the label, but that's at the end of the line.
![image](/uploads/f7d02999614ef14009d158d8236b9951/image.png)
With multiple checkboxes, it has to be after the label, there isn't really any other option.
![image](/uploads/155a387d37d5452b9e4f7373cb7a447a/image.png)
Another different layout, I think it only makes sense after the label here
![image](/uploads/d13c5bd26e5bb9aff8f72adf5dc2f109/image.png)https://lab.civicrm.org/dev/core/-/issues/224Event confirmation emails do not populate guest details when payment is confi...2023-06-19T04:25:50ZJKingsnorthEvent confirmation emails do not populate guest details when payment is confirmed by IPN (API)This issue occurs with:
* Paid events, using an IPN payment gateway, or delayed payment
* On events that can have 'additional participants' (guests)
In this case, the event confirmation emails are missing:
* The names of additional part...This issue occurs with:
* Paid events, using an IPN payment gateway, or delayed payment
* On events that can have 'additional participants' (guests)
In this case, the event confirmation emails are missing:
* The names of additional participants
* Any custom 'participant' fields associated with the additional participants
Detailed steps to recreate:
* Create custom fields assigned to the 'Participant' entity, add them to a profile
* Create a free event with online registration, allowing multiple participants, and add the profile with custom fields to it, enable confirmation emails
* Register for the event, with an 'additional participant'
* Notice that the confirmation email contains the 'name' of the additional participant, and also the custom fields associated with their registration
* Create a paid event, with the 'pay later' option (otherwise the same options as above)
* Register for the event, with an 'additional participant' (pay later)
* Now use the Contribution - completetransaction API call to 'complete' the payment (this is the process that would happen if the IPN was triggered).
* Notice that the confirmation email does not contain the name of the participants, and any custom participant fields for the additional participants are NOT included.
Issue cause:
Information from the 'form' submission is passed into the email template when it is triggered for a free event. This information is not populated when the \CRM_Event_BAO_Event::sendMail method is called from the 'completetransaction' API call. Some information is assigned in \CRM_Event_Form_Registration_Confirm::buildQuickForm and includes the $part variable, which is assigned to the template, and subsequently used in the 'online event registration' email template. The custom fields for additional participants are also assigned to the template, based on the form (https://github.com/civicrm/civicrm-core/blob/694ccbf41adc31bce4d056fcc46930ba9c2e15e5/CRM/Event/Form/Registration/Confirm.php#L311), which is also missing from the 'completetransaction' route.
Our solution:
The code around this area of the system was quite spahettified, so we have solved this issue using a custom hook: https://gist.github.com/JKingsnorth/4d233df13a0f6493c44f69d81fa5f27a - although this isn't a great approach (in terms of being able to commit it back to core) - it does seem to resolve the issue.https://lab.civicrm.org/dev/core/-/issues/3875Pressing return on additional participants page for event registration goes b...2023-06-03T19:57:34ZlarsssandergreenPressing return on additional participants page for event registration goes back to previous page instead of forwardThere are three buttons on the additional participant page: Go Back, Continue, Skip Participant. Since all three are type="submit", when you press the return/enter key, the first button of type="submit" is clicked, so you go back one pag...There are three buttons on the additional participant page: Go Back, Continue, Skip Participant. Since all three are type="submit", when you press the return/enter key, the first button of type="submit" is clicked, so you go back one page. Contrast with the primary participant registration page, where return does take you to the next page because there is only one button or with a contribution page where return takes you to the confirmation page, again because there is only one button.
The easiest fix would be to change the types of the other buttons to "button". The button type [is set here](https://github.com/civicrm/civicrm-core/blob/c94963f7637912571ce62b33de60f7d5ce640f69/CRM/Core/Form.php#L758) for all buttons as "submit" unless type="reset" is passed to addButtons. So I propose to review button types in use, setting those that make sense as "submit" (next, done, submit, upload, process, etc) and others as "button" (cancel, refresh). Any buttons without a type will be left as "submit" so as to avoid breaking anything.
There is also a class default added to buttons that have isDefault, but it's unclear to me what this does.https://lab.civicrm.org/dev/core/-/issues/4085SearchKit can't export more than a couple thousand rows2023-05-26T16:17:22ZJonGoldSearchKit can't export more than a couple thousand rowsOverview
----------------------------------------
When attempting to "Download Spreadsheet" in SK, it times out with more than a couple thousand rows. It's very PHP-intensive to do the pseudoconstant lookups, Smarty calculations, etc. ...Overview
----------------------------------------
When attempting to "Download Spreadsheet" in SK, it times out with more than a couple thousand rows. It's very PHP-intensive to do the pseudoconstant lookups, Smarty calculations, etc. That's not noticeable when it's calculating a page of 50, but doesn't scale.
Reproduction steps
----------------------------------------
1. Create an SK query that yields a large number of contacts. Ensure you have 2-3 pseudoconstant fields in your `SELECT`.
1. Attempt to export with "Download Spreadsheet"
Current behaviour
----------------------------------------
Times out, but appears to still be downloading.
Expected behaviour
----------------------------------------
Finishes successfully, or at least reports back to the user that the export won't finish.
Comments
----------------------------------------
Most systems that offer exports of large data sets - including our competitors like NationBuilder etc., but also many apps like PayPal - do not attempt to offer the export in real-time. They queue the export, then you visit a queue page to download the completed exports (most systems will email you when it's ready).
@eileen @totten I know you've both been working on queuing mechanisms. I can drum up some funding (maybe $750 USD? Need to check) to support this. I'm not sure if it's a heavy lift or a light one though, so I don't know if that's a substantial amount of funding.
Ideally, this would work like imports or CiviMail, where the queue job can build the export over multiple cron runs. The client who would fund this is on Pantheon, which doesn't have an unlimited cron job run time.https://lab.civicrm.org/dev/core/-/issues/3868Link contribution view with asssociated entity2023-05-18T23:37:57ZyashodhaLink contribution view with asssociated entityWhen you view a contribution, there's no way to know whether this contribution was done as a part of membership, pledge or an event registration.
I propose provide this additional data. Display this under total amount
e,g
![Screens...When you view a contribution, there's no way to know whether this contribution was done as a part of membership, pledge or an event registration.
I propose provide this additional data. Display this under total amount
e,g
![Screenshot_from_2022-09-23_19-15-29](/uploads/24028770f5b17e20ab40334973061b05/Screenshot_from_2022-09-23_19-15-29.png)
Membership will be a link to membership view page.
(depending on the related entity we display the link)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4141API4: When searching by date range, end of range is not included2023-04-22T17:05:33ZlarsssandergreenAPI4: When searching by date range, end of range is not includedWhen you use SearchKit to search by date range on a datetime field (i.e. between two dates), the end date is not included in the results because it interprets 12/31/2022 as 20221231000000 instead of the expected 20221231235959. The same ...When you use SearchKit to search by date range on a datetime field (i.e. between two dates), the end date is not included in the results because it interprets 12/31/2022 as 20221231000000 instead of the expected 20221231235959. The same happens in FormBuilder with a date filter and Choose date range. This comes from API4, where `->addWhere('receive_date', 'BETWEEN', ['2022-01-01', '2022-12-31'])` is interpreted as to 20221231000000 rather than to 20221231235959.
This is quite confusing for users, e.g. when last quarter doesn't give the same results as 10/01/2022 - 12/31/2022.
I think the fix is simply to use a default time of 23:59:59 if none is specified for an end date, but I'm not sure if that might cause unexpected behaviour elsewhere.