CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-03-20T01:39:56Zhttps://lab.civicrm.org/dev/core/-/issues/1921Remove unneccessary isoToDate function2023-03-20T01:39:56ZeileenRemove unneccessary isoToDate function**[CQ] Let's celebrate the recent 6 year anniversary of making isoToData unnecessary by getting it out of the code**
Prior to July 2014 the following would fail
```
$contribution->fetch();
$contribution->save();
```
because the fetch ...**[CQ] Let's celebrate the recent 6 year anniversary of making isoToData unnecessary by getting it out of the code**
Prior to July 2014 the following would fail
```
$contribution->fetch();
$contribution->save();
```
because the fetch format for dates was invalid for save.
However, that all changed once this was merged https://github.com/civicrm/civicrm-packages/commit/283da6111677fc2b0176902b4c9a5cbcf668a258
Except for the bits that provide handling for it still litter our codehttps://lab.civicrm.org/dev/core/-/issues/1Allow to search for "in progress" contributions2024-03-01T16:29:50ZxavierAllow to search for "in progress" contributionsThe search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on s...The search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on status "in progress". Worse case scenario, no contributions have this status, and it will return an empty list4.7.31https://lab.civicrm.org/dev/core/-/issues/2Display Inbound Email: linefeed suppressed2024-03-26T10:22:28ZDetlev SieberDisplay Inbound Email: linefeed suppressedWhen viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.When viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.4.7.31https://lab.civicrm.org/dev/core/-/issues/2204Proposal - make 5.33 the last CiviCRM version to support php 7.1 (agreed) and...2021-02-05T06:10:18ZeileenProposal - make 5.33 the last CiviCRM version to support php 7.1 (agreed) and mysql 5.6 (deferred) (& equivalent MariaDB version)This extracts from our end-of-life planning for old mysql versions
https://lab.civicrm.org/dev/core/-/issues/1681 and php versions https://lab.civicrm.org/dev/core/-/issues/1528 and makes the proposal that the 5.33 ESR is the last versi...This extracts from our end-of-life planning for old mysql versions
https://lab.civicrm.org/dev/core/-/issues/1681 and php versions https://lab.civicrm.org/dev/core/-/issues/1528 and makes the proposal that the 5.33 ESR is the last version to support php 7.1 and mysql 5.6. This means that sites can get up to 8 more months support on these versions for $120.
Background/ notes
- we have aligned recent end of life for php & mysql versions with ESR versions because it means that if there is an economic value to delaying upgrading people can opt in. If $120 doesn't seem like value for money then it's hard to make the case it is worth $x in developer time
- we have been announcing that both are EOL for ? 6 months? via system checks
- we haven't had a lot of push back from sites about previous EOL efforts on php versions. Generally once we stop supporting a php version there are a reasonable amount of breaking changes after the first 2-3 months
- we had annecdotal evidence from 2 partners that getting off mysql 5.5 was tricky for some sites. OTOH there are unlikely to be any breaking changes for quite some time for 5.6 sites for quite some time. It's likely they could continue to use 5.6 for a year or more after we stop supporting it - we just get to say 'sorry not supported' when those weird edge cases pop up around row format or it there is some unforseen reason for a breaking change
- mysql 8.0 is about to be released
- php 8.0 is about to be released
- generally our ability to support newer mysql versions / php versions has been delayed by difficulties around legacy support and we have effectively supported old versions at the expense of newer versions
- php stopped supporting php 7.1 about a year ago
- Oracle still appears to support php 5.6 (not sure if it's for free or not)5.34.0https://lab.civicrm.org/dev/core/-/issues/12Improvement: for crmUiWizard-driven workflows, scroll back to top between steps2023-06-23T17:54:21ZginkgofjgImprovement: for crmUiWizard-driven workflows, scroll back to top between stepsSome "steps" in a wizard are fairly long and require scrolling to reach all the required fields. See the CiviMail wizard (civicrm/a/#/mailing) for example.
Differences in height between the steps can make clicking the buttons that contr...Some "steps" in a wizard are fairly long and require scrolling to reach all the required fields. See the CiviMail wizard (civicrm/a/#/mailing) for example.
Differences in height between the steps can make clicking the buttons that control the workflow (back, forward, etc.) at the bottom of the wizard a jarring experience. Sometimes the next step is significantly shorter than the previous one, and the user is left looking at white space. Sometimes the next step is very similar to the previous step, and it is unclear that anything occurred after the user's click because the user's view hasn't changed.
In any case, a better user experience would be to move the user to the top of the wizard at each transition.5.0.0ginkgofjgginkgofjghttps://lab.civicrm.org/dev/core/-/issues/2098testMailReportForPrint outputs screeds of stuff into test log - fix2023-05-18T05:03:26ZeileentestMailReportForPrint outputs screeds of stuff into test log - fixhttps://lab.civicrm.org/dev/core/-/issues/2097Remove CIVICRM_FLEXMAILER_HACK_DELIVER2023-05-16T05:03:25ZeileenRemove CIVICRM_FLEXMAILER_HACK_DELIVERI started looking at fixing the memory leaks in MailingJob::runJobs (see #2073) - which is tested via MailingJob:;testMailerSendTest_email but the fact we pass $job out - to use memory & queries efficiently $job should be a CRM_Core_DAO:...I started looking at fixing the memory leaks in MailingJob::runJobs (see #2073) - which is tested via MailingJob:;testMailerSendTest_email but the fact we pass $job out - to use memory & queries efficiently $job should be a CRM_Core_DAO::executeQuery() object but it is a ```CRM_Mailing_BAO_MailingJob``` - there are also a couple of places that call functions on it that could be called statically if it were a $dao
Basically we should clear the mess up - or as a minimum for this ticket remove those weird constants CIVICRM_FLEXMAILER_HACK_DELIVER
@jamie @seamuslee @mattwire @tottenhttps://lab.civicrm.org/dev/core/-/issues/2033Performance - query analysis2020-10-13T02:06:15ZeileenPerformance - query analysisUsing the methodology described [here](https://lab.civicrm.org/extensions/systemtools/-/blob/master/README.md) I have analysed the queries to pipe 7 contributions into CiviCRM and analyse all the queries to see if we can eliminate some. ...Using the methodology described [here](https://lab.civicrm.org/extensions/systemtools/-/blob/master/README.md) I have analysed the queries to pipe 7 contributions into CiviCRM and analyse all the queries to see if we can eliminate some. Analysis follows (I will look to address some)
1. This is on a server that uses Redis with associated reduction of queries
2. Main civi api calls called are Contact.create & contribution.create.
3. None of the queries are slow - the focus here is on removing unnecessary queries from high volume code paths
4. All 7 contributions were inserted within the total time of one second. We normally process 2000 donations per code run so reducing 1 query per row saves 2000 per run
5. 18% of the total queries come from [this line of code](https://github.com/civicrm/civicrm-core/blob/d357f225f281a0862b67a60d027c703ed2292f8b/CRM/Core/BAO/Location.php#L73) for [this issue](https://issues.civicrm.org/jira/browse/CRM-5051). I believe the handling in the create classes likely makes it obsolete - https://lab.civicrm.org/dev/core/-/issues/2039
| Type of query | Count |proportion queries that are unnecessary|
|--------------------|-------|-------|
| Activity wrangling #2057 | 42 |high|
| CiviCRM log | 14 |medium|
| greeting queries | 6 |undetermined|
| Initialisation | 24 |low|
| Insert actions | 97 |Low|
| location queries #2039 | 119 |very high|
| metadata | 51 |low|
| pcp #2056 | 14 |high|
| uf match queries #2087 | 14 |medium|
| wmf | 14 |low|
| **Grand Total** | **395** |
Visual https://docs.google.com/document/d/1Min5WxmC8O0_MF4nK3LMTXcVZ-WQU_4k1WSJtMeqLl8/edit?usp=sharing
**Activity wrangling 42**
I haven't dug very far but my sense is this is likely about checking for existing activities linked to the contributions. As these are new contributions these checks might be largely avoidable
Examples
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:54 | SELECT * FROM `civicrm_activity_contact` WHERE ( `civicrm_activity_contact`.`activity_id` = 112183025 ) AND ( `civicrm_activity_contact`.`contact_id` = 46011835 ) AND ( `civicrm_activity_contact`.`record_type_id` = 2 ) | 0.000549 | 0 | 0 |
| 15/09/20 2:54 | SELECT * FROM `civicrm_activity_contact` WHERE ( `civicrm_activity_contact`.`activity_id` = 112183025 ) AND ( `civicrm_activity_contact`.`record_type_id` = 1 ) | 0.000606 | 0 | 0 |
| 15/09/20 2:54 | SELECT * FROM `civicrm_activity_contact` WHERE ( `civicrm_activity_contact`.`activity_id` = 112183025 ) AND ( `civicrm_activity_contact`.`record_type_id` = 2 ) | 0.000725 | 0 | 0 |
| 15/09/20 2:54 | SELECT * FROM `civicrm_activity_contact` WHERE ( `civicrm_activity_contact`.`activity_id` = 112183025 ) AND ( `civicrm_activity_contact`.`record_type_id` = 2 ) | 0.000605 | 1 | 1 |
| 15/09/20 2:54 | SELECT * FROM `civicrm_activity_contact` WHERE ( `civicrm_activity_contact`.`activity_id` = 112183025 ) AND ( `civicrm_activity_contact`.`record_type_id` = 3 ) | 0.000636 | 0 | 0 |
**CiviCRM Log = 14**
I split these out from the main insert queries as my feeling is that we don't need to add to civicrm log when logging is enabled - I'm pretty sure there is another GL on this & it's not quite that black and white
Examples
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
|15/09/20 2:54 |INSERT INTO `civicrm_log` (`entity_table` , `entity_id` , `data` , `modified_id` , `modified_date` ) VALUES ('civicrm_activity' , 112183024 , 'Activity created for source=46011834' , 46011834 , 20200909141546 )| |
**greeting queries = 6**
I haven't done any analysis on these - I suspect we have skipGreeting enabled in our api call so it's only 6
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:54 | SELECT contact_a.id as contact_id, contact_a.email_greeting_id as email_greeting_id, contact_a.postal_greeting_id as postal_greeting_id, contact_a.addressee_id as addressee_id, contact_a.addressee_display as addressee_display, contact_a.addressee_custom as addressee_custom, contact_a.email_greeting_display as email_greeting_display, contact_a.email_greeting_custom as email_greeting_custom, contact_a.postal_greeting_display as postal_greeting_display, contact_a.postal_greeting_custom as postal_greeting_custom FROM civicrm_contact contact_a WHERE ( contact_a.id = '46011839' ) LIMIT 0, 25 | 0.000734
| 15/09/20 2:54 | SELECT contact_a.id as contact_id, contact_a.email_greeting_id as email_greeting_id, contact_a.postal_greeting_id as postal_greeting_id, contact_a.addressee_id as addressee_id, contact_a.addressee_display as addressee_display, contact_a.addressee_custom as addressee_custom, contact_a.email_greeting_display as email_greeting_display, contact_a.email_greeting_custom as email_greeting_custom, contact_a.postal_greeting_display as postal_greeting_display, contact_a.postal_greeting_custom as postal_greeting_custom FROM civicrm_contact contact_a WHERE ( contact_a.id = '46011840' ) LIMIT 0, 25 | 0.000913 | 1 | 1 |
**Initialisation queries 24**
These are all pretty necessary
examples
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:53 | ( SELECT * FROM civicrm_menu WHERE path in ( 'civicrm' ) AND domain_id = 1 ORDER BY length(path) DESC LIMIT 1 ) UNION ( SELECT * FROM civicrm_menu WHERE path IN ( 'navigation' ) AND domain_id = 1 ) | 0.001571 | 1 | 1 |
| 15/09/20 2:53 | /*!40101 SET NAMES utf8 */ | | | |
| 15/09/20 2:53 | /*!50503 SET NAMES utf8mb4 */ | | | |
| 15/09/20 2:53 | BEGIN | | | |
**Insert actions 97**
This is where the work is done - nothing extraneous in the query list here
example
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:54 | INSERT INTO `civicrm_entity_financial_trxn` (`entity_table` , `entity_id` , `financial_trxn_id` , `amount` ) VALUES ('civicrm_financial_item' , 67488679 , 67491096 , 2.35 ) |
**Location queries 119**
These seem to be mainly extraneous. 70 of them come from what appears to be an outdated effort to handle is_primary (including 10 on open id which we don't support). At least some of the remaining 39 appear to be variants of this - this is the lowest hanging fruit
examples
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| Location queries | 15/09/20 2:54 | SELECT * FROM `civicrm_openid` WHERE ( ( is_primary = 0 OR is_primary IS NULL ) ) AND ( `civicrm_openid`.`contact_id` = 46011839 ) | 0.000643 | 0 | 0 |
| Location queries | 15/09/20 2:54 | SELECT * FROM `civicrm_openid` WHERE ( ( is_primary = 0 OR is_primary IS NULL ) ) AND ( `civicrm_openid`.`contact_id` = 46011840 ) | 0.000517 | 0 | 0 |
| Location queries | 15/09/20 2:54 | SELECT * FROM `civicrm_openid` WHERE ( ( is_primary = 1 ) ) AND ( `civicrm_openid`.`contact_id` = 46011834 ) | 0.001377 | 0 | 0 |
**Metadata queries 51**
This is less of a concern for us in this context as these (almost) all only ran once and none ran once per contribution. There is scope to improve them though & UI users would probably be helped. We would prefer they used the Redis-backed metadata cache
examples
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:54 | SELECT a.id as `id`, a.custom_group_id as `custom_group_id`, a.name as `name`, a.label as `label`, a.data_type as `data_type`, a.html_type as `html_type`, a.default_value as `default_value`, a.is_required as `is_required`, a.is_searchable as `is_searchable`, a.is_search_range as `is_search_range`, a.weight as `weight`, a.help_pre as `help_pre`, a.help_post as `help_post`, a.mask as `mask`, a.attributes as `attributes`, a.javascript as `javascript`, a.is_active as `is_active`, a.is_view as `is_view`, a.options_per_line as `options_per_line`, a.text_length as `text_length`, a.start_date_years as `start_date_years`, a.end_date_years as `end_date_years`, a.date_format as `date_format`, a.time_format as `time_format`, a.note_columns as `note_columns`, a.note_rows as `note_rows`, a.column_name as `column_name`, a.option_group_id as `option_group_id`, a.serialize as `serialize`, a.filter as `filter`, a.in_selector as `in_selector` FROM civicrm_custom_field a INNER JOIN `civicrm_custom_group` `custom_group_id_to_civicrm_custom_group` ON a.custom_group_id = custom_group_id_to_civicrm_custom_group.id WHERE (a.name = "original_currency" OR a.label = "original_currency") AND (custom_group_id_to_civicrm_custom_group.name = "contribution_extra" OR custom_group_id_to_civicrm_custom_group.title = "contribution_extra") LIMIT 25 OFFSET 0 | 0.001292 | 1 | 1 |
| 15/09/20 2:54 | SELECT a.id as `id`, a.custom_group_id as `custom_group_id`, a.name as `name`, a.label as `label`, a.data_type as `data_type`, a.html_type as `html_type`, a.default_value as `default_value`, a.is_required as `is_required`, a.is_searchable as `is_searchable`, a.is_search_range as `is_search_range`, a.weight as `weight`, a.help_pre as `help_pre`, a.help_post as `help_post`, a.mask as `mask`, a.attributes as `attributes`, a.javascript as `javascript`, a.is_active as `is_active`, a.is_view as `is_view`, a.options_per_line as `options_per_line`, a.text_length as `text_length`, a.start_date_years as `start_date_years`, a.end_date_years as `end_date_years`, a.date_format as `date_format`, a.time_format as `time_format`, a.note_columns as `note_columns`, a.note_rows as `note_rows`, a.column_name as `column_name`, a.option_group_id as `option_group_id`, a.serialize as `serialize`, a.filter as `filter`, a.in_selector as `in_selector` FROM civicrm_custom_field a INNER JOIN `civicrm_custom_group` `custom_group_id_to_civicrm_custom_group` ON a.custom_group_id = custom_group_id_to_civicrm_custom_group.id WHERE (a.name = "original_amount" OR a.label = "original_amount") AND (custom_group_id_to_civicrm_custom_group.name = "contribution_extra" OR custom_group_id_to_civicrm_custom_group.title = "contribution_extra") LIMIT 25 OFFSET 0 | 0.001085 | 1 | 1 |
| 15/09/20 2:54 | SELECT a.id as `id`, a.custom_group_id as `custom_group_id`, a.name as `name`, a.label as `label`, a.data_type as `data_type`, a.html_type as `html_type`, a.default_value as `default_value`, a.is_required as `is_required`, a.is_searchable as `is_searchable`, a.is_search_range as `is_search_range`, a.weight as `weight`, a.help_pre as `help_pre`, a.help_post as `help_post`, a.mask as `mask`, a.attributes as `attributes`, a.javascript as `javascript`, a.is_active as `is_active`, a.is_view as `is_view`, a.options_per_line as `options_per_line`, a.text_length as `text_length`, a.start_date_years as `start_date_years`, a.end_date_years as `end_date_years`, a.date_format as `date_format`, a.time_format as `time_format`, a.note_columns as `note_columns`, a.note_rows as `note_rows`, a.column_name as `column_name`, a.option_group_id as `option_group_id`, a.serialize as `serialize`, a.filter as `filter`, a.in_selector as `in_selector` FROM civicrm_custom_field a WHERE (a.name = "opt_in" OR a.label = "opt_in") LIMIT 25 OFFSET 0 | 0.001043 | 1 | 1 |
| 15/09/20 2:54 | SELECT a.id as `id`, a.entity_table as `entity_table`, a.entity_id as `entity_id`, a.account_relationship as `account_relationship`, a.financial_account_id as `financial_account_id` FROM civicrm_entity_financial_account a WHERE (a.entity_id = "9") AND (a.entity_table = "civicrm_financial_type") LIMIT 25 OFFSET 0 | 0.000718 | 6 | 6 |
| 15/09/20 2:54 | SELECT a.id as `id`, a.financial_account_id as `financial_account_id` FROM civicrm_entity_financial_account a WHERE (a.entity_table = "civicrm_option_value") AND (a.entity_id = "6342") LIMIT 1 OFFSET 0 | 0.001156 | 1 | 1 |
| 15/09/20 2:54 | SELECT a.id as `id`, a.financial_account_id as `financial_account_id` FROM civicrm_entity_financial_account a WHERE (a.entity_table = "civicrm_option_value") AND (a.entity_id = "844") LIMIT 1 OFFSET 0 | 0.000697 | 1 | 1 |
**PCP 14 queries**
I haven't done much analysis but I think these should be avoidable on sites without pcps - maybe the same way we no longer have product queries
examples
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:54 | SELECT id FROM civicrm_contribution_soft WHERE contribution_id = 49769031 AND pcp_id IS NOT NULL | 0.000624 | 0 | 0 |
| 15/09/20 2:54 | SELECT id FROM civicrm_contribution_soft WHERE contribution_id = 49769031 AND pcp_id IS NULL | 0.000616 | 0 | 0 |
| 15/09/20 2:54 | SELECT id FROM civicrm_contribution_soft WHERE contribution_id = 49769032 AND pcp_id IS NOT NULL | 0.000503 | 0 | 0 |
| 15/09/20 2:54 | SELECT id FROM civicrm_contribution_soft WHERE contribution_id = 49769032 AND pcp_id IS NULL | 0.000562 | 0 | 0 |
**uf match queries - 14**
These are not relevant to the incoming but not sure if they are avoidable - the duplication might be though
|timestamp|query|seconds|rows found|columns requested|
|----------|-------|-------|-------|-------|
| 15/09/20 2:54 | SELECT * FROM `civicrm_uf_match` WHERE ( `civicrm_uf_match`.`domain_id` = 1 ) AND ( `civicrm_uf_match`.`contact_id` = 46011840 ) | 0.000567 | 0 | 0 |
| 15/09/20 2:54 | SELECT * FROM `civicrm_uf_match` WHERE ( `civicrm_uf_match`.`domain_id` = 1 ) AND ( `civicrm_uf_match`.`contact_id` = 46011840 ) | 0.00053 | 0 | 0 |
**wmf queries - 14**
these are specific to our script5.32.0https://lab.civicrm.org/dev/core/-/issues/2032Proposal - add ability to segment query logs2020-10-08T00:28:45ZeileenProposal - add ability to segment query logsI'm just working on documenting how to use query logs per process & it occurs to me that it is a bit hard getting the process specific part out of a longer query log. I have a possible way we could break it out into files / give back mor...I'm just working on documenting how to use query logs per process & it occurs to me that it is a bit hard getting the process specific part out of a longer query log. I have a possible way we could break it out into files / give back more control which I will put up as part of a PR - but it is a bit hacky....5.31.0https://lab.civicrm.org/dev/core/-/issues/2031Proposal - add exclude dirs to default civicrm.settings.php or in buildkit fo...2021-01-15T05:31:11ZeileenProposal - add exclude dirs to default civicrm.settings.php or in buildkit for performanceI think we should consider building this recommendation into buildkit defaults, if not default on install.
https://docs.civicrm.org/sysadmin/en/latest/setup/optimizations/#exclude-dirs-that-do-not-need-to-be-scanned
If would give
1) be...I think we should consider building this recommendation into buildkit defaults, if not default on install.
https://docs.civicrm.org/sysadmin/en/latest/setup/optimizations/#exclude-dirs-that-do-not-need-to-be-scanned
If would give
1) better dev experience (less slowness) and
2) if there are any issues with that recommendation we'd notice them & hopefully update it.https://lab.civicrm.org/dev/core/-/issues/45show image files inline when clicked instead of download2023-02-09T05:03:28Zyashodhashow image files inline when clicked instead of downloadImage files when viewed should by default be shown inline unless explicitly set to query parameter "download=1"Image files when viewed should by default be shown inline unless explicitly set to query parameter "download=1"yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2017Remove unused functions -2023-05-12T05:03:32ZeileenRemove unused functions -Finding a few unused functions at the moment - mostly because I opened the open id code to try to find where an extraneous query is coming from.... isAllowedToLoginFinding a few unused functions at the moment - mostly because I opened the open id code to try to find where an extraneous query is coming from.... isAllowedToLoginhttps://lab.civicrm.org/dev/core/-/issues/2011Extension display UI improvement - separate out processors2023-05-02T05:03:21ZeileenExtension display UI improvement - separate out processorsA while back JohnFF did a PR to split the extension screen out into topics. It stalled because aspects around the categorisation were problematic & I understand there was some issue that became blocking.
However, I think we all agreed t...A while back JohnFF did a PR to split the extension screen out into topics. It stalled because aspects around the categorisation were problematic & I understand there was some issue that became blocking.
However, I think we all agreed the UI outcome was good.
We discussed today that we could bring this back in a more phased way - ie
1) scan for extensions with the tag topic:payment-processor
https://docs.civicrm.org/dev/en/latest/extensions/info-xml/#tags
If some are detected then display them in a separate PaymentProcessor's tab instead of the main tab
2) encourage payment processors to add the tab & add it to those we can
3) once people can see how it works with one generally agreed categorisation open up the discussion as to what other taxonomy we should use - I would expect the permitted ones in the original implementation would just be an array - so this would be technically easy but the discussion would be probably fairly extensive. Payment processors stand out, however, as being the part of the discussion that could be easily picked off
https://github.com/civicrm/civicrm-core/pull/12924https://lab.civicrm.org/dev/core/-/issues/2044Proposal apiv4 - revisit required parameters on location entities2020-10-02T01:41:10ZeileenProposal apiv4 - revisit required parameters on location entitiesI propose we adjust the location api required fields inn v4api
- Address - don't require contact_id, make location_type_id required in xml
- Email - don't require contact_id, make location_type_id required in xml
- Phone - don't require...I propose we adjust the location api required fields inn v4api
- Address - don't require contact_id, make location_type_id required in xml
- Email - don't require contact_id, make location_type_id required in xml
- Phone - don't require contact_id, make location_type_id required in xml
For all these entities we have a valid use case for no contact_id in the context of location blocks for addresses. I wanted to cleanup the code in ManageLocation around addresses https://github.com/civicrm/civicrm-core/pull/18488 & found I can't use Address::save to do in a better way due to the above
@colemanw how far did you go down this path?5.31.0https://lab.civicrm.org/dev/core/-/issues/2046Rationalise BAO create vs add functions2023-05-13T05:03:22ZeileenRationalise BAO create vs add functionsBack in the dawn of CiviCRM there was create and there was add and there was a theory behind them. Fast forward to today - there is still create & there is still add but not much sign of a theory behind them.
What has changed is that we...Back in the dawn of CiviCRM there was create and there was add and there was a theory behind them. Fast forward to today - there is still create & there is still add but not much sign of a theory behind them.
What has changed is that we no longer recommend either create is called directly
I proposed we set a goal (long term) to consolidate create & add functions into one function - with the functionality moved from add into create & add becoming a deprecated wrapper around create. The example I'm looking at is pretty straight forward - ie in Email BAO
1) With this PR https://github.com/civicrm/civicrm-core/pull/18494 add is no longer called (seemingly not even in universe)
2) the only thing create does that add doesn't is handlePrimary so there is a weak case for a separate add.
I'll put up a PR for the change to Email - to demo it - it doesn't turn out to be an easy merge I'll close it & continue to track here.
@colemanw @mattwire @monish.deb @seamusleehttps://lab.civicrm.org/dev/core/-/issues/91Prevent un-workable searches in search builder (was search builder improvements)2018-05-03T23:37:58ZMonish DebPrevent un-workable searches in search builder (was search builder improvements)Earlier there was a requirement where we need to remove specific MySQL operators which are not valid for specific data type e.g. String type doesn't work with >, <, <= and >= operators. And here's the fix https://github.com/civicrm/civic...Earlier there was a requirement where we need to remove specific MySQL operators which are not valid for specific data type e.g. String type doesn't work with >, <, <= and >= operators. And here's the fix https://github.com/civicrm/civicrm-core/commit/759094bdfa40531e4ec0cf0a644d9edd6b9247cf done earlier as per which it is fetching all columns which are String type and passing them into a separate JSON string identified as ```stringFields``` and another formatted list of valid string operators as ```stringOperators```. Similarly to identify date fields and to do a specific operation on such fields we are passing another variable ```dateFields```. These JSON object in JS are later used to specific operations. Now on the other hand, recently, I encountered another issue where the Boolean type columns don't work with IS EMPTY/IS NOT EMPTY operator and eventually leads to DB syntax error. So if I follow the same approach I need to assign another JSON string, which won't be an ideal fix. This lead me to do following 3 changes to improve the code:
1. Assign a single list of all data columns which are either Boolean, String or Date (as currently, these are the only kind that needs attention)
2. Use this list (as ```fieldTypes```) in JS to filter the operator or do field specific operations like covert a input search field to datepicker if the chosen search field is date kind.
3. Reduce list of variable assignment.5.2.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2420Add no results found on empty civireports dashlet2021-03-28T16:35:20ZeileenAdd no results found on empty civireports dashletI've had a customer report that the dashlets are borked post upgrade. We are using shoreditch & I am investigating this issue https://github.com/civicrm/org.civicrm.shoreditch/issues/484
However in the context of grenwich I have noticed...I've had a customer report that the dashlets are borked post upgrade. We are using shoreditch & I am investigating this issue https://github.com/civicrm/org.civicrm.shoreditch/issues/484
However in the context of grenwich I have noticed 2 things - the first of which is this issue - notably that part of the user's confusion was the blank box.
This box is blank in 5.30 and in dmaster (per below) so it is not new but I think we should have some indicator of lack of results rather than empty
![image](https://user-images.githubusercontent.com/336308/109080485-89aab380-7765-11eb-874f-962f49e22ada.png)
![image](https://user-images.githubusercontent.com/336308/109080515-9929fc80-7765-11eb-82b4-26e463e60d0d.png)5.36.0https://lab.civicrm.org/dev/core/-/issues/113Add new api handler 'current_domain' along the lines of 'user_contact_id'2022-06-13T01:56:11ZeileenAdd new api handler 'current_domain' along the lines of 'user_contact_id'Several api accept domain_id & in almost all cases the value passed is the current domain id. I think we should be able to set that as a default for api like membership type, instead of requiring it to be passed in as is currently the ca...Several api accept domain_id & in almost all cases the value passed is the current domain id. I think we should be able to set that as a default for api like membership type, instead of requiring it to be passed in as is currently the case.
With this we could change
```
function _civicrm_api3_membership_type_create_spec(&$params) {
// todo could set default here probably
$params['domain_id']['api.required'] = 1;
```
to
```
function _civicrm_api3_membership_type_create_spec(&$params) {
$params['domain_id']['api.default'] = 'current_domain';
```
We have a similar thing in place for 'user_contact_id' here
https://github.com/eileenmcnaughton/civicrm-core/blob/fee14197b427c1781e369e5bfd36816afad6d7ee/api/v3/utils.php#L2086 and I feel we could expand that piece of code.
Pinging @totten because Tim re-wrote that earlier handling of user_contact_id & may have some points he wishes to interjecthttps://lab.civicrm.org/dev/core/-/issues/115Proposal - create fields array standard & generic field template/s for it & f...2022-10-11T15:26:36ZeileenProposal - create fields array standard & generic field template/s for it & for fields, work towards generic entity form templateWe have a generalised issue where we want people to write extensions to alter CiviCRM but in many cases the way CiviCRM is structured makes that difficult and unmaintainable. As part of pushing people out to extensions we also need to wo...We have a generalised issue where we want people to write extensions to alter CiviCRM but in many cases the way CiviCRM is structured makes that difficult and unmaintainable. As part of pushing people out to extensions we also need to work to improve core code to support that purpose.
In the 5.x series we have made it easier for extension writers to store entity specific data by extending custom fields to (almost) all entities via the api*. However, it is still very difficult for extension writers to inject these fields, or other fields, into forms or to remove or re-order them. In general our approach has been to make things more metadata driven but we have not really standardised how to do this for templates. Conversely we already have examples in our code of templates that have been re-written to support output being modified by a php hook - (notably it is possible to alter the Billing fields on the payment form & the output columns in the contribution search from a php hook because metadata is assigned to the template & processed in the template) but we have not standardised those approaches into a recommendation.
To be clear - this proposal is NOT about going through all our forms and altering them to be more editable - it's about agreeing what we are working towards when we ARE editing forms. Currently it is possible to say
* "we are working towards replacing jcalendar.tpl with datepicker fields and when we touch date fields we should attempt to convert them"
* "we are working towards replacing non-metadata ways of adding fields to a form with addField and when we touch fields not added that way we should attempt to convert them"
Conversely we would say "if you are trying to fix the way a datefield is handling date defaults and the field is a jcalendar field we expect the fix to be converting it to a datepicker field rather than adding extra mangling for the legacy method".
In this case we would say
* "we are working towards assigning a standardised array of fields to a form & a tpl way of handling them and when we are working on a form we should seek to convert them"
(Generally we do require that PRs are improving the consistency & quality of our codebase & compliance with code-directions when we merge them)
I would note that complex forms like Contribution & Event forms might make poor candidates for tpl standardisation but a lot of our forms are simple settings forms or editing basic entities and these are good candidates for being generic & standardised. (This is allied with fixing the forms such that IF custom data is enabled on the entity THEN it can be altered via the form - which I will cover separately)
There are 2 open PRs which revolve around making tpls more generic, more metadata driven & more form-alterable
https://github.com/civicrm/civicrm-core/pull/12128/files#diff-1f76de158e02dfb7afa76303ef60e9ebR27
and https://github.com/civicrm/civicrm-core/pull/12078
The proposal would be that where it is possible to iterate through fields we assign them to the tpl in an array that looks like
```
$this-assign('entityFields', [
'field_1' => [
'name' => 'field_1',
'description' => ts("description to show below field"),
'help' => ['id' => 'id-field_1, 'file' => 'CRM/Contact/Form/Contact',
'is_add_translate_dialog' => 1,
],
'field_1' => ['name' => 'field_1'],
'money_field' => ['name' => 'money', 'formatter' => 'crmMoney'],
'weird_looking_field' => [
'name' => 'weird_looking_field',
'template' => CRM/Member/Form/MembershipType/weird_looking_field.tpl',
```
In practice some helpers would be involved in building the array so that fields like is_add_translate_dialog are derived from existing metadata. That would also potentially apply to keys like description, help & formatter. It is expected that if a field were to use a field specific template it would be under the path of the form.
The form template would then work towards looking more like
```
{foreach from=$entityFields item=fieldSpec}
{assign var=fieldName value=$fieldSpec.name}
<tr class="crm-{$entityInClassFormat}-form-block-{$fieldName}">
{include file="CRM/Core/Form/Field.tpl"}
</tr>
{/foreach}
```
With the tpl being
```
{if $fieldSpec.template}
{include file=$fieldSpec.template}
{else}
<td class="label">{$form.$fieldName.label}
{if $fieldSpec.help}{assign var=help value=$fieldSpec.help}{capture assign=helpFile}{if $fieldSpec.help}
{$fieldSpec.help}
{else}''{/if}
{/capture}{help id=$help.id file=$help.file}{/if}
{if $action == 2 && $fieldSpec.is_add_translate_dialog}{include file='CRM/Core/I18n/Dialog.tpl' table=$entityTable field=$fieldName id=$entityID}{/if}
</td>
<td>{if $form.$fieldName.html}{if $fieldSpec.formatter === 'crmMoney'}{$form.$fieldName.html|crmMoney}{else}{$form.$fieldName.html}{/if}{else}{$fieldSpec.place_holder}{/if}<br />
{if $fieldSpec.description}<span class="description">{$fieldSpec.description}</span>{/if}
</td>
{/if}
```
In some cases it might be too hard to make the form iterate through an array but individual fields could be converted - either in order to make that field hook alterable - (ie. the hook could then change the description metadata, or suppress a field) or as part of chipping away at the conversion
```
{assign var=fieldName value='my_converted_field'}
<tr class="crm-{$entityInClassFormat}-form-block-{$fieldName}">
{include file="CRM/Core/Form/Field.tpl"}
</tr>
```
* Note to enable custom data for a new type in an extension use code like the following
```
$optionValues = civicrm_api3('OptionValue', 'get', [
'option_group_id' => 'cg_extend_objects',
'name' => 'civicrm_relationship_type'
]);
if (!$optionValues['count']) {
civicrm_api3('OptionValue', 'create', [
'option_group_id' => 'cg_extend_objects',
'name' => 'civicrm_relationship_type',
'label' => ts('Relationship Type'),
'value' => 'RelationshipType',
]);
}
```https://lab.civicrm.org/dev/core/-/issues/117Remove usage of each() This is deprecated in php7.22018-05-28T02:48:08ZseamusleeRemove usage of each() This is deprecated in php7.2The following parts of the code still used each() which is an older format of foreach
```
CRM/Activity/BAO/Query.php: while (list(, $k) = each($value)) {
CRM/Activity/BAO/Query.php: while (list($k, $v) = each($value)...The following parts of the code still used each() which is an older format of foreach
```
CRM/Activity/BAO/Query.php: while (list(, $k) = each($value)) {
CRM/Activity/BAO/Query.php: while (list($k, $v) = each($value)) {
CRM/Case/XMLProcessor/Report.php: while (list($gid, $group_values) = each($groupTree)) {
CRM/Case/XMLProcessor/Report.php: while (list($id, $field_values) = each($group_values['fields'])) {
CRM/Event/Form/Participant.php: while (list($k, $dupeCheckContactId) = each($this->_contactIds)) {
CRM/Member/Form/MembershipView.php: $dir = each($relDirection);
CRM/Member/BAO/Membership.php: while (($available > 0) && ($params = each($queue))) {
CRM/Pledge/BAO/Pledge.php: list($field, $value) = each($startDate);
CRM/Pledge/BAO/PledgeBlock.php: list($field, $value) = each($date);
CRM/Report/Form/Contribute/Recur.php: while (list(, $suffix) = each($date_suffixes)) {
CRM/Report/Form/ActivitySummary.php: while (list(, $suffix) = each($date_suffixes)) {
CRM/Utils/Migrate/Import.php: while (list($group_id, $fields) = each($fields_indexed_by_group_id)) {
CRM/Utils/Migrate/Import.php: while (list(, $customFieldXML) = each($fields)) {
CRM/Utils/Token.php: while (list($key) = each($greetingTokens)) {
```
ping @eileen @monish.deb5.3.0https://lab.civicrm.org/dev/core/-/issues/151Action to Update Recurring Contributions From Membership View is Never Shown2018-06-20T20:41:20ZCamilo RodríguezAction to Update Recurring Contributions From Membership View is Never Shown## Overview
The table added to view recurring contributions form the membership details view (https://lab.civicrm.org/dev/core/issues/38) was never showing the 'Edit' action. The table shown when looking at recurring contributions from w...## Overview
The table added to view recurring contributions form the membership details view (https://lab.civicrm.org/dev/core/issues/38) was never showing the 'Edit' action. The table shown when looking at recurring contributions from within a membership should behave exactly as the table shown on a contact's **Contributions** tab.
## How it Works Currently
The table added to view recurring contributions form the membership details view was never showing the 'Edit' action, even though the user had all necessary permissions.
## How it Should Work
If the 'Edit' action is shown on the list of recurring contributions of a contact on **Contributions** tab, it should also be available on the list shown within a membership.
## Comments
Related to change introduced in #385.4.0https://lab.civicrm.org/dev/core/-/issues/280Deleting membership types do not remove price field values from online member...2022-09-09T05:03:27ZyashodhaDeleting membership types do not remove price field values from online membership formsSteps to replicate:
------------------
1. Create a price field with options(select/checkbox/radio).
2. Choose an option related to a membership type.
3. Delete the membership type and it sets NULL membership type for the price option wi...Steps to replicate:
------------------
1. Create a price field with options(select/checkbox/radio).
2. Choose an option related to a membership type.
3. Delete the membership type and it sets NULL membership type for the price option without any indications.
Desired behavior:
-----------------
**Delete membership**
I would like to get some input about the behavior-
1. When admin tries to delete a membership type, check for any related price fields and if yes, throw a form rule implying them to delete the price field first.
2. Or just show warning message with list of membership type used in price field and allow anyway.
**Disabled Membership Type**
I would like to get some input about the behavior-
1. Show warning Message on disable action and if yes, skip building price field option related to disabled membership type.
2. User can dismiss warning message but can't continue with disablement of membership typeyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2131New deprecation Warning alternative2021-01-03T23:19:01ZeileenNew deprecation Warning alternativeWe were adding CRM_Core_Error::deprecationWarning to code that we wanted to be avoided. It was discussed in matter-most that it was a bit inaccurate so the bar for deprecating code became that we had to agree a new function first.
I pre...We were adding CRM_Core_Error::deprecationWarning to code that we wanted to be avoided. It was discussed in matter-most that it was a bit inaccurate so the bar for deprecating code became that we had to agree a new function first.
I pretty much stopped deprecating code after that but the deprecation process has been really helpful and the helper is much more grepable - in the meantime I'll switch back to
Civi::log()->warning("$className needs to be regenerated. Missing getEntityTitle method.", ['civi.tag' => 'deprecated']);5.34.0https://lab.civicrm.org/dev/core/-/issues/320Current Employer only allows you to filter by static groups, not all groups2022-08-30T15:42:55ZjamieCurrent Employer only allows you to filter by static groups, not all groupsI suspect this is just old code that has not been updated to use the _groupFilter property.I suspect this is just old code that has not been updated to use the _groupFilter property.https://lab.civicrm.org/dev/core/-/issues/335Warning that $greetingToken is not always an array2021-09-12T21:51:54ZgharrisWarning that $greetingToken is not always an arrayWhen adding Activities to Scheduled Reminders, I came across a couple of warnings coming from core/CRM/Utils/Token.php. (https://lab.civicrm.org/dev/core/blob/master/CRM/Utils/Token.php)
```
Notice: Undefined index: contact in plugin...When adding Activities to Scheduled Reminders, I came across a couple of warnings coming from core/CRM/Utils/Token.php. (https://lab.civicrm.org/dev/core/blob/master/CRM/Utils/Token.php)
```
Notice: Undefined index: contact in plugins/civicrm/civicrm/CRM/Utils/Token.php on line 1457
Warning: array_diff(): Argument #1 is not an array in plugins/civicrm/civicrm/CRM/Utils/Token.php on line 1457
```
According to line 1376, $greetingTokens is not necessarily expected to be an array, but lines 1454 and 1457 do expect it to be an array. Line 1407 looks like it might create an array for $greetingTokens, if you get there. Wrapping if statements around 1454 and 1457 so they look like below does remove the warnings:
```
// Remove null contact fields from $greetingTokens
if (!empty($greetingTokens) && array_key_exists('contact', $greetingTokens)) {
$greetingTokens['contact'] = array_diff($greetingTokens['contact'], $nullFields);
}
// Also remove them from $tokenString
if (!empty($greetingTokens) && array_key_exists('contact', $greetingTokensOriginal)) {
$removedTokens = array_diff($greetingTokensOriginal['contact'], $greetingTokens['contact']);
}
```
However, I expect that's not the correct answer. It seems like $greetingTokens should be treated as an array throughout the file, and an "if" test should be done at the top, converting it to an array if the test is false. However, I'm afraid that's deeper than I can wade.
Originally found while also attempting to diagnose https://lab.civicrm.org/dev/core/issues/58https://lab.civicrm.org/dev/core/-/issues/348Custom Participant tokens not working in scheduled reminders2021-10-02T05:27:54Zmagnolia61Custom Participant tokens not working in scheduled remindersCustom Participant tokens do not work in scheduled reminders.<BR>
I believe the underlying code exists in CiviCRM but it is not possible to use participant tokens.
Work has been done to get these working in pdf creation though: https://...Custom Participant tokens do not work in scheduled reminders.<BR>
I believe the underlying code exists in CiviCRM but it is not possible to use participant tokens.
Work has been done to get these working in pdf creation though: https://issues.civicrm.org/jira/browse/CRM-16734
20200902 Coming back at this issue. I tested again and these are the results using CiviCRM 5.28.4<br>
Situation is an event registration and scheduled reminders being send based on that.
| Type of token | example | result |
| ------ | ------ | ------ |
| Only core event tokens | event.title | get correctly replaced |
| Custom event tokens | event.custom_123| Expected one Event but found 0 |
| Only core participant tokens | participant.role | No error, but do not get replaced |
| Custom participant tokens | participant.custom_123 | No error, but do not get replaced |5.43.0justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/360Can CIviCRM honor outbound proxies set site-wide for PHP applications?2022-08-24T05:03:36ZsudomanCan CIviCRM honor outbound proxies set site-wide for PHP applications?Is there a way to encourage CiviCRM to use an outbound proxy that is set system-wide for PHP applications? This is the format of our config in `/etc/php/set_proxy.php`:
```` php
<?php
$stream_default_opts = array(
'http'=>array(
'...Is there a way to encourage CiviCRM to use an outbound proxy that is set system-wide for PHP applications? This is the format of our config in `/etc/php/set_proxy.php`:
```` php
<?php
$stream_default_opts = array(
'http'=>array(
'proxy'=>"tcp://proxy.example.com:8118",
'request_fulluri' => true,
),
'https'=>array(
'proxy'=>"tcp://proxy.example.com:8118",
'request_fulluri' => true,
)
);
stream_context_set_default($stream_default_opts);
putenv('http_proxy=http://proxy.example.com:8118');
putenv('https_proxy=http://proxy.example.com:8118');
?>
````
However CiviCRM seems to ignore this setting at least some of the time: #324https://lab.civicrm.org/dev/core/-/issues/366Showing Line Items for Contributions with Default Price Sets2022-08-28T05:03:35ZCamilo RodríguezShowing Line Items for Contributions with Default Price Sets## Overview
In scenarios like data migration, multiple membership lines might be added to a contribution via the default priceset. The current mechanism prevents these lines from being shown when looking at a contributions detail view (C...## Overview
In scenarios like data migration, multiple membership lines might be added to a contribution via the default priceset. The current mechanism prevents these lines from being shown when looking at a contributions detail view (CRM_Contribute_Form_ContributionView). It makes sense that quick config priceset do not show up in the priceset configuration pages but there are more cons than pros to not show the lines on the actual contributions.
## How it Works Currently
To decide if line items should be shown for the contribution, line items are fetched, ordered by their price field's weight. Then, the price set for the first line item is checked. If the price set's `quick_config` flag is set, then the line items are NOT shown. If the falg is NOT set, the list of line items is shown.
## How it Should Work
List of line items should always be shown, especially if there is more than one of them, even if they're added using the default price set. Not sure what the logic is behind having the list of line items depend on the price set, but it could be better to have the contribution say if it should be shown with line items or not, by adding a new flag, `show_line_items` to the Contribution entity.guanhuanguanhuanhttps://lab.civicrm.org/dev/core/-/issues/371Be environmentally friendly. Remove the sentence: "Please print this page for...2019-10-13T19:27:08Zjustinfreeman (Agileware)Be environmentally friendly. Remove the sentence: "Please print this page for your records." from the various CiviCRM tpls. We like trees!Be environmentally friendly. Remove the sentence: "Please print this page for your records." from the various CiviCRM tpls. We like trees!
A quick grep found this text in the following locations. There may be other similar on other tpls...Be environmentally friendly. Remove the sentence: "Please print this page for your records." from the various CiviCRM tpls. We like trees!
A quick grep found this text in the following locations. There may be other similar on other tpls/translations too.
templates/CRM/Contribute/Form/Contribution/ThankYou.tpl:66: <div>{ts 1=$paymentProcessor.name}Your contribution has been submitted to %1 for processing. Please print this page for your records.{/ts}</div>
templates/CRM/Contribute/Form/Contribution/ThankYou.tpl:77: <div>{ts}Your transaction has been processed successfully. Please print this page for your records.{/ts}</div>
templates/CRM/Event/Form/Registration/ThankYou.tpl:74: <p>{ts 1=$paymentProcessor.name}Your registration payment has been submitted to %1 for processing. Please print this page for your records.{/ts}</p>
templates/CRM/Event/Form/Registration/ThankYou.tpl:79: <p>{ts}Your registration has been processed successfully. Please print this page for your records.{/ts}</p>
ext/iatspayments/templates/CRM/iATS/ContributeThankYouExtra_UKDD.tpl:23: <p>Please print this page for your records.</p>
Binary file l10n/de_DE/LC_MESSAGES/civicrm.mo matches
Binary file l10n/uk_UA/LC_MESSAGES/civicrm.mo matches
Binary file l10n/fr_FR/LC_MESSAGES/civicrm.mo matches
Binary file l10n/ca_ES/LC_MESSAGES/civicrm.mo matches
Binary file l10n/es_MX/LC_MESSAGES/civicrm.mo matches
Binary file l10n/et_EE/LC_MESSAGES/civicrm.mo matches
Binary file l10n/pl_PL/LC_MESSAGES/civicrm.mo matches
Binary file l10n/zh_TW/LC_MESSAGES/civicrm.mo matches
Binary file l10n/cs_CZ/LC_MESSAGES/civicrm.mo matches
Binary file l10n/es_ES/LC_MESSAGES/civicrm.mo matches
Binary file l10n/nl_NL/LC_MESSAGES/civicrm.mo matches
Binary file l10n/hu_HU/LC_MESSAGES/civicrm.mo matches
Binary file l10n/ja_JP/LC_MESSAGES/civicrm.mo matches
Binary file l10n/en_AU/LC_MESSAGES/civicrm.mo matches
Binary file l10n/sl_SI/LC_MESSAGES/civicrm.mo matches
Binary file l10n/ru_RU/LC_MESSAGES/civicrm.mo matches
Binary file l10n/da_DK/LC_MESSAGES/civicrm.mo matches
Binary file l10n/el_GR/LC_MESSAGES/civicrm.mo matches
Binary file l10n/ar_EG/LC_MESSAGES/civicrm.mo matches
Binary file l10n/en_CA/LC_MESSAGES/civicrm.mo matches
Binary file l10n/de_CH/LC_MESSAGES/civicrm.mo matches
Binary file l10n/tr_TR/LC_MESSAGES/civicrm.mo matches
Binary file l10n/sv_SE/LC_MESSAGES/civicrm.mo matches
Binary file l10n/fr_CA/LC_MESSAGES/civicrm.mo matches
Binary file l10n/pt_BR/LC_MESSAGES/civicrm.mo matches
Binary file l10n/pt_PT/LC_MESSAGES/civicrm.mo matches
Binary file l10n/en_GB/LC_MESSAGES/civicrm.mo matches
Binary file l10n/zh_CN/LC_MESSAGES/civicrm.mo matches
Binary file l10n/nb_NO/LC_MESSAGES/civicrm.mo matches
Binary file l10n/hi_IN/LC_MESSAGES/civicrm.mo matches
Binary file l10n/lv_LV/LC_MESSAGES/civicrm.mo matches
Binary file l10n/it_IT/LC_MESSAGES/civicrm.mo matches
Agileware Reference: SUP-6032https://lab.civicrm.org/dev/core/-/issues/392Support MySQL 8.0 now that it is GA2021-04-01T01:52:03ZJoeMurraySupport MySQL 8.0 now that it is GA# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (htt...# Overview
MySQL 8.0 went General Availability on April 19, 2018. CiviCRM's aim is to support the latest GA for required infrastructure (MySQL, PHP) as soon as feasible.
In reviewing removed features that cause incompatibilities (https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) I noticed a couple of issues that definitely require changes, one that might cause syntax errors that are easily fixed when found, and a fourth that we may want to change to improve our functionality and get current.
This is a meta issue for tracking what's needed for MySQL8. I have added a MySQL8 flag to lab for the moment to help in tracking. We can delete that flag after this issue is deemed complete.
# Related issue: Upgrade test infrastructure to enable testing against a version on the edge of being officially supported: https://lab.civicrm.org/dev/core/issues/1142
# Issue: Field Names now Reserved Words https://lab.civicrm.org/dev/core/issues/1143
# Testing issue: dependence on PHP version for MySQL authentication ~~https://lab.civicrm.org/dev/core/issues/1144~~
# Document dealing with changes to MySQL user password library https://lab.civicrm.org/dev/core/issues/1145
# Possible issue: Sort order on GROUP BY clauses
~~I don't think we have any code that tries to specify sort order on GROUP BY fields, but if so we will need to change to add an ORDER BY clause with the sort order. I think we should just try running tests on MySQL 8.0 and using it manually to determine locations in code with this issue, and play whack-a-mole on anything missed.~~
# Nice to have: Upgrade our text fields to support all utf8 characters https://lab.civicrm.org/dev/core/issues/339https://lab.civicrm.org/dev/core/-/issues/444Updated alterReportVars or new hook for reports2023-08-31T08:51:04ZJoeMurrayUpdated alterReportVars or new hook for reportsThere is no way to currently change a core report to get it to expose custom fields for a component if it does not do it already. It's not unusual an unusual use case to combine creating a custom field with exposing it in a core report....There is no way to currently change a core report to get it to expose custom fields for a component if it does not do it already. It's not unusual an unusual use case to combine creating a custom field with exposing it in a core report. What's needed is to be able to use a hook to add values to $_customGroupExtends. This would also allow extensions to define their own custom fields and add them to a report.
The alterReportVar hook is one place where this functionality could be added https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterReportVar/. The current three supported varTypes, columns, rows and sql, could be extended by a new one, customFields, or some similar name.
There has been criticism in the past of this hook. IIRC @eileen the concern was especially around how it was not well designed for the sql argument, but I don't recall the details. Perhaps it was that the hook was trying to do too many things and provided too broad a surface.
Rather than further complexifying this hook, an alternative approach would be to create a new one focussed exclusively on the issue of changing custom field exposed by a report. Perhaps it could be call alterReportCustomFields.
So we'd like feedback on
1. Should there be hook support for changing the custom fields exposed by reports?
2. If so, should we change alterReportVar or create a new hook, alterReportCustomFields?https://lab.civicrm.org/dev/core/-/issues/518Lybunt performance improvement2019-02-19T04:55:07ZeileenLybunt performance improvementA couple of years back I did some work on the performance of the Lybunt report https://issues.civicrm.org/jira/browse/CRM-17837 which succeeded in improving the query enough that it would run for prior years there is still an exponential...A couple of years back I did some work on the performance of the Lybunt report https://issues.civicrm.org/jira/browse/CRM-17837 which succeeded in improving the query enough that it would run for prior years there is still an exponential inefficiency in the query which means that 2 years later & some large number of donations later we are back to it not running.
The current query is
```
CREATE TEMPORARY TABLE civicrm_tmp_e_rptlybunt_20181114_5beb5dc8d8e46 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci
SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid FROM civicrm_tmp_e_rptgrp_20181114_5beb5dc8d1b4b group_temp_table INNER JOIN civicrm_contact contact_civireport
ON group_temp_table.id = contact_civireport.id INNER JOIN civicrm_contribution contribution_civireport ON contribution_civireport.contact_id = contact_civireport.id
AND contribution_civireport.is_test = 0
AND contribution_civireport.receive_date BETWEEN '20170101000000' AND '20171231235959'
LEFT JOIN civicrm_contribution cont_exclude ON cont_exclude.contact_id = contact_civireport.id
AND cont_exclude.receive_date BETWEEN '2018-01-01' AND '20181231235959' WHERE cont_exclude.id IS NULL AND 1 AND 1
GROUP BY contact_civireport.id;
```
and it takes 394 seconds
to return only a few hundred rows (the group has only 730 contacts).
Playing around I was able to reduce this time to .24 second by re-writing the query as
```
SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid
FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table INNER JOIN civicrm_contact contact_civireport
ON group_temp_table.id = contact_civireport.id
WHERE group_temp_table.id IN
(
SELECT group_temp_table.id FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table
INNER JOIN civicrm_contribution contribution_civireport ON contribution_civireport.contact_id = group_temp_table.id
AND contribution_civireport.is_test = 0
AND contribution_civireport.receive_date BETWEEN '20170101000000' AND '20171231235959'
)
AND group_temp_table.id IN
(
SELECT group_temp_table.id FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table LEFT JOIN
civicrm_contribution cont_exclude ON cont_exclude.contact_id = group_temp_table.id
AND cont_exclude.receive_date BETWEEN '2018-01-01' AND '20181231235959'
WHERE cont_exclude.id IS NULL
)
GROUP BY contact_civireport.id;
```
I experimented on our staging site on running the query on our WHOLE data base (ie. without the group constraint) and it completed in 720 seconds - which is outrageously good really since that legitimately queries a LOT of records.
I'm going to look at how to fix up the LYBUNT report to use the above query. There are already some tests from last time I worked on performance on this report.5.9https://lab.civicrm.org/dev/core/-/issues/537Owner notification email sending every time the contribution is resaved2020-12-04T10:43:06Zrita_compucorpOwner notification email sending every time the contribution is resavedWhen someone donates to a fundraising page, and then the site's staff member goes and edits the contribution that is related to the fundraising page, and saves the changes (even if there is no change just resaving the contribution) the f...When someone donates to a fundraising page, and then the site's staff member goes and edits the contribution that is related to the fundraising page, and saves the changes (even if there is no change just resaving the contribution) the fundraiser will receive the same email notification again.
Steps:
- create a contribution page and enable fundraising pages to be created under it
- make the payment processor to be Sagepay or Paypal standard
- create a fundraising page
- then log out and start donating to the fundraising page
- after donation the fundraiser will receive an email
- then go to the civi backend, search for the contribution that was just created after donation
- click Edit at that contribution
- no need to change anything on the contribution, just click Save
--> the same owner notification will be sent to the owner again. Every time you update the contribution the owner receives a notification with the same details.
Expected:
- online contribution: the notification should only be sent once, after the successful donation
- offline contribution: the notification should only be sent once, after creating the new contribution from civi backend
Tested on Civi 5.4 and 5.7, same happening on both.5.33.0https://lab.civicrm.org/dev/core/-/issues/538Activity search (advanced search) by subject - is exact match only2022-11-25T05:03:18ZRayWrightActivity search (advanced search) by subject - is exact match onlySearching activity subject (or details) from the advanced search form is set to an exact match (=). This seems less than ideal as most of the time you won't know the exact subject or details. While you can add the wildcard % characters t...Searching activity subject (or details) from the advanced search form is set to an exact match (=). This seems less than ideal as most of the time you won't know the exact subject or details. While you can add the wildcard % characters to search, the standalone activity search form operates as you'd expect using the LIKE term.
Can the advanced search (activities section) be made to match this behavior?
Here's a detailed breakdown verified on the demo site:
* Run an Advanced search for an activity that contains "Tell a Friend" in the subject line - no results.
* Run a standalone activity search (Search > Find Activities) for an activity that contains "Tell a Friend" in the subject line - returns all the activities that subject line contains the search term, including "Subject for Tell a Friend".
* Same problem when you search details or both.
Here is the on-screen feedback for the search results:
**Advanced Search**
```
No matches found for:
Activity targeted to ...AND...
Activity Text (Subject Only) = 'Tell a Friend' ...AND...
Activity Status In Completed
```
**Find Activies**
```
Activity targeted to ...AND...
Activity Text (Subject Only) Like '%Tell a Friend%' ...AND...
Activity Status In Completed
```https://lab.civicrm.org/dev/core/-/issues/549Migration of CiviCRM is terrible2018-11-28T12:07:46ZGhost UserMigration of CiviCRM is terribleI’m not sure how others migrate CiviCRM but the experience is a mess from a lack of quality documentation to the actual process. I was migrating a install and followed existing documentation and simply could not get the SQL to import via...I’m not sure how others migrate CiviCRM but the experience is a mess from a lack of quality documentation to the actual process. I was migrating a install and followed existing documentation and simply could not get the SQL to import via PHPMyAdmin it kept throwing errors and I consider myself to be expert level with managing databases. I even brought in a tech from my hosting provider and they escalated to a senior tech and couldn’t make it happen.
I’d highly encourage some work to improve documentation and also to look into improving the migration process. After hours of failed attempts I had to simply create reports for all data and do a clean install and manually do data entry which as you can imagine isn’t an ideal scenario. I’d suggest some sort of export and import function where data can be saved to a csv and imported that way if the sql issues which others seem to run into can’t be resolved.https://lab.civicrm.org/dev/core/-/issues/599Add Membership Renewal as Scheduled Reminder trigger option2022-09-24T05:03:38ZJoeMurrayAdd Membership Renewal as Scheduled Reminder trigger optionCurrently Scheduled Reminders can be based off membership join, start and end date. Renewal date is an important workflow event, and should be supported.
The existing three dates for membership are stored on the membership record. Renew...Currently Scheduled Reminders can be based off membership join, start and end date. Renewal date is an important workflow event, and should be supported.
The existing three dates for membership are stored on the membership record. Renewal date is not stored, and involves changing the end date.
civicrm_membership_log does not record what happened to prompt the new log record, ie a renewal.
A renewal can be (somewhat reliably) determined to have occurred at membership_log.modified_date when membership_log.end_date is increased by civicrm_membership_type.duration_unit * civicrm_membership_type.duration_interval compared to previous membership_log record for that membership. This can only be determined after the renewal has been processed.
Use a post-process validation to prevent configuration of a scheduled reminders based on a time BEFORE a renewal, only AFTER a renewal: "To schedule a reminder about an upcoming membership renewal, configure a message to be sent before the membership end date."
This algorithm will not work properly when the membership type duration and interval change between the time of the renewal and the sending of the reminder. As a work-around to avoid a schema change, when changes are made to the membership type duration or interval for a membership type that has a membership renewal triggered schedule reminder, display the following message: "Note: scheduled reminders for membership renewals of this membership type that have not been sent since the renewal will need to be done manually."EdselopezEdselopezhttps://lab.civicrm.org/dev/core/-/issues/605Display of Test Transactions in CiviCRM2023-09-06T05:03:20Zmattwiremjw@mjwconsult.co.ukDisplay of Test Transactions in CiviCRMSee https://github.com/civicrm/civicrm-core/pull/12421 and https://github.com/civicrm/civicrm-core/pull/12385
There is quite a lot of inconsistency with displaying test transactions in CiviCRM. In some places they are shown, others not...See https://github.com/civicrm/civicrm-core/pull/12421 and https://github.com/civicrm/civicrm-core/pull/12385
There is quite a lot of inconsistency with displaying test transactions in CiviCRM. In some places they are shown, others not, sometimes the tab counts include them, sometimes not...
I propose that we add a setting (global or per-user?) to CiviCRM and test transactions are shown ONLY based on that setting, not on any other random variable we choose to latch onto (who knew that force=1 also means "don't show test transactions"!).https://lab.civicrm.org/dev/core/-/issues/630CiviCase multi-category/ multi-instance support2022-10-29T05:03:41ZguanhuanCiviCase multi-category/ multi-instance supportRecently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. So...Recently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. Some of them require a change to evolve CiviCase’s data model to a multi-level structure.
To support this idea, I have attached a diagram to demonstrate the multi-level structure. We have suggested that a new field “case type category” would provide a lot of flexibility.
![CiviCase_Structure](/uploads/b73a3f3e8eb1d71034ac9121e1379f9c/CiviCase_Structure.jpg)
The basic idea is, an organisation’s business is made up of many different workflows for different business areas, such as Service delivery (i.e. a Helpdesk, Counselling service or Delivering care/housing support), Prospecting (i.e. major donors, grants bid writing in), Awards (i.e. Grants out), Volunteer vacancy management and even perhaps as a set of tasks for an event etc. These completely different workflows often are managed by completely different teams (who would need to manage their own case types), produce very different data and therefore require very different analysis and reports. "Case Type” is not sufficient to support all these needs as there may be several case types which apply to any specific business area.
Each team would probably want:
- The ability to create/configure case types of their category. For example with a volunteer vacancy managers they may want to create multiple vacancies, or with Grants, there may be multiple open opportunities. For Major donors they may split these between different types of donor - i.e. trusts, individuals, government which have different timelines and activities.
- The ability to add additional fields at the case type level for each category.
- Only having access to cases with the case type category they should have access to
- Some modifications to the case screen for cases of that case type category.
We've made a more detailed [draft proposal](https://compucorp.atlassian.net/wiki/spaces/PS/pages/1014398991/CiviCase+multi-category+support) of what we need to do to eliminate these caveats. The main target is to bring out the full potential of CiviCase as CiviCRM’s workflow management suite.https://lab.civicrm.org/dev/core/-/issues/633Specify the type of activity source entity2022-09-26T05:03:42ZguanhuanSpecify the type of activity source entity**Overview**
Activity table has a column source_record_id. It can refer to different entities depending on different activity type. For example, activity type "Event Registration" uses participant records as source records while activit...**Overview**
Activity table has a column source_record_id. It can refer to different entities depending on different activity type. For example, activity type "Event Registration" uses participant records as source records while activity type "Contribution" uses contribution records as source records.
The interpretation of what type of entity the source record is referring is subject to the logics for a selection of activity type defined in the code, in other words, it's hardcoded currently (please point out if this is no longer true).
**Proposed Solution**
This can be easily improved by adding a source_record_entity_table column to the activity table next to the source_record_id to indicate the entity.
This solution will not only help avoiding hardcoding source record entity but also provide flexibility to both:
- Recording source record: Any activity can refer to any entity that initiated/ is relevant to the activity. Same type of activity can even refer to different entities in different scenarios.
- Interpreting source record: Core and extensions can define the interpretation logics for different activity types and different source record entity. This can potentially be used to enable more tokens in activity based schedule reminders.https://lab.civicrm.org/dev/core/-/issues/666Prevent trailing ampersand in some URLs in WordPress2019-03-13T12:12:33ZhaystackPrevent trailing ampersand in some URLs in WordPressThere's a minor flaw in `CRM_Utils_System_WordPress::url()` which produces URLs with a trailing `&` when an empty array is passed to `CRM_Utils_System::url()` as the `$query` parameter. See, for example, the call to `CRM_Utils_System::ur...There's a minor flaw in `CRM_Utils_System_WordPress::url()` which produces URLs with a trailing `&` when an empty array is passed to `CRM_Utils_System::url()` as the `$query` parameter. See, for example, the call to `CRM_Utils_System::url()` in `CRM_Core_Payment::getNotifyUrl()`.
[The flaw](https://lab.civicrm.org/dev/core/blob/master/CRM/Utils/System/WordPress.php#L286-288) is that `$query` is set and is an empty string, which is appended to `$queryParts` and then results in a trailing `&` when the `$queryParts` array [is imploded](https://lab.civicrm.org/dev/core/blob/master/CRM/Utils/System/WordPress.php#L305).
My concern is that the URLs generated when an empty array is passed as the `$query` param are likely to be caught by `redirect_canonical()` with the possible loss of session data as a result of a WordPress-triggered redirect. (Or rather - since the example IPN URL is called externally - others like it in the CiviCRM ecosystem)
PR to follow.https://lab.civicrm.org/dev/core/-/issues/668Cases: Send email modal does not have case tokens2019-01-20T21:19:17ZshitijgCases: Send email modal does not have case tokensThe send email activity modal when accessing from inside the case does not have case tokens.
Print/Merge Document activity modal, if triggered from within the case, comes with case tokens such as caseid, case start date, case end date...The send email activity modal when accessing from inside the case does not have case tokens.
Print/Merge Document activity modal, if triggered from within the case, comes with case tokens such as caseid, case start date, case end date etc. However, these tokens, as described above, are not available in the send email modal
See screenshots
![Screen_Shot_2019-01-16_at_10.24.01](/uploads/5f8905a8d77c8a98dbe0daa3dc6f6df2/Screen_Shot_2019-01-16_at_10.24.01.png)
![Screen_Shot_2019-01-16_at_10.24.33](/uploads/28e2cc787916d4c29af252125803aa5d/Screen_Shot_2019-01-16_at_10.24.33.png)https://lab.civicrm.org/dev/core/-/issues/722Display attachments in Activities tab2022-10-01T05:03:35ZDon WijesooriyaDisplay attachments in Activities tabAttachments in case activities are displayed as paper-clip icon links on the case view screen.
![case_view](/uploads/d9e655c25b0d7b2001380d714720f7fe/case_view.png)
It would be better if attachments are displayed in the activities tab ...Attachments in case activities are displayed as paper-clip icon links on the case view screen.
![case_view](/uploads/d9e655c25b0d7b2001380d714720f7fe/case_view.png)
It would be better if attachments are displayed in the activities tab for all other activities as well.https://lab.civicrm.org/dev/core/-/issues/724For many countries other than USA, state is displayed as a number instead of ...2023-11-17T05:03:23ZIan KellingFor many countries other than USA, state is displayed as a number instead of a stringRepro:
Go to https://civicrm.demo.civihosting.com which is running 5.10.0 when
I tested this. Create a new contact, add an address in japan, choose a
state from the drop down box and click save. Then view the contact. In the state field,...Repro:
Go to https://civicrm.demo.civihosting.com which is running 5.10.0 when
I tested this. Create a new contact, add an address in japan, choose a
state from the drop down box and click save. Then view the contact. In the state field,
you will see a number instead of a state name. This seems to happen with
many countries.
We printed mailing labels that had numbers instead of the state names
and we don't know how many were or were not delivered. Please consider
this a high priority bug.https://lab.civicrm.org/dev/core/-/issues/732Parsing of addresses in the format of different countries2023-03-05T05:03:27ZjaapjansmaParsing of addresses in the format of different countriesCiviCRM has the ability to parse addresses into a street name, house number and street unit.
This parsing is based on I assume US address formats.
E.g. an address like _799 E DRAGRAM SUITE 5A_ is parsed into house number: 799, street n...CiviCRM has the ability to parse addresses into a street name, house number and street unit.
This parsing is based on I assume US address formats.
E.g. an address like _799 E DRAGRAM SUITE 5A_ is parsed into house number: 799, street name: E Dragram, and Street unit Suite 5a.
In the Netherlands and Belgium the adresses are formatted in a different way, first it is the street name, then the house number and then the street unit.
Some examples:
* _Grote straat 1a_, which should be parsed to Street name: Grote straat, house number 1, and street unit a
* _Grote straat 2-3_, which should be parsed to Street name: Grote straat, House number 2, and street unit 3
* _Plein 40-45 60-II_, which should be parsed to Street name: Plein 40-45, house number 60 and street unit II
**What I think CiviCRM should be capable of (either with an extension or in core):**
1. Parse addresses based on the country of the address
2. Format addresses based on the country of the address, meaning glue the individual address (Street name, house number, street unit) parts into one address
**How does it work currently?**
When I enable Address Parsing I can enther a full address into CiviCRM.
If I enter _Grote straat 1a_ it gets parsed into Address name: Grote straat 1a, House number: _empty_ and street unit _empty_
If I enter _Plein 40-45 60-II_ it gets parsed into Address name: Plein 40-45 60-II, House number: _empty_ and street unit _empty_
If I enter the individual parts, street name: Grote straat, house number: 1 and street unit a, it gets formatted to 1 Grote straat a
As you can see the formatting and parsing of Dutch and Belgium addresses does not work.
**Proposed solution**
I do think it will be good when the address parsing functionality could be made in such way that extensions could hook into it.
I am thinking of a hook which provides callback functions for address parsing based on the country ID of the address.
Example code
```php
$callbacks[1020] = array('CRM_Address_BAO_Address', 'parseBelgiumAddress');
$callbacks['default'] = array('CRM_Address_BAO_Address', 'parseAddress');
/**
* Alter the callbacks for address parsing
*
* @param array $callbacks
*/
hook_civicrm_alter_address_parser_callbacks(&$callbacks) {
// Add a custom address parser
// For example the dutch one:
$callbakcs[1152] = array('CRM_MyExtension_DutchAddressParser', 'parseDutchAddress');
}
```
This way CiviCRM core could provide a default address parser, and a set of address parser for certain countries and if one is missing an extension developer could write the missing parser.
What do you think of this? If everyone is happy I am happy to implement this.jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/773Proposal: Don't allow deleting custom fields that are used in a smart group2022-11-07T05:03:58ZJonGoldProposal: Don't allow deleting custom fields that are used in a smart groupI'm inspired by [this SE question](https://civicrm.stackexchange.com/questions/28713/how-to-troubleshoot-expected-one-customfield-but-found-0-error/28731). I can't think of a reason why we'd allow someone to delete a custom field used i...I'm inspired by [this SE question](https://civicrm.stackexchange.com/questions/28713/how-to-troubleshoot-expected-one-customfield-but-found-0-error/28731). I can't think of a reason why we'd allow someone to delete a custom field used in a smart group. The downside is we'd need to use an unindexed search on `civicrm_saved search` (e.g. `LIKE %"custom_1"%`) but I'm guessing that most folks don't have thousands of smart groups, and this would happen fairly infrequently.https://lab.civicrm.org/dev/core/-/issues/779Support token for participant id in scheduled reminder2021-10-12T02:22:06ZyashodhaSupport token for participant id in scheduled reminderCurrently, the participant id token is not available for scheduled reminder.
This is especially useful if the user need to be sent Self-service Registration Update forms
https://yoursite/civicrm/event/selfsvcupdate?reset=1&pid=xCurrently, the participant id token is not available for scheduled reminder.
This is especially useful if the user need to be sent Self-service Registration Update forms
https://yoursite/civicrm/event/selfsvcupdate?reset=1&pid=x5.43.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/781Contact Display Name vs Email Greeting in Workflow templates2019-10-23T20:22:53ZMichael LabriolaContact Display Name vs Email Greeting in Workflow templatesI noticed that some of the workflow templates use contact.display_name in the greeting and some of them use contact.email_greeting. It would make sense to me that they all use contact.email_greeting. From what I can tell these template...I noticed that some of the workflow templates use contact.display_name in the greeting and some of them use contact.email_greeting. It would make sense to me that they all use contact.email_greeting. From what I can tell these templates are part of civicrm_generated.mysql file, which is quite large. I created a fork and updated the several places where display_name is still being used. Is submitting a merge request something a general user can do here?
Thanks!5.20.0https://lab.civicrm.org/dev/core/-/issues/785Differentiate smart group from regular group using icon in select2 field2020-07-27T19:47:10ZMonish DebDifferentiate smart group from regular group using icon in select2 fieldCurrently there is no way to tell which group is smart or regular group from UI. It would be ideal to use icon against such smart group options to differentiate them from regular ones.Currently there is no way to tell which group is smart or regular group from UI. It would be ideal to use icon against such smart group options to differentiate them from regular ones.5.29.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/787Auto-complete search results not consistent with other searches2020-03-16T20:27:10ZyashodhaAuto-complete search results not consistent with other searchesAuto-complete (custom data on contacts) search results not consistent with other searches if the searched string has a space.
(check screenshot)![search](/uploads/8047fab578e9e63da65526701a88682d/search.png)
The quick search result is ri...Auto-complete (custom data on contacts) search results not consistent with other searches if the searched string has a space.
(check screenshot)![search](/uploads/8047fab578e9e63da65526701a88682d/search.png)
The quick search result is right and the auto-complete should also show 1 result only.5.25.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/794Expose address name in the invoice templates2022-10-09T05:03:32ZyashodhaExpose address name in the invoice templatesAllow *domain_address_name* to be used as address name in invoice template.Allow *domain_address_name* to be used as address name in invoice template.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/808support reCaptcha v32020-11-24T22:45:22ZJoeMurraysupport reCaptcha v3There's a new reCaptcha that does not show I am not a robot, but does require evaluation of a score returned. Would be good to support it before current v2 goes away (this is Google, days before Google+ is disappearing ;) ).
See https:/...There's a new reCaptcha that does not show I am not a robot, but does require evaluation of a score returned. Would be good to support it before current v2 goes away (this is Google, days before Google+ is disappearing ;) ).
See https://developers.google.com/recaptcha/docs/versionshttps://lab.civicrm.org/dev/core/-/issues/833(DX) Make backtraces for API exceptions useful2022-10-16T05:04:38Ztotten(DX) Make backtraces for API exceptions usefulThe current API architecture began with this calling convention for checking errors:
```php
$result = civicrm_api(...);
if ($result['is_error']) ...
```
It quickly became a common problem that callers forgot to check the result for suc...The current API architecture began with this calling convention for checking errors:
```php
$result = civicrm_api(...);
if ($result['is_error']) ...
```
It quickly became a common problem that callers forgot to check the result for success/failure, so a thin wrapper was introduced which generated an exception instead of returning an error-value:
```php
try {
$result = civicrm_api3(...);
}
catch (API_Exception $e) {...}
```
This generally surfaces errors better, but then the next step is: what caused the error? How do I get a backtrace?
The backtrace always points to the wrapper function. If you want the real backtrace, you need to switch back to `civicrm_api()`, set `debug=1`, and inspect the output for `trace` info.
I don't have a quick solution. Questions to elicit thoughts/planning:
* Can one generate a synthetic exception?
* If the initial problem is reported as an exception, and if the error is reported to the consumer as an exception, is there some way to pass that along?
* What are the implications for an existing consumer which uses `civicrm_api3()` and looks for `API_Exception`?
* What are the implications for an existing consumer which uses `civicrm_api()` and looks for a `trace`?
* How does this fit into the lifecycle of API kernel (e.g. of events/listeners using `civi.api.exception`)?https://lab.civicrm.org/dev/core/-/issues/846CQ: Refactor Recurring Contribution Forms2022-10-26T05:03:42Zmattwiremjw@mjwconsult.co.ukCQ: Refactor Recurring Contribution FormsThe contributionrecur forms have poor test coverage, are inconsistent with each other and do not have sensible parameters being passed to them (eg. recur_id). This is a meta issue to track improvements to these forms:
CRM/Contribute/For...The contributionrecur forms have poor test coverage, are inconsistent with each other and do not have sensible parameters being passed to them (eg. recur_id). This is a meta issue to track improvements to these forms:
CRM/Contribute/Form/CancelSubscription
CRM/Contribute/Form/UpdateBilling
CRM/Contribute/Form/UpdateSubscription
All 3 forms have been converted to inherit from the parent class `CRM/Contribute/Form/ContributionRecur` and common functionality will gradually be moved there.https://lab.civicrm.org/dev/core/-/issues/883Quick search should use FTS by default2023-01-26T05:03:54ZtottenQuick search should use FTS by defaultModern search systems have trained users to interactively tweak their search-text. For example, if I'm searching for a person named "Joeseph Smith", I might go through a series of searches (depending on the particular data-set, number of...Modern search systems have trained users to interactively tweak their search-text. For example, if I'm searching for a person named "Joeseph Smith", I might go through a series of searches (depending on the particular data-set, number of matches, and quality of the search):
1. "Joe"
2. "Joe Smi"
3. "Joe Smith"
4. "Joseph"
5. "Joseph Smith"
6. "Smith"
7. "Smith J"
8. "Smith, J"
Unfortunately, the default quick-search in Civi doesn't handle this well. Anecdotally, I feel like half of my searches (regardless of how much I tweak the search-text) don't produce the expected result -- even if I hit enter and drill-down to view a longer list of results.
A big part of this originates with a mix of compatibility/complexity concerns. CiviCRM stores contacts with MySQL InnoDB, and (during much of Civi's development) InnoDB's best filter option was `LIKE`... so that's what it uses. But `LIKE` is not very effective for matching names. Of course, MySQL has evolved -- first, MyISAM gained support for "full text search" (FTS); then, in v5.6, InnoDB also gained support for FTS. Civi has some options to use InnoDB FTS, but they're not enabled by default, and (IIRC) they're not integrated with the quick-search. There are third-party search systems (like Solr and ElasticSearch), but they're significant additional deployment/installation matter. Consequently, there is no *general* resolution to this problem (although some sites may have customizations in this space).
### Opinions
InnoDB doesn't have the best performance reputation - e.g. [(1)](https://hackernoon.com/dont-waste-your-time-with-mysql-full-text-search-61f644a54dfa) [(2)](https://www.percona.com/blog/2013/07/31/innodb-full-text-search-in-mysql-5-6-part-3/) - but it *is* the simplest option from an architectural POV. It can search the existing data-stores, and it's supported on any deployment with MySQL v5.6+. To make this architecture compatible with all deployments, all we really need is a slight bump in the system-requirements. Future-You will thank Current-You to please keep the architecture simple.
But the performance is a real consideration. So I'd vote to take an empirical decision-making approach:
1. Do credible benchmarking of some realistic searches using InnoDB FTS. That basically means -- setup a dev site, load a bazillion contacts, add some FTS indices, spy on the "Advanced Search" to grab some example SQL queries, and then manually tweak+execute to see if FTS-enabled variants perform alright. This can answer some key questions without requiring a lot of design discussion.
2. If InnoDB FTS performance is acceptable, then this is great. There's no need for a major new data-layer. We should simply re-engineer the default "Quick Search" to use InnoDB FTS (*with some LExIM provisos*), and we should bump the MySQL requirements (strictly v5.6+ or v5.7+).
3. If InnoDB FTS does not perform well, then solving the search-usability issue will require something else -- e.g. mapping into some other system (e.g. MyISAM FTS, Solr, Elastisearch). This is a more complicated path. I don't want to rule it out, but I'd vote to only look at it if the simpler/KISS architecture doesn't cut it.https://lab.civicrm.org/dev/core/-/issues/894Cannot change event selections to remove price field in price set when sold out2021-05-08T20:35:07ZlarsssandergreenCannot change event selections to remove price field in price set when sold outWhen using a price set for an event registration with a max participants limit for a specific price field, once that price field reaches the limit, it isn't possible to remove the contact from that price set field from the backend. It ju...When using a price set for an event registration with a max participants limit for a specific price field, once that price field reaches the limit, it isn't possible to remove the contact from that price set field from the backend. It just shows sold out and doesn't allow you to remove the contact. This works the same if it is a checkbox or numerical value, etc.
![Screen_Shot_2019-04-23_at_11.57.29_AM](/uploads/14d6428be73966900887d265edee82ef/Screen_Shot_2019-04-23_at_11.57.29_AM.png)
Presumably, this is to prevent contacts being added to sold out events, but it should be possible to **remove** them from sold out events. The price field should only be disabled if the contact isn't registered for it. It should be enabled if the contact is registered, so that it can be removed. This would be more complex in the case of numerical value fields, but this would at least fix the issue for checkboxes, radio selects, etc.
Tested on demo on Drupal (5.14.alpha1) and 5.7.4 on Drupal.https://lab.civicrm.org/dev/core/-/issues/2569afform - how to refresh display on submit2023-08-01T05:03:26Zeileenafform - how to refresh display on submitI'm not sure if this is a feature request of a documentation request but I seem close to having configuration & display working via afform & search kit for my custom entity 'Monolog' 'out of the box'.
eg git clone https://github.com/ei...I'm not sure if this is a feature request of a documentation request but I seem close to having configuration & display working via afform & search kit for my custom entity 'Monolog' 'out of the box'.
eg git clone https://github.com/eileenmcnaughton/monolog.git
enable & go to
civicrm/monolog
You can see I have a display of configured monologs below a form that allows you to add a new monolog. What I'd like is that the bottom display refreshes once the first is submitted
![image](/uploads/677229d37558e2fca0d18224378f3bc9/image.png)
@totten @colemanwhttps://lab.civicrm.org/dev/core/-/issues/2567Afform - how to edit not obvious2022-03-17T02:43:51ZeileenAfform - how to edit not obviousAfter several attempts I'm still completely mystified as to how to create a simple afform and open in edit mode for a contact. I have tried on demo.dmaster.civicrm.org creating a basic individual form but cannot figure out how to add an ...After several attempts I'm still completely mystified as to how to create a simple afform and open in edit mode for a contact. I have tried on demo.dmaster.civicrm.org creating a basic individual form but cannot figure out how to add an id to the url
The biggest part of this is there is no documentation.
However I suspect this should be addressed with notes / links in the UI as well
@colemanw @totten @MikeyMJCO @seamusleecolemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/905Better support in core for token payment processing2023-02-16T05:03:39ZeileenBetter support in core for token payment processingOver time token payments have become the preferred way of handling recurring payments. A while back we added the payment_token table for storage but we still have a situation where various processor extensions are solving the same proble...Over time token payments have become the preferred way of handling recurring payments. A while back we added the payment_token table for storage but we still have a situation where various processor extensions are solving the same problems separately (with varying degrees of maintainability). If we can converge on some improvements in core to better support this we can add tests in core & make the whole thing more reliable. Use of new methods would be recommended rather than required.
The focus here is on the regular scheduled job that finds recurring contributions that need to be charged, charges them and updates them in CiviCRM. I'm imagining we would add additional functions to the CRM_Core_Payment class that can be used and overridden by the various processors. We might visually separate them into a trait but I think it would be 'used' by CRM_Core_Payment.
The basic flow is
- getDuePayments
- preProcessDuePayments
- submitDuePaymentsToGateway
- updateSuccessfulPayments OR updateFailedPayments
Potentially status reporting - e.g emailing an administrator or logging to system log fits in at the end - I'm gonna leave that out of scope for now.
**Get Due Payments**
There are 2 types of payments here - those that are naturally due and those that are due to be retried due to previous failure. I think we should have 2 methods
- getDueScheduledPayments &
- getDueFailureRetryPayments
**Preprocess due payments**
Generally we create a pending contribution here (repeattransaction, status-pending)
We also attempt to 'lock' the recurring contribution so that it won't be retried the same day if the script fails or if there is a concurrent process. I'm imagining the functions to be
- createPendingTokenPayment
- lockRecurringContribution (more on this down below)
** Submit payments to gateway***
This generally uses 'doPayment'
** Update Successful Payments Update Failed Payment**
We call completetransaction for success & unlock the recurring contribution. Fails is the area we are trying to converge on
**Locking recurrings**
The main ways currently in use for 'locking recurrings' are to
- change the status on the recurring contribution
- add a pending contribution (& use the presence of that in a pending state as a blocker to further processing)
- push out the next_sched_contribution_date and failure_retry_date before starting so it won't be retried again before the schedule is due
After some thought I think we should do more with the status on the recurring contribution. My main reservation at the moment is that processors that use that method are overloading the 'Pending' status which actually means 'no payment yet received' - but I think that stems back to another design decision that I think was a mistake. Originally contribution, contribution_recur, pledge & pledge status were set up to share an option group. This causes a bunch of issues & hacky handling & as of now only contribution & contribution recur share statuses. I think we should separate them out into 2 option groups & then have some extra statuses that reflect the lock situation e.g
- 'Processing' - this would be our 'locked' status & nothing more would happen until that is resolved
- 'Failing' - this would mean one or more fails have happened but we haven't given up yet
This would mean that to be processed the next_sched_contribution_date needs to be now AND the status needs to not be 'Processing' OR the status needs to be 'Failing' and the failure_retry_date needs to be now.
Note that separating out the option group also addresses some other issues so I will likely do it in a 'numbers are all still the same' way sooner rather than later and we will be in a better position later.
**Unlocking recurring**
Success is easy - we just complete the transaction & push next_sched_contribution_date & null our failure_count & failure_retry_date
Failure is hard. The fails could be
- script does not complete. In this case the contribution is left in the 'Processing' status - in some cases people will manually intervene here and in some cases audit information from the processor will update the recurring. However, if, after a month it is still in Processing then it should be tried again. This feels like the case for pushing out next_sched_contribution_date BEFORE attempting payment
- payment fails with a temporary error related to the server (server says come back later)
- payment fails with a temporary error related to the user (card is overdrawn)
- payment fails with a permanent error (card is cancelled, stolen)
- payment fails with a permanent user error because they have cancelled the token at the gateway
Generally in a temporary error we will try again (using the failure_retry_date) and in a permanent error we will cancel the recurring contribution, in the case of the user-cancel it might make more sense for some sites to set it to completed....
**Next steps**
Overall I think if we start to get to some agreed additional functionality to support in core / add to the interface & keep tested that is a good thing. I feel like I need to ponder it for a bit & this will be an ongoing thing. But there are 2 things I think are worth doing now
1) add 4 new exception classes to core (all extending PaymentProcessorException)
- PermanentTokenPaymentException
- TemporaryServerTokenPaymentException
- TemporaryUserTokenPaymentException
- TokenCancelledByUserException
2) create a new contribution_recur_status_id option group - ensure the values exactly match the contribution option group & chip away at updating the various code places to use it (they should still work if using the old one as the numbers will be the same - this is how we managed it on pledges)
Initial discussion at https://github.com/iATSPayments/com.iatspayments.civicrm/pull/273
"Related" issues:
* https://lab.civicrm.org/dev/financial/issues/57
* https://lab.civicrm.org/dev/financial/issues/53
EDIT NOTE - 'Being processed' has been updated in this test to 'Processing' - since that was what was agreed. Comments below may be confusing without realising the text used to refer to Being Processedhttps://lab.civicrm.org/dev/core/-/issues/921Register token event not available2021-10-12T02:21:28ZjaapjansmaRegister token event not availableWith the `TokenProcessor` implementation one could register tokens with the `registerToken` event. See the docs: https://docs.civicrm.org/dev/en/latest/framework/token/#token-events-v47
However the `registerToken` event doesn't do anyth...With the `TokenProcessor` implementation one could register tokens with the `registerToken` event. See the docs: https://docs.civicrm.org/dev/en/latest/framework/token/#token-events-v47
However the `registerToken` event doesn't do anything. Also the class `CRM_Activity_Tokens` provide custom field tokens of activities for scheduled reminders. But those tokens don't show up in the token list when composing a scheduled reminder.
I would propose two things:
1. Make the `registerToken` event working
2. Make sure the activity tokens are visible in the list with tokens when composing a scheduled reminder. (This is possibly fixed when we fix 1.
Btw tested this in CiviCRM 5.8.0 and CiviCRM 5.12jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/2554hook_civicrm_tokenValues inconsistent data2021-09-20T20:18:36Zjaapjansmahook_civicrm_tokenValues inconsistent dataThe `hook_civicrm_tokenValues` has the following parameter signature:
* `&$values` an array containing the data to be replaced. The array has an index by contact id.
* `$contactIDs` an array of all contact ids
* `$jobID` id of the mai...The `hook_civicrm_tokenValues` has the following parameter signature:
* `&$values` an array containing the data to be replaced. The array has an index by contact id.
* `$contactIDs` an array of all contact ids
* `$jobID` id of the mailing job
* `$tokens` array of tokens to be replaced
* `$context` the calling class
However the `$values` and `$contactIds` have a inconsistent markup. The inconsistency is visible when one does a search on cases and then select **Print/Merge document** from the action list and creates a PDF.
At that point the `$values` also hold data for the contact with the same ID as the case ID.
And at that point the `$contactIds` is an array containing the following: `$contactIds[´contact_id´] = 1; $contactIds[´case_id´] = 2`
**Proposal / Expected behaviour**
* Only expect the affected contacts in `$values`
* The `$contactIds` should hold the contactIds and the case ID should be moved to $values.
I discovered this whilst writing https://docs.civicrm.org/dev/en/latest/step-by-step/create-custom-case-token/5.43.0https://lab.civicrm.org/dev/core/-/issues/2536Empty extension requires tag misevaluated2023-07-26T05:03:26ZeileenEmpty extension requires tag misevaluatedI'm seeing
![image](/uploads/9ca2d57e51026f71ccf522fc6a6d55cc/image.png)
In the UI it seems to be the carriage return in the tag causing the issue
![image](/uploads/19c9c8f5e5fb469af62f846a747b9180/image.png)
But contactlayoutedit xm...I'm seeing
![image](/uploads/9ca2d57e51026f71ccf522fc6a6d55cc/image.png)
In the UI it seems to be the carriage return in the tag causing the issue
![image](/uploads/19c9c8f5e5fb469af62f846a747b9180/image.png)
But contactlayoutedit xml is unchangedhttps://lab.civicrm.org/dev/core/-/issues/2533Afform - include Generic.html by default2021-04-25T21:00:40ZeileenAfform - include Generic.html by defaultI had a go at adding an afform in an extension today for a simple entity in the extension. I had to do 2 things to expose it
1) Add this file
https://github.com/eileenmcnaughton/deduper/commit/2ca0de29f66401584b966dcf42cd299b98af09a7
2...I had a go at adding an afform in an extension today for a simple entity in the extension. I had to do 2 things to expose it
1) Add this file
https://github.com/eileenmcnaughton/deduper/commit/2ca0de29f66401584b966dcf42cd299b98af09a7
2) hack a file similar to this one into core
https://github.com/civicrm/civicrm-core/compare/master...eileenmcnaughton:grantaff?expand=1#diff-e15ef3dc8f2633f790b8b2b34384aba83b9b5114e01a8f851e9e059273ae42d1
I think 2 could be addressed by fixing this line
https://github.com/civicrm/civicrm-core/blob/a191be25440e213fc29679584d2b62f5076369c2/ext/afform/admin/ang/afGuiEditor/afGuiEntity.html#L59 to include the specified file if exists else Generic.html
Note that simply downloading & enabling the master version of deduper if enough to get to the point where you can attempt to create the afform for ContactNamePair. It DOES work but the options section doesn't render
![image](/uploads/0a862ce216ac61045e9ef180d376abf6/image.png)
As a secondary issue, I couldn't figure out how to construct an edit url for ithttps://lab.civicrm.org/dev/core/-/issues/924Advanced search: activity tags should use select22019-06-05T15:24:08ZMonish DebAdvanced search: activity tags should use select2Steps to replicate:
1. add a tag and flag it as available to activities.
2. load advanced search and expand the activity panel.
Note that the activity field is the old format -- checkbox list. It should use select2. See the case panel ...Steps to replicate:
1. add a tag and flag it as available to activities.
2. load advanced search and expand the activity panel.
Note that the activity field is the old format -- checkbox list. It should use select2. See the case panel for comparison.5.12.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/927Cancel first contribution associated to membership, cancels the membership2021-04-09T18:47:41Zsluc23Cancel first contribution associated to membership, cancels the membershipFollowing this old topic:
https://civicrm.stackexchange.com/questions/2482/membership-sets-to-cancelled-when-contribution-fails-why
https://issues.civicrm.org/jira/browse/CRM-18177
current CiviCRM behavior is when a Contribution a...Following this old topic:
https://civicrm.stackexchange.com/questions/2482/membership-sets-to-cancelled-when-contribution-fails-why
https://issues.civicrm.org/jira/browse/CRM-18177
current CiviCRM behavior is when a Contribution associated with a membership is Cancelled, if this membership has only this Contribution, the membership is cancelled too.
Same when the Contribution gets to "Failed", if it's the first Contribution associated with the membership, it is set to "Expired" status.
https://github.com/civicrm/civicrm-core/blob/5.13/CRM/Contribute/BAO/Contribution.php#L1784
We use Membership for many Organizations with *manual/offline* payment processors, like direct debit, where the first Contribution can be Cancelled (i.e.: the member has no funds in his bank account) but this doesn't mean that the membership has to be cancelled too. The ORG will reattempt to charge this contribution later, and this same Contribution can be later Completed or a new one charged.
This ticket is meant to reopen the discussion about this topic with other users, and if it worth it, to rework on a solution where this behavior of cancelling memberships is not mandatory
Other areas of the code where similar things happen:
* https://github.com/civicrm/civicrm-core/blob/5.13/CRM/Contribute/BAO/ContributionRecur.php#L2985.35.0https://lab.civicrm.org/dev/core/-/issues/929Allow membership type to be configured in different currencies2022-10-30T05:03:28ZyashodhaAllow membership type to be configured in different currenciesCurrently, there is no way to configure membership type fee with different currencies. We would need to either have to configure the currency at membership level or allow the currency to be saved when recording the membership payment. Ch...Currently, there is no way to configure membership type fee with different currencies. We would need to either have to configure the currency at membership level or allow the currency to be saved when recording the membership payment. Check screenshots.
Thoughts?![mem_type](/uploads/8e9a32c89936251dc190e6b5bc1f8fab/mem_type.png)![membership](/uploads/2489c4353150f801142c7cd7170caafc/membership.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/930Performance issue with advanced search result count when searching on several...2022-11-21T05:03:26ZlolcodePerformance issue with advanced search result count when searching on several groups and one or more is a Smart groupIn advanced search we are searching for all users in any one of 3 groups. One of those groups is a fairly large smart group.
One of the slow queries observed and checked in the slow query log (over 60 seconds) is the one for getting the ...In advanced search we are searching for all users in any one of 3 groups. One of those groups is a fairly large smart group.
One of the slow queries observed and checked in the slow query log (over 60 seconds) is the one for getting the total number of results.
```
SELECT count(DISTINCT contact_a.id) as rowCount
FROM civicrm_contact contact_a
LEFT JOIN civicrm_group_contact civicrm_group_contact-2032325,930575
ON (contact_a.id = civicrm_group_contact-2032325,930575.contact_id AND civicrm_group_contact-2032325,930575.status IN ('Added'))
LEFT JOIN civicrm_group_contact_cache civicrm_group_contact_cache_2031143
ON contact_a.id = civicrm_group_contact_cache_2031143.contact_id
WHERE (
(
( civicrm_group_contact-2032325,930575.group_id IN ( 2032325,930575 ) )
OR
( civicrm_group_contact_cache_2031143.group_id IN ("2031143") )
)
)
AND (contact_a.is_deleted = 0);
```
MySQL EXPLAIN gives us a query_cost for this of 5505518.60
I came up with an alternate query at a much lower cost but I don't know enough about the Contact Query code to try it out and test it.
```
SELECT count(DISTINCT c.id) as rowCount
FROM civicrm_contact c
LEFT JOIN
(
select group_id, contact_id
from civicrm_group_contact_cache
WHERE group_id IN (2031143)
UNION
select group_id, contact_id
from civicrm_group_contact
WHERE group_id IN (2032325,930575) AND status IN ('Added')
) G
ON G.contact_id = c.id
WHERE
c.is_deleted = 0 and G.group_id IS NOT NULL
```
MySQL EXPLAIN gives us a query_cost for this one of only 102510.43
![Image_Pasted_at_2019-5-2_11-50](/uploads/b79c15b4b3c565259b4759a56ca6d14c/Image_Pasted_at_2019-5-2_11-50.png)
![Image_Pasted_at_2019-5-2_10-24](/uploads/fdf295fdb7435d156096e578544db0ee/Image_Pasted_at_2019-5-2_10-24.png)https://lab.civicrm.org/dev/core/-/issues/936CiviEvent - cannot register same participant multiple times from backoffice2022-11-04T05:03:28ZtapashCiviEvent - cannot register same participant multiple times from backofficeI have checked "**Same email address**" so that same person can book multiple times with an event that has multiple session and some might want to register other session at later time. From online registration it works, however it does n...I have checked "**Same email address**" so that same person can book multiple times with an event that has multiple session and some might want to register other session at later time. From online registration it works, however it does not work from backend and keep gives me error "**This contact has already been assigned to this event.**". How can I resolve this issue please? I am on civi 5.13.1, also tested on 5.11 . Thanks
EDIT: I was able to replicate this on https://dmaster.demo.civicrm.org
![Screenshot_2019-05-04_at_19.36.13](/uploads/5bff50eb46be8a3c23304b366eafc1f0/Screenshot_2019-05-04_at_19.36.13.png)https://lab.civicrm.org/dev/core/-/issues/947PCP honour roll hide amount2019-08-19T11:33:28ZMartinPCP honour roll hide amountA feature request - When filling out a PCP contribution page, the donor has the option to be shown on the honor roll or not (with some additional options). Could we add an extra option here to ask if the donor would like to hide the dona...A feature request - When filling out a PCP contribution page, the donor has the option to be shown on the honor roll or not (with some additional options). Could we add an extra option here to ask if the donor would like to hide the donation amount or not?
If this request is accepted I may be able to provide the code changes for it.kcristianokcristianohttps://lab.civicrm.org/dev/core/-/issues/952Make the "redirect back to event info page" a configurable link on the event ...2023-04-21T05:03:27ZJamie Novick - CompucoMake the "redirect back to event info page" a configurable link on the event configuration**Use case:**
In many situations organisations may wish to use CiviEvent with their CMS. In those situations often a CMS content page is presented to the public as the event information page rather then the default CiviCRM event informa...**Use case:**
In many situations organisations may wish to use CiviEvent with their CMS. In those situations often a CMS content page is presented to the public as the event information page rather then the default CiviCRM event information page (often as it is easier to style). Some links back to the event information page are hardcoded however and it would be preferable if they were configurable.
**How it works currently:**
Whenever you:
- Complete a registration
- If you return to an event that you have already registered for and chose not to register a further participant
you will be offered a link back to the CiviCRM event information page.
**How it should (could 😉) work:**
Add a configuration option on the Online registration tab of the event with label:
"Specify a different event information page"
Type: Checkbox
Help text: "CiviCRM by default will create an event information page with basic details of the event for any event which allows online registration. Users are presented with a link to this page when participants complete their registration, or if they have already registered for an event. If you wish to provide a different link to users then you can enter a different link here."
Label: External event information page link
Type: Text (single line)https://lab.civicrm.org/dev/core/-/issues/957Expose billing name for contribution reports2022-11-03T05:03:31ZyashodhaExpose billing name for contribution reportsIt would be helpful to have billing name exposed for contribution reports.It would be helpful to have billing name exposed for contribution reports.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/970Customised greetings not handled during merge2022-11-02T05:03:41ZJKingsnorthCustomised greetings not handled during mergeIt is possible to set customised email or postal 'greetings' in the system. However, when you choose to take across a customised greeting during a merge - the greeting itself is not migrated.
Steps to recreate:
- Create a contact record...It is possible to set customised email or postal 'greetings' in the system. However, when you choose to take across a customised greeting during a merge - the greeting itself is not migrated.
Steps to recreate:
- Create a contact record A, email address 'dupe@example.com'
- Edit record A, change the 'email greeting' to 'Customised' and the text to 'Why hi A!'
- Create a contact record B, email address 'dupe@example.com'
- Find duplicates on email address
- Go to merge the contacts, ensure that 'Email greeting ID 4' is being taken across:
![image](/uploads/6931d4c2c29057b95eb4490dea1a968a/image.png)
(note this is easier with patch https://github.com/civicrm/civicrm-core/pull/14260 applied!)
- Merge and view result
- Notice that the fact it is 'customised' has been retained, but the actual value has been lost:
![image](/uploads/be3c91513060ade5df0597c9342016a0/image.png)
This needs to be fixed for: email greeting, postal greeting and addressee fields. + tests written!
The fix would be:
- Ensure that the customised values are also displayed on the merge form
- Ensure that the 'customisations' are taken across when selected during a merge
- Ensure that customisations are removed appropriately if they are not longer customised as the result of a merge
- Handle cases where both contacts have different customised greetings
Thoughts:
The display could be like:
`Greeting ID: Customised: Hello A --[]--> Customised: Hello hello A!`
rather than having the customisation displayed in a separate row on the merge screenhttps://lab.civicrm.org/dev/core/-/issues/974.ics files should be whitelisted as file types for upload2019-08-15T14:00:20ZStoob.ics files should be whitelisted as file types for uploadCurrently an uploaded .ics file to Civi has the 'unknown' suffix appended. To offer some background, .ics file is a common format used by Google, Outlook and many other calendar software https://en.wikipedia.org/wiki/ICalendar. Indeed ...Currently an uploaded .ics file to Civi has the 'unknown' suffix appended. To offer some background, .ics file is a common format used by Google, Outlook and many other calendar software https://en.wikipedia.org/wiki/ICalendar. Indeed you will see this filetype attached to many email invitations you get for meetings.
I suggest that this filetype should be whitelisted by CiviCRM and uploaded without modification, for use in all places where attachments are allowed: CiviMail, custom data fields, etc. Since the filetype contains only data (similar to JSON or XML) there are no security issues I'm aware of, but I will rely on security experts to judge ultimately be the judge. Here's an example of part of the problem CiviCRM's appended suffix causes. The ".unknown" file cannot be recognized nor easily opened. @eileen @seamuslee
![ics](/uploads/f3f6c8c202dba00da35eda94eecdd974/ics.png)
![ics2](/uploads/3823eebea44838c339af41bb241e3d07/ics2.png)5.14.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/980Support latest phpunit versions2019-05-30T22:37:18ZeileenSupport latest phpunit versionsCurrently we extend a class in our unit tests that belongs with a pre-namespaced phpunit. There is a migration path summed up as
"If you want to update a simple project, where the only usage of PHPUnit classes is to create tests, you ar...Currently we extend a class in our unit tests that belongs with a pre-namespaced phpunit. There is a migration path summed up as
"If you want to update a simple project, where the only usage of PHPUnit classes is to create tests, you are very lucky. You need to require at minimum PHPUnit 4.8.35 or 5.4.3, which includes the FC class PHPUnit\Framework\TestCase as an alias for \PHPUnit_Framework_TestCase."
https://engineering.facile.it/blog/eng/phpunit-upgrade-namespace/
But from my digging I think we need to remove dbunit first (sebastianbergmann/dbunit#217) - which I've started doing5.15.0https://lab.civicrm.org/dev/core/-/issues/982Cleanup & api-ise the dedupe code2022-11-07T05:03:57ZeileenCleanup & api-ise the dedupe codeI've been looking at the dedupe code a lot. The problem is it was written to support a particular form & there is no layering. I think the right steps to clean it up involve adding some apis. I have been experimenting with a new angular ...I've been looking at the dedupe code a lot. The problem is it was written to support a particular form & there is no layering. I think the right steps to clean it up involve adding some apis. I have been experimenting with a new angular interface but we need to expose the logic via the api for it to be usable. Currently I'm looking at adding find apis - looking at creating a new api entity 'Dedupe' (I could use 'Rule' and add actions - on the fence there)
& looking at an action Dedupe.getmatcheshttps://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/core/-/issues/989Allow Permissioned contact to download the invoice2020-05-20T14:10:30ZeileenAllow Permissioned contact to download the invoiceOverview
To Print other contact Invoice Logged in contact need 'access CiviContribute' permission
To Print own Invoice Logged in contact need 'view my invoices' Permission.
If user role only have 'view my invoices' permission and want to...Overview
To Print other contact Invoice Logged in contact need 'access CiviContribute' permission
To Print own Invoice Logged in contact need 'view my invoices' Permission.
If user role only have 'view my invoices' permission and want to print invoice of contact which have Permissioned relationship. It gives access denied message.
(e.g. Employee should print invoice of Employer contact if relationship is Permissioned)
Before
it was not allowing download invoice for Permissioned relationship contact.
After
It allow to download invoice for Permissioned relationship contact.
NOTE I'm opening this to track https://github.com/civicrm/civicrm-core/pull/13320 so I can close it - it hasn't been approved in concept so it's stalled in the PR queue. Most of the work for a change like this is in the unit test & in the approval negotiation so the PR is probably about 20% of the overall work & it makes more sense to remove from review queue for nowhttps://lab.civicrm.org/dev/core/-/issues/998Exception.create (dedupe exception create) should purge rows from the prev ne...2019-11-24T06:28:02ZeileenException.create (dedupe exception create) should purge rows from the prev next table relating to the matchI'm pretty sure the current code fails to exclude dupes that have been flipped the opposite way from their exclusion (based on reading the code). I proposed we add a BAO_Exception object & the create action removes merge entries from pre...I'm pretty sure the current code fails to exclude dupes that have been flipped the opposite way from their exclusion (based on reading the code). I proposed we add a BAO_Exception object & the create action removes merge entries from prev-next cache (by calling a function on a Dedupe class, not by a direct query as I think it may not always be stored in that table)
@seamuslee FYIhttps://lab.civicrm.org/dev/core/-/issues/1008Ended or Finished contribution recur status?2022-11-10T05:04:00ZeileenEnded or Finished contribution recur status?I have hit a few times where people feel they want to end a recurring contribution with a status other than 'Completed', 'Failed' or 'Cancelled'
If someone has a recurring for 100 payments and they make 80 and then stop for one reason o...I have hit a few times where people feel they want to end a recurring contribution with a status other than 'Completed', 'Failed' or 'Cancelled'
If someone has a recurring for 100 payments and they make 80 and then stop for one reason or another they have not 'Completed' but it can feel unsatisfying to make the status 'Cancelled' when the organisation feels they honoured the spirit or their commitment. I think there are a a few variations of this scenario & I wonder whether adding
'Finished' or 'Ended' as a status makes sense - now we have separated recurring statuses from contribution statuses we have more flexibility here.
@justinfreeman @andrewhunt @JonGold @lcdweb @ehommel any thoughts?https://lab.civicrm.org/dev/core/-/issues/1009Provide a page for donors to manage their recurring contributions, view contr...2020-09-17T09:42:42Zjustinfreeman (Agileware)Provide a page for donors to manage their recurring contributions, view contribution history and update payment detailsThis is a concept being posted for discussion and feedback, prior to any development work.
We were asked last week how a contributor can manage their own recurring contributions in CiviCRM. I have never seen a page for these actions or ...This is a concept being posted for discussion and feedback, prior to any development work.
We were asked last week how a contributor can manage their own recurring contributions in CiviCRM. I have never seen a page for these actions or any other way to self-manage their donations. Is there such a feature in CiviCRM?
Assuming no such feature exists, It would be great to provide a page for donors to manage their recurring contributions, view contribution history and update payment details.
What other features should be available on this page? Interested in hearing other thoughts and opinions. And how others currently solve this problem.justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/1010incorrect capitalization in default Pledges - Acknowledgement message template2019-06-10T14:20:22Zphilmorbruincorrect capitalization in default Pledges - Acknowledgement message templateSELECT * FROM `civicrm_msg_template` WHERE `id` = 54
field: msg_html
Lines 24 and 25 as it is:
<p>{ts 1=$contact.display_name}dear %1{/ts},</p>
<p>{ts}thank you for your generous pledge. please print this acknowledgment for you...SELECT * FROM `civicrm_msg_template` WHERE `id` = 54
field: msg_html
Lines 24 and 25 as it is:
<p>{ts 1=$contact.display_name}dear %1{/ts},</p>
<p>{ts}thank you for your generous pledge. please print this acknowledgment for your records.{/ts}</p>
As it should be:
<p>{ts 1=$contact.display_name}Dear %1{/ts},</p>
<p>{ts}Thank you for your generous pledge. Please print this acknowledgment for your records.{/ts}</p>https://lab.civicrm.org/dev/core/-/issues/1013Possible php 7.1 modifications needed in civi core2020-01-30T02:00:36ZjitendraPossible php 7.1 modifications needed in civi coreUsed https://github.com/Alexia/php7mar to scan the master(5.15.alpha1) version of civi code.
The issues found by the checker are listed in the attached file.
[2018-12-22_15.32.20_all-civicrm.md](/uploads/fbaeff85306048256d4df9fa80c95ab...Used https://github.com/Alexia/php7mar to scan the master(5.15.alpha1) version of civi code.
The issues found by the checker are listed in the attached file.
[2018-12-22_15.32.20_all-civicrm.md](/uploads/fbaeff85306048256d4df9fa80c95abb/2018-12-22_15.32.20_all-civicrm.md)
Maybe, it would be better to update the code based on the same?https://lab.civicrm.org/dev/core/-/issues/1024New hook called before CRM_Mailing_BAO_TrackableURL::getTrackerURL()2019-12-19T15:52:56ZscardiniusNew hook called before CRM_Mailing_BAO_TrackableURL::getTrackerURL()I have a extension which adds utm params to links from mailing, these which are trackable later.
https://github.com/WeMoveEU/utmaltor
For this purpose I need new hook which will be called before CRM_Mailing_BAO_TrackableURL::getTracker...I have a extension which adds utm params to links from mailing, these which are trackable later.
https://github.com/WeMoveEU/utmaltor
For this purpose I need new hook which will be called before CRM_Mailing_BAO_TrackableURL::getTrackerURL()https://lab.civicrm.org/dev/core/-/issues/1031Queue for Core importers (for avoiding time outs)2022-08-22T22:22:06Zalejandro_salgadoQueue for Core importers (for avoiding time outs)Hi all, using CiviCRM importers for large datasets seems to be something that could be improved to avoid php timeouts or memory issues.
There are many questions and entries like [this one](https://civicrm.stackexchange.com/questions/219...Hi all, using CiviCRM importers for large datasets seems to be something that could be improved to avoid php timeouts or memory issues.
There are many questions and entries like [this one](https://civicrm.stackexchange.com/questions/21970/page-timeout-on-contact-import)
We used @eileen API csv Import GUI extension, which is very handy for specific imports or updates that the standard importers can't do, also it uses the Queue which is great.
Thinking a way for keep using the current importers without the timeout issues we came out with this approach, which is using the Queue for standard importers (contacts, activities, memberships, etc..)
Which should be the best approach? an extension? trying to add this to Core?
Thanks for the feedback!!5.51.0https://lab.civicrm.org/dev/core/-/issues/1032Make Find Events search more comprehensive2022-11-11T05:03:48ZyashodhaMake Find Events search more comprehensiveCurrently *Find Events* search will only let one search on the basis of event name/type or date.
There could be other criteria that could be relevant esp like search by event location which will make it possible to search for event venue...Currently *Find Events* search will only let one search on the basis of event name/type or date.
There could be other criteria that could be relevant esp like search by event location which will make it possible to search for event venues for a particular city without going into a specific event.https://lab.civicrm.org/dev/core/-/issues/1039Make the contact summary details popup on merge screen non bold a la contact ...2019-06-18T04:19:18ZseamusleeMake the contact summary details popup on merge screen non bold a la contact summary screenWhen on a contact merge screen there is now ability to mouse over and see the basic information popup like you see on search results or on a contact summary screen when you mouse over a person icon. The difference in the merge screen is ...When on a contact merge screen there is now ability to mouse over and see the basic information popup like you see on search results or on a contact summary screen when you mouse over a person icon. The difference in the merge screen is that it gets bolded content rather than normal text as it is in a header row of a table and the css is inheriting from the header row5.16.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1040Inconsistent validation of price field and option visibility combinations2022-11-12T05:03:50ZAndie HuntInconsistent validation of price field and option visibility combinationsSee https://github.com/civicrm/civicrm-core/pull/13966 for early discussion. Basically, CiviCRM occasionally attempts to prevent you from creating a price field with Admin visibility that only has options with Public visibility or vice-...See https://github.com/civicrm/civicrm-core/pull/13966 for early discussion. Basically, CiviCRM occasionally attempts to prevent you from creating a price field with Admin visibility that only has options with Public visibility or vice-versa. It is by no means consistent or effective in stopping this, however.
Some people [hold the opinion](https://github.com/civicrm/civicrm-core/pull/13966#issuecomment-480379731) that there should be no validation on this. At the very least, the validation should allow you to fix situations where there is no price option with visibility that matches its field's visibility (the situation that PR 13966 fixes).https://lab.civicrm.org/dev/core/-/issues/1041Refactor CiviCRM status checks so that checks are only performed when request...2020-09-17T09:42:52Zjustinfreeman (Agileware)Refactor CiviCRM status checks so that checks are only performed when requested and status alerts are only accessible to users with appropriate permissionsRefactor CiviCRM status checks so that:
1. checks are only performed when requested (and not on every CiviCRM page load)
2. where status alert information is available or shown
3. status alerts are only accessible to users with appropria...Refactor CiviCRM status checks so that:
1. checks are only performed when requested (and not on every CiviCRM page load)
2. where status alert information is available or shown
3. status alerts are only accessible to users with appropriate permissions
4. status check information is accessible via API supporting remote monitoring and alerts
Related PR for the new status check permission, https://github.com/civicrm/civicrm-core/pull/14521
On CiviCRM performance (1): if you run something in CiviCRM's menu it then invokes runItem to process and start the relevant functions to call the status check.
*List of status checks and suggested frequency*
TBCjustinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/1046Proposal to fix longstanding name vs label problems for case roles2020-02-10T15:53:18ZDaveDProposal to fix longstanding name vs label problems for case roles## Overview
At some point in time the xml case type definition started to use the label for the case role instead of the name. Currently you can't change the relationship type label in the UI without causing problems or in some cases a f...## Overview
At some point in time the xml case type definition started to use the label for the case role instead of the name. Currently you can't change the relationship type label in the UI without causing problems or in some cases a fatal error.
See
https://lab.civicrm.org/dev/core/issues/774
https://lab.civicrm.org/dev/core/issues/856
The first link also includes links to related instances over time.
## Proposal
Add a tag to the xml (e.g. `<name_for_real_this_time>` or `<lookupKey>` or `<optionValueName>` etc). When parsing the xml use this tag first, otherwise fall back to using `<name>` and compare it against label (same as current). This way it won't affect existing installs. For installs using database storage for case type definitions the upgrade script can add this tag to the xml. For sites using files people can add it as needed (possibly the upgrade script can suggest).
Ping @colemanw @eileen @jitendra @andrewhunt @totten
Also pinging @bgm since this issue causes language problems too.5.20.0https://lab.civicrm.org/dev/core/-/issues/1062Change the CiviCRM v3 / v4 API to only return active contacts by default. Cur...2019-11-27T21:55:34Zjustinfreeman (Agileware)Change the CiviCRM v3 / v4 API to only return active contacts by default. Currently will include deleted contactsThis is a straight forward request to simply change the CiviCRM v3 / v4 API to only return **active contacts by default**. Currently API calls will include deleted contacts in the results.
This is counter-intuitive and a constant source...This is a straight forward request to simply change the CiviCRM v3 / v4 API to only return **active contacts by default**. Currently API calls will include deleted contacts in the results.
This is counter-intuitive and a constant source of bugs when testing new code. It is not always immediately obvious that deleted contacts are included in the result set, especially if you are testing on a CiviCRM site with no deleted contacts. Then when you move the code to production, BAM! What are all these other contacts in here? That's a big fail (and many sad faces).
The only reason I know of for deleted contacts to be included by default currently was quite eloquently described by @seamuslee in [chat](https://chat.civicrm.org/civicrm/pl/ux97e5idefnxzq8h99zuo5t6jh): "*because we want to keep you on your toes* @agileware_justin"
If you want to return deleted contacts in an API call, then this should be explicit via a parameter. eg. return deleted contacts = true.
Agileware Ref: CIVICRM-1241https://lab.civicrm.org/dev/core/-/issues/1064Allow personalised 'view in browser' links for mass emails2021-09-13T08:10:09ZJKingsnorthAllow personalised 'view in browser' links for mass emailsProblem summary:
As a user, I want to view an email in my browser, but when I do the tokens are not populated.
Detail:
The {mailing.viewUrl} token can be used to generate a link to the 'public' view of an email. If a user is logged in t...Problem summary:
As a user, I want to view an email in my browser, but when I do the tokens are not populated.
Detail:
The {mailing.viewUrl} token can be used to generate a link to the 'public' view of an email. If a user is logged in to the website, then the tokens in the email are replaced correctly. However, it would be cool if the public view of the email also supported checksums, so that we can include a link to the personalised web-version of the email.
This involves:
* Supporting checksums when rendering the email in \CRM_Mailing_Page_View::run
* Adding a new token to extract the 'mailing key' (ID or hash) from the mailing
* Updating the documentation to describe the URL format to use for this
The proposed format is:
https://example.com/civicrm/mailing/view?reset=1&id={mailing.key}&cid={contact.contact_id}&{contact.checksum}
This is because we can't easily 'inject' contact-related tokens into the existing {mailing.viewUrl}. This format also matches the existing patterns as described in https://docs.civicrm.org/user/en/latest/common-workflows/tokens-and-mail-merge/
(It would be super-awesome if we could make these tokens more user-friendly, like {checksum.event.123} or something. But that is out-of-scope for this issue!)
I'm about to throw up a PR with the proposed code changes.https://lab.civicrm.org/dev/core/-/issues/1069Error thrown while sending email using the preferred from address2019-07-31T10:23:15ZyashodhaError thrown while sending email using the preferred from addressGo to Settings - Outbound Mail
Check Allow Mail to be sent from logged in contact's email address
Error is thrown while sending email using the preferred from address (logged in user's email address)
![from_error](/uploads/af9340f4d2f...Go to Settings - Outbound Mail
Check Allow Mail to be sent from logged in contact's email address
Error is thrown while sending email using the preferred from address (logged in user's email address)
![from_error](/uploads/af9340f4d2fd80fc572d43ac9a78d609/from_error.png)
This behavior replicated *only* for preferred from address.
![preferred_from](/uploads/3357529a787d528568898a372f6e9d0a/preferred_from.png)
yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1071CiviCRM Mailing does not set the Reply-To header to use VERP (CiviCRM return ...2020-09-17T09:47:54Zjustinfreeman (Agileware)CiviCRM Mailing does not set the Reply-To header to use VERP (CiviCRM return address) when Flexmailer is installed and using default optionCiviCRM Mailing does not set the Reply-To header to use VERP (CiviCRM return address) when Flexmailer is enabled and **Traditional Mailing Handler** using the *default* option of **Automatic** or **CiviMail BAO** or on page /civicrm/admi...CiviCRM Mailing does not set the Reply-To header to use VERP (CiviCRM return address) when Flexmailer is enabled and **Traditional Mailing Handler** using the *default* option of **Automatic** or **CiviMail BAO** or on page /civicrm/admin/flexmailer?reset=1
If the **Traditional Mailing Handler** option is set to **Flexmailer Pipeline** then the Reply-To header is set correctly.
This is problematic because all email replies are sent to the reply-to email address which is often a **user mailbox** and not processed by CiviCRM at all. The user receives all the bounced emails and out of office replies.
Because this problem occurs with the default options, there is a high likelihood that this problem will impact on a CiviCRM site.
Environment:
* CiviCRM 5.14.1
* Flexmailer extension 1.1.0
* Track replies using VERP in Reply-To header option is enabled
* Enable Custom Reply-To option is disabled
Agileware Ref: CIVICRM-1254https://lab.civicrm.org/dev/core/-/issues/1072Combine the CiviMail Settings and the CiviMail Components Settings which are ...2020-09-17T09:48:45Zjustinfreeman (Agileware)Combine the CiviMail Settings and the CiviMail Components Settings which are currently on two different pages to be on the same pageCombine the CiviMail Settings and the CiviMail Components Settings which are currently on two different pages to be on the same page.
The reasoning is that these settings are all related to CiviMail and should be shown on the same page....Combine the CiviMail Settings and the CiviMail Components Settings which are currently on two different pages to be on the same page.
The reasoning is that these settings are all related to CiviMail and should be shown on the same page.
Particularly confusing when the VERP configuration is on BOTH pages.
**Settings - CiviMail**
* Enable Custom Reply-To
* VERP Separator
**CiviMail Component Settings**
* Track replies using VERP in Reply-To header
![Settings_-_CiviMail](/uploads/735ca3a60a22986c58a2f9bfe1a21946/Settings_-_CiviMail.png)
![CiviMail_Component_Settings](/uploads/a6ef9a8e20d71b46744d511d97d85590/CiviMail_Component_Settings.png)
Agileware Ref: CIVICRM-1255https://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/1077Make report listing actions links hookable2020-08-12T14:56:34ZyashodhaMake report listing actions links hookableMake report listing actions hookable. All the other action links in CRM are exposed to links hook.
![report_action](/uploads/0163d968e46b47ae3fbe41bdf96e7875/report_action.png)Make report listing actions hookable. All the other action links in CRM are exposed to links hook.
![report_action](/uploads/0163d968e46b47ae3fbe41bdf96e7875/report_action.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1080Option for encrypting sensitive data2022-11-15T05:03:39ZherbdoolOption for encrypting sensitive dataHas anyone developed a way to encrypt sensitive data in CiviCRM? Only certain user roles would be able to decrypt it. Inspired by https://www.drupal.org/project/encrypt Is anyone interested in this? I could imagine a lot of non-profits w...Has anyone developed a way to encrypt sensitive data in CiviCRM? Only certain user roles would be able to decrypt it. Inspired by https://www.drupal.org/project/encrypt Is anyone interested in this? I could imagine a lot of non-profits wanting to encrypt sensitive data like drivers licenses, birth certificates, birthdays, etc.
I'm guessing putting this issue in the Core project isn't the best place but it's not clear where else it could go. Maybe we need an extensions ideas project?https://lab.civicrm.org/dev/core/-/issues/1087Inappropriately small edit box for large text fields when editing inline2022-11-16T05:03:58ZandrewcormickdockeryInappropriately small edit box for large text fields when editing inlineWhen editing text fields via the inline editor, an inappropriately small box appears even for fields which require a large amount of text.
For example, consider the custom fields as created according to the first image attached. When e...When editing text fields via the inline editor, an inappropriately small box appears even for fields which require a large amount of text.
For example, consider the custom fields as created according to the first image attached. When editing, only a small amount of the long text field can be observed at once (see second image).
This has caused usability issues for our user base.
![First image - when viewing custom fields](/uploads/00a8cb8067bb1f295f466b0768d5e3cd/image.png)
![Second image - trying to edit a large text field](/uploads/2dad994174335728b2caba425bec80da/image.png)https://lab.civicrm.org/dev/core/-/issues/1093Add support for bulkcreates2023-01-04T05:03:23ZeileenAdd support for bulkcreatesAfter discussing with @colemanw on chat - there is a demand in some cases to create an entity in a way that performs well on multiple creates at one. GroupContact or MailingQueue are both examples. The current example is creating bulk cu...After discussing with @colemanw on chat - there is a demand in some cases to create an entity in a way that performs well on multiple creates at one. GroupContact or MailingQueue are both examples. The current example is creating bulk custom fields - the actual row saves are fine here but if adding more than one field to an-already-large custom table then multiple column adds is slow whereas one sql action adding multiple indexes & columns (& one for log tables) is much better.
We talked about laying the ground work for this being a supported apiv4 action with the goal being that apiv4 would expose an action for any entities that have a bulkCreate action.
At this stage my scope is limited to cleaning up the CustomField.create function and adding a bulkCreate function that is tested & suitable to be exposed via apiv4 (but I'm not taking that next step at this stage so the contract can still change). Currently 2 BAO have bulkCreate functions. They relate to mailings and are suitable for bulk create although require some tweaks (passing keyed params rather than 0, 1 etc)https://lab.civicrm.org/dev/core/-/issues/1100Proposal to add a new hook_civicrm_alterExternUrl2020-05-30T01:02:26ZAndrei Mondocandreimondoc@gmail.comProposal to add a new hook_civicrm_alterExternUrlThere's been talks about deprecating all `extern` scripts in favour of CMS REST endpoints or use [CiviCRM's routing](https://lab.civicrm.org/dev/cloud-native/issues/16), and along the way helping other issues like CMS bootstrapping, base...There's been talks about deprecating all `extern` scripts in favour of CMS REST endpoints or use [CiviCRM's routing](https://lab.civicrm.org/dev/cloud-native/issues/16), and along the way helping other issues like CMS bootstrapping, base paths, and session management.
[Drupal 8](https://www.drupal.org/docs/8/api/restful-web-services-api) and [WordPress](https://developer.wordpress.org/rest-api/) offer the possibility of extending their REST endpoints, and it seems Joomla does so too although unofficially? ([REST API for Joomla!](https://extensions.joomla.org/extension/rest-api/) and [cAPI Core REST API for Joomla!](https://extensions.joomla.org/extension/capi-core-rest-api/))
This seems to me like a sensible way forward, hence my proposal to add a `hook_civicrm_alterExternUrl` something along the lines of:
``` php
// Create an event object.
$event = GenericHookEvent::create(array(
'type' => 'cxn', // replacing with ipn|extern|soap|pxIPN|etc.
'civiURL' => &$civiUrl,
'url' => rtrim($civiUrl, '/') . '/extern/cxn.php',
);
/**
* Allow filtering of extern URL.
*
* @since ...
*
* @param string $hook_name The dispatched hook name.
* @param object $hook_event The dispatched hook event object.
*/
Civi::service('dispatcher')->dispatch('hook_alterExternUrl', $event);
return $event->url;
```
I have completed the [REST endpoints integration for WordPress](https://github.com/civicrm/civicrm-wordpress/pull/160) and I remember someone (in Mattermost) mentioning they were/are doing the same for Drupal 8. In order to start testing and integrating those endpoints this hook would a good transition.
Any feedback is appreciated, thanks.5.23.0https://lab.civicrm.org/dev/core/-/issues/1101Feature request - Add a Public Group Title and Public Group Description field...2020-09-17T09:48:49Zjustinfreeman (Agileware)Feature request - Add a Public Group Title and Public Group Description fields to CiviCRM Group and display these fields on the public pages for subscribe, unsubscribe etc.Feature request - Add a Public Group Title and Public Group Description fields to CiviCRM Group and display these fields on the public pages for subscribe, unsubscribe etc.
Currently, Group Title and Group Description have dual uses:
1....Feature request - Add a Public Group Title and Public Group Description fields to CiviCRM Group and display these fields on the public pages for subscribe, unsubscribe etc.
Currently, Group Title and Group Description have dual uses:
1. Displayed in the CiviCRM back-end and used for internal reference only, AND
2. Displayed publicly on the Internet on public pages
The problem is that the internal title and description for a group is often not appropriate as a public title and description, often revealing targetting / collation information as to how the group is populated which can be potentially embarrassing or harmful to the organisation if revealed publicly.
This proposal is similar to the feature which has been added to Profiles to have an Profile Title (internal display only) and Public Profile Title (displayed on public pages).
Agileware Ref: CIVICRM-1269