Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-04-22T16:23:05Zhttps://lab.civicrm.org/dev/core/-/issues/3406Allow duplicate backend registration when event has "allow same participant e...2022-04-22T16:23:05ZbgmAllow duplicate backend registration when event has "allow same participant emails"We have the following use-case:
* Organisation using CiviEvent for a box office, i.e. to sell tickets for concerts
* People may buy multiple tickets for concerts, and often not at the same time.
For example, they may have bought a tick...We have the following use-case:
* Organisation using CiviEvent for a box office, i.e. to sell tickets for concerts
* People may buy multiple tickets for concerts, and often not at the same time.
For example, they may have bought a ticket during pre-sales, then later bought a ticket as a gift for a friend.
The front-end allows this, thanks for the "allow same participant emails". However the backend does not validate this option. When adding a backend registration, if the participant has already bought a ticket, the admin will get an error message: "This contact has already been assigned to this event."
Looking at Stack Exchange, I found this thread:
https://civicrm.stackexchange.com/questions/15826/enable-multiple-event-registration-for-same-purchaser-participant
Since we use the Event Cart and the [boxoffice](https://lab.civicrm.org/extensions/boxoffice) extension, I implemented a workaround here:
https://lab.civicrm.org/extensions/boxoffice/commit/526703f40c772930bac18e16f71e918e5bd50fb1#d8fbb70d3d7f43c0bde3f9f1385c3d03e740a39f_0_79
but we could avoid all those overrides by adding those 4 lines of code to CRM_Event_Form_Participant.
cc @cmtool5.17.0https://lab.civicrm.org/dev/core/-/issues/3405Event Templates: do not auto-populate the Start Date / End Date2022-04-22T16:23:02ZbgmEvent Templates: do not auto-populate the Start Date / End DateWhen creating an event using an event template, the Start Date is automatically set to the date when the template was created.
To reproduce:
* Create an Event Template (Administer > Events > Event Templates)
* Wait one day, or set the ...When creating an event using an event template, the Start Date is automatically set to the date when the template was created.
To reproduce:
* Create an Event Template (Administer > Events > Event Templates)
* Wait one day, or set the `start_date` to some past date (templates are saved as regular events in the `civicrm_event` database table).
* Create a new Event, and use the template that was created.
* Notice how the start date is automatically set.
This might not sound like a big deal, but when the event template was created in 2015, it gets pretty annoying to have to also click to change the year (and it's easy to overlook).
This was also reported on Stack Exchange:
https://civicrm.stackexchange.com/questions/28159/event-template-start-date
cc @justinfreeman @cividesk @lcdweb (because you seem to be using Events a lot)5.17.0https://lab.civicrm.org/dev/core/-/issues/3373Event Cart: does not save participant custom fields on checkout2022-04-22T16:22:03ZbgmEvent Cart: does not save participant custom fields on checkoutHow to reproduce:
* Create a custom group for Participants, add a custom field in it
* Create a profile for participants: first name, last name, your-participant-custom-field. Don't set a default value.
* Add an event to cart, checkout....How to reproduce:
* Create a custom group for Participants, add a custom field in it
* Create a profile for participants: first name, last name, your-participant-custom-field. Don't set a default value.
* Add an event to cart, checkout.
Result: the your-participant-custom-field will not have been saved.5.17.0bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/1073Performance : Expose some important smarty configuration variables outside th...2021-03-29T14:14:27ZVangelisPPerformance : Expose some important smarty configuration variables outside the smarty classWhile working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the...While working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the results. That is on the contact display page, on search, advanced search and so on.
Added Redis caching to CiviCRM, helped with a bit of small improvement but again, the delay was there.
Digging deeper with XHProf, I've found out that for every page that was loading, Smarty was checking if the templates needed recompiling.
Long story short, inside the /packages/Smarty/Smarty.class.php there's a variable that is `true` by default:
`var $compile_check = true;`
Description is the following:
> This tells Smarty whether to check for recompiling or not. Recompiling does not need to happen unless a template or config file is changed. Typically you enable this during development, and disable for production.
Disabling this in production, i did see a big improvement in terms of speed, as Smarty is now being instructed not scan every time if it needs to recompile the templates.
My suggestion would be to expose that variable (along with `$caching`) as a constant so that for example we can add it to `settings.php` as 'false' in production environments.
I could provide a patch (if needed) that does that.
PS. "complex" = a CiviCRM instance with many extensions and many tpl injections through custom extensions.5.17.0https://lab.civicrm.org/dev/core/-/issues/1226Smart groups: Relative date filters saved incorrectly2019-09-03T06:50:14ZPradeep Nayakpradpnayak@gmail.comSmart groups: Relative date filters saved incorrectly(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not sa...(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not saved correctly.
This issue entails two aspects:
1. (*Code update in 5.16.4*) Fix the code so that smart groups are properly saved
2. (*Data cleanup; case-by-case*) Identify any smart-groups which were created or edited in the past month (5.16.x). Determine if they should be updated to use a relative date filter.
The following fields are believed to affected:
* `log_date_relative`
* `pledge_payment_date_relative`
* `pledge_start_date_relative`
* `pledge_end_date_relative`
* `pledge_create_date_relative`
* `member_join_date_relative`
* `member_start_date_relative`
* `member_end_date_relative`
* `birth_date_relative`
* `deceased_date_relative`
* `mailing_date_relative`
* `relation_date_relative`
* `relation_start_date_relative`
* `relation_end_date_relative`
* `relation_action_date_relative`
* `contribution_recur_start_date_relative`
* `contribution_recur_next_sched_contribution_date_relative`
* `contribution_recur_cancel_date_relative`
* `contribution_recur_end_date_relative`
* `contribution_recur_create_date_relative`
* `contribution_recur_modified_date_relative`
* `contribution_recur_failure_retry_date_relative`5.17.0Pradeep Nayakpradpnayak@gmail.comPradeep Nayakpradpnayak@gmail.comhttps://lab.civicrm.org/dev/core/-/issues/1061Bad popup on update recurring screen2019-08-21T16:48:10ZeileenBad popup on update recurring screenWe are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to M...We are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to March 2018 when custom data was added to this form (by @mattwire ) - which means we don't need to target the rc & I'm inclined to focus on 'the right fix' on master.
Fundamentally we have a backoffice form that is being exposed for front end users. I have personally proposed doing similar to the 'Add Payment' form recently so it probably bares a little thought. In this case the custom data is not accessible to checksum accessors of the page & superficially the problem is not that it is not available but that it is noisily not available.
I feel like at a conceptual level we probably want to either
1) say front end forms are front end forms and back end forms are back end forms and never the twain shall meet or
2) set the front end form flag whenever a both-use-form is accessed with a checksum
In terms of the custom data I feel the safest option is just to say 'don't expose custom data on both-use forms to users without Access CiviCRM'. If people want to this might not be the right form approach for them - they can actually probably intervene by hook but the risk of exposing inappropriate custom data fields seems real.
This probably also impacts on theming & provides an obvious way not to present un-themed versions of these pages (@seamuslee @totten )5.17.0https://lab.civicrm.org/dev/core/-/issues/1109Contact Reference fields are not updated when merging contacts2019-08-08T03:27:12ZPatrick Figelpfigel@greenpeace.orgContact Reference fields are not updated when merging contactsWhen contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at som...When contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at some point after that. (Confirmed as broken in 5.7, 5.13 and master.)5.17.0https://lab.civicrm.org/dev/core/-/issues/1170Fix getLoginURL() for Backdrop2019-08-08T03:16:12ZherbdoolFix getLoginURL() for BackdropBecause of https://github.com/backdrop/backdrop-issues/issues/260, any anonymous visits to `/user` will redirect to `/user/login`. Currently `CRM_Utils_System_Backdrop::getLoginURL()` creates a link to `/user?destination...` and this URL...Because of https://github.com/backdrop/backdrop-issues/issues/260, any anonymous visits to `/user` will redirect to `/user/login`. Currently `CRM_Utils_System_Backdrop::getLoginURL()` creates a link to `/user?destination...` and this URL will automatically try to redirect. And because of Backdrop/Drupal allowing the `?destination` parameter to override other redirects, it will automatically go to that destination instead of staying at `/user` or even `/user/login`
There's probably an easy fix by just changing getLoginURL to point to `/user/login` and no immediate redirect will happen.5.17.0https://lab.civicrm.org/dev/core/-/issues/1171unreleased regression2019-08-08T01:27:17Zeileenunreleased regressionnew enotices on importing with an import mapping (not to be confused with the pre-existing ones)
https://github.com/civicrm/civicrm-core/pull/14978new enotices on importing with an import mapping (not to be confused with the pre-existing ones)
https://github.com/civicrm/civicrm-core/pull/149785.17.0https://lab.civicrm.org/dev/drupal/-/issues/72confirmation screen shows internal profile name not public title (reg screen ...2019-08-07T18:07:13ZDLaurysconfirmation screen shows internal profile name not public title (reg screen shows public title)The profile names that appear on the screen when registering for an event don't match between the register screen and the confirmation screen. The register screen uses the 'public title' of the profile, which is great! But then the confi...The profile names that appear on the screen when registering for an event don't match between the register screen and the confirmation screen. The register screen uses the 'public title' of the profile, which is great! But then the confirmation screen shows the internal profile name.5.17.0https://lab.civicrm.org/dev/core/-/issues/949Export table field size is inadequate for State/Province data values2019-08-06T20:35:08ZorigamiusaExport table field size is inadequate for State/Province data valuesExporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary ...Exporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary table is created with a column size of varchar(16), presumably because the State/Province key is stored as a LONG; but the exported quantity is the value, which could be of arbitrary length (and certainly includes examples longer than 16 characters in normal usage).
This appears to be a similar issue to https://lab.civicrm.org/dev/core/issues/181 and https://lab.civicrm.org/dev/core/issues/877.5.17.0https://lab.civicrm.org/dev/core/-/issues/1135Participants having multiple roles affects maximum event registration count2019-08-05T19:47:12ZDon WijesooriyaParticipants having multiple roles affects maximum event registration countIf you add multiple participant roles for a participant entry, it affects the event full count.
### Steps to reproduce
1. On dmaster, create a new event
2. Enable online registration and set "Max Number of Participants" to 1
3. Go to l...If you add multiple participant roles for a participant entry, it affects the event full count.
### Steps to reproduce
1. On dmaster, create a new event
2. Enable online registration and set "Max Number of Participants" to 1
3. Go to live event registration page. You should be able to register
4. Now add a new registration to a different contact from backend.
5. Once again go to live event registration page. Now it should show the event full message.
6. Go back to the other contact's events. Edit the event participant entry and add another role such as "Host".
7. Now go to the event registration page and you will be able to register for the maxed out event
### Issue
After inspecting `CRM_Event_BAO_Participant::eventFull()` the following line assumes there will only be one value in the field
````php
$where[] = " participant.role_id IN ( '" . implode("', '", $escapedRoles) . "' ) ";
````
Therefore when you have multiple values it won't work properly.
### Solution
I used regular expression code that's used in `CRM_Event_BAO_Query::whereClauseSingle()` under `case 'participant_role_id'`. This is a simple workaround I could think of. Haven't tested in all other scenarios.
````php
$regexp = "([[:cntrl:]]|^)" . implode('([[:cntrl:]]|$)|([[:cntrl:]]|^)', $escapedRoles) . "([[:cntrl:]]|$)";
$where[] = " participant.role_id REGEXP '{$regexp}'";
````5.17.0https://lab.civicrm.org/dev/core/-/issues/439Contact Reference Field Cutoff on Export2019-08-04T18:55:16ZhershelContact Reference Field Cutoff on ExportOn a brand new Drupal 7 / CiviCRM 5.6.0 install I created a custom field group for Grants and added one Contact Reference field and then created 2 grants. When I search for grants and export and try to export that Contact Reference field...On a brand new Drupal 7 / CiviCRM 5.6.0 install I created a custom field group for Grants and added one Contact Reference field and then created 2 grants. When I search for grants and export and try to export that Contact Reference field, the name of the Contact is limited to 16 characters.
Further testing indicates that the name of a Contact Reference field on a Contact record also is limited to 16 characters when exported.
First reported here: https://civicrm.stackexchange.com/questions/26835/grant-export-custom-field-cutoff5.17.0https://lab.civicrm.org/dev/core/-/issues/961Contribution page including 2 email fields does not respect dedupe rule.2019-08-02T01:27:13ZjitendraContribution page including 2 email fields does not respect dedupe rule.Unsupervised rule fails if we have 2 email fields to match on with latter set as empty. To replicate -
- Add a profile with first name, last name, billing email and work email.
- Create a contact with first name = "Test", Last name = "D...Unsupervised rule fails if we have 2 email fields to match on with latter set as empty. To replicate -
- Add a profile with first name, last name, billing email and work email.
- Create a contact with first name = "Test", Last name = "Dedupe" and email = "test@example.com"
- Add the profile to a contribution page.
- Submit the contribution page anonymously and enter First name = Test, Last name = "Dedupe" and billing email = "test@example.com". Keep work email as empty.
- Complete the payment.
![image](/uploads/43e2533c1a6f37dc9251b380755ca0f9/image.png)
- The payment should be recorded against the existing contact based on dedupe matching.
- As we do not have any value filled for second email field, dedupe fails and a new contact is created with same details.5.17.0jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/1104Make admin panels hookable2019-08-01T04:07:14ZyashodhaMake admin panels hookableMake it easy to show/hide items on administer screen.Make it easy to show/hide items on administer screen.5.17.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/987Issue with alterReportVars hook invoke2019-08-01T04:07:14ZsushantpIssue with alterReportVars hook invokeCurrently alterReportVars hook is invoked after grand total and section total calculations.
When alterReportVars used for altering any values in report rows , calculations does not take that into
consideration.
alterReportVars hook ...Currently alterReportVars hook is invoked after grand total and section total calculations.
When alterReportVars used for altering any values in report rows , calculations does not take that into
consideration.
alterReportVars hook should invoked before grand total and section total calculations.5.17.0https://lab.civicrm.org/dev/financial/-/issues/36Bug, cannot import Contributions because the import requires the payment meth...2019-07-31T20:48:05Zjustinfreeman (Agileware)Bug, cannot import Contributions because the import requires the payment method, payment instrument ID, not the payment instrument labelBug, cannot import Contributions because the import requires the payment method, payment instrument ID, not the payment instrument label.
For example: Contributions being imported with payment instrument (payment method) of "Credit card...Bug, cannot import Contributions because the import requires the payment method, payment instrument ID, not the payment instrument label.
For example: Contributions being imported with payment instrument (payment method) of "Credit card", "Cheque" will fail to import. However if these labels are replaced with the values, 1 (Credit card) and 4 (Cheque) then the import will succeed.
Importing contribution payment_instrument_id is formatted in following line of code.
https://github.com/agileware/civicrm-core/blob/master/CRM/Utils/DeprecatedUtils.php#L246
Code gets the option Value instead of a Name, the contribution API accepts the payment_instrument by Value. Logic is updated in Utils to consider name instead of ID. This function is getting called from only Contribution import.
PR submitted, see https://github.com/civicrm/civicrm-core/pull/13125
Agileware Ref: CIVICRM-11035.17.0justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/1118Case summary report filters incorrectly for case type2019-07-21T23:07:54ZDeepak SrivastavaCase summary report filters incorrectly for case typeCase summary report uses REGEXP filtering for case type:
`WHERE case_civireport.case_type_id REGEXP '[[:cntrl:]]*5[[:cntrl:]]*' `
Which results in records where case type id consists of 5 (for this example).
![image](/uploads/485a42f6d...Case summary report uses REGEXP filtering for case type:
`WHERE case_civireport.case_type_id REGEXP '[[:cntrl:]]*5[[:cntrl:]]*' `
Which results in records where case type id consists of 5 (for this example).
![image](/uploads/485a42f6d595079ce990816695e1b4a6/image.png)
The clause looks old and appears to be based on assumption that case could be based on multiple case types. Case type however is an integer column and could use where() clause of CRM/Report/Form.php.
The problem also been raised on stack exchange - https://civicrm.stackexchange.com/questions/30573/case-type-filter-bug-in-case-summary-report-multiple-case-types-reported.
A PR would follow.5.17.0https://lab.civicrm.org/dev/core/-/issues/1133Payment method name is displayed instead of label in payment block for Manual...2019-07-19T20:27:43ZDon WijesooriyaPayment method name is displayed instead of label in payment block for Manual payment`getPaymentTypeLabel()` method in `CRM_Core_Payment_Manual` class returns payment method name instead of label.
````php
/**
* Get the name of the payment type.
*
* @return string
*/
public function getPaymentTypeLabel() ...`getPaymentTypeLabel()` method in `CRM_Core_Payment_Manual` class returns payment method name instead of label.
````php
/**
* Get the name of the payment type.
*
* @return string
*/
public function getPaymentTypeLabel() {
return CRM_Core_PseudoConstant::getName('CRM_Contribute_BAO_Contribution', 'payment_instrument_id', $this->getPaymentInstrumentID());
}
````
## Fix
````php
/**
* Get the name of the payment type.
*
* @return string
*/
public function getPaymentTypeLabel() {
return CRM_Core_PseudoConstant::getLabel('CRM_Contribute_BAO_Contribution', 'payment_instrument_id', $this->getPaymentInstrumentID());
}
````5.17.0https://lab.civicrm.org/dev/core/-/issues/1120Export help info does not match code2019-07-16T20:03:55ZeileenExport help info does not match codeIn the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04...In the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04_AM.png)
In the code the rules are that 2 or more contacts being merged use the rules (ie if contacts are merged then use the rules). (There is some mickey mouse separate handling where it seems the code attempts to only use the 'other' logic for 2 or more
I can't see why you wouldn't use the merge string for any merges - which would simplify the code a lot too
@lcdweb @colemanw thoughts - can we tweak the above to '(when merging contacts to one row)' & clean up the code to just do that (without extra code that with more or less success attempts to do ? something ? when there are only 2 & use the merge string where there is more than 2
I *think* the intent might have been that you could choose different behaviour for many vs just 2 but in practice you can't actually select that in the UI5.17.0