Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-03-21T19:38:53Zhttps://lab.civicrm.org/dev/core/-/issues/1640Update pending contribution status action also send email without warning2020-03-21T19:38:53ZjaapjansmaUpdate pending contribution status action also send email without warningWhen you search for contributions with status pending. You have an action to batch update all contribution statuses to completed. See screenshots
![Screenshot_from_2020-03-10_22-38-02](/uploads/e533c6e42f3ed4d1545f3855d3dd81b8/Screensho...When you search for contributions with status pending. You have an action to batch update all contribution statuses to completed. See screenshots
![Screenshot_from_2020-03-10_22-38-02](/uploads/e533c6e42f3ed4d1545f3855d3dd81b8/Screenshot_from_2020-03-10_22-38-02.png)
![Screenshot_from_2020-03-10_22-39-20](/uploads/d57cd774f224eb3ec62c73dc446628e7/Screenshot_from_2020-03-10_22-39-20.png)
When you do this the system also sends an email receipt to the donor.
**There is no warning about this e-mail.**
Possible solutions:
1. Checkbox for sending e-mails or not (this will give the user control)
2. A warning text indicating that this action also sends an e-mai.
I will see if I can work on option 1.jaapjansmajaapjansmahttps://lab.civicrm.org/dev/translation/-/issues/39Installing CiviCRM in another language, with civicrm-setup2020-05-26T00:28:31ZbgmInstalling CiviCRM in another language, with civicrm-setupI have perhaps a bit of a less-common setup, with Aegir, and running into the following situation when installing CiviCRM on Drupal8 with the 'new' civicrm-setup installer:
At first, the installer failed because of:
```
Error: Call to ...I have perhaps a bit of a less-common setup, with Aegir, and running into the following situation when installing CiviCRM on Drupal8 with the 'new' civicrm-setup installer:
At first, the installer failed because of:
```
Error: Call to a member function getPath() on null in CRM_Core_I18n::getResourceDir()
(line 301 of [...]/vendor/civicrm/civicrm-core/CRM/Core/I18n.php
```
So I patched with the following in `civicrm-setup/plugins/installDatabase/InstallSchema.civi-setup.php`:
```
elseif ($seedLanguage) {
global $tsLocale;
$tsLocale = $seedLanguage;
// Added this:
require_once $model->settingsPath;
\Civi\Core\Container::boot(FALSE);
```
but now I'm getting:
```
Exception: No domain in DB
```
since `Civi/Core/Paths.php` initializes CRM_Core_Config::singleton(), which checks for a domain.
trace:
```
civicrm-core/CRM/Core/Config.php line 115
civicrm-core/Civi/Core/Paths.php line 36
civicrm-core/Civi/Core/Paths.php line 145
civicrm-core/Civi/Core/Paths.php line 189
civicrm-core/Civi/Core/Paths.php line 84
civicrm-core/Civi/Core/Paths.php line 145
civicrm-core/Civi/Core/Paths.php line 189
civicrm-core/CRM/Core/I18n.php line 301
```
i.e. it ends up running:
```
->register('civicrm.root', function () {
return \CRM_Core_Config::singleton()->userSystem->getCiviSourceStorage();
})
```
which brings me to a bit of a catch-22, because `civicrm_domain` gets populated by `sql/civicrm_data.fr_CA.mysql`.
I feel like this is a regression caused by the new-ish `[civicrm.l10n]` variable.
If I patch `CRM/Core/I18n.php` to return a hardcoded l10n resourceDir, the installer runs fine.5.27.0https://lab.civicrm.org/dev/core/-/issues/1630Membership auto-renew is not optional if using price set2023-11-09T05:03:26ZAllenShawMembership auto-renew is not optional if using price setThe "optional auto-renew" setting for a membership type is not honored on the contribution page if using a price set.
**Repro steps:**
1. Configure a membership type with "auto-renew option" = "Give option, but not required", e.g., "Ge...The "optional auto-renew" setting for a membership type is not honored on the contribution page if using a price set.
**Repro steps:**
1. Configure a membership type with "auto-renew option" = "Give option, but not required", e.g., "General type A"
1. Create a membership price set with a "membership type" field (radio) including at least the "General type A" membership type.
1. Create a contribution page using this price set;
1. Just in case, ensure the contribution page uses a payment processor that supports recurring contributions (not sure if this step is necessary for repro, but it would be in the real world)
1. Open the contribution page in "live" mode
1. Below the "Membership type" price field, observe the message "Membership will renew automatically."; also observe there is no checkbox labeled "Please renew my membership automatically." (which would be expected for optional auto-renewal).
**Bonus repro:**
1. Edit the configuration for "General type A" membership type, so that "auto-renew option" = "No auto-renew option".
1. Reload the contribution page and observe that auto-renew is not required.
**Bonus repro 2:**
1. Create another contribution page, this time offering the "General type A" membership type without using a price set (i.e., in the "quick config" membership type options under the Membership tab), and set the "Auto-renew" option to "Give option" for this membership type.
1. Open this contribution page in "Live" mode and observe that the checkbox labeled "Please renew my membership automatically." appears as expected.
**Other notes:**
1. Just to be sure I'm not imagining things, this did used to work; here are a couple of sources indicating I should be able to use a membership price set and still have the membership types "auto-renew is optional" setting be honored on the contribution page:
- https://civicrm.stackexchange.com/questions/10048/auto-renew-option-not-appearing-for-membership
- https://issues.civicrm.org/jira/browse/CRM-17197
1. Using the browser developer's console to edit on-page html I can make the hidden/forced checkbox visible and uncheck it; when the form is submitted in this state, the membership is created without auto-renewal; this indicates the issue is primarily with the creation of the page (e.g., hiding via JavaScript, etc.), and that form validation still allows optional renewal.https://lab.civicrm.org/dev/core/-/issues/1626Unexpected import behaviour when set the setting to view only for custom fields.2022-08-10T04:48:13Zkartik1000Unexpected import behaviour when set the setting to view only for custom fields.While creating the custom field there is a option <br> <strong> View Only? Is this field set by PHP code (via a custom hook). This field will not be updated by CiviCRM. </strong> <br>
Even after selecting this option when we import a 'cs...While creating the custom field there is a option <br> <strong> View Only? Is this field set by PHP code (via a custom hook). This field will not be updated by CiviCRM. </strong> <br>
Even after selecting this option when we import a 'csv' containing one of the custom fields as its column, the value of the custom field is changed from the default value to the value mentioned in the 'csv'. Even when the custom field is not present in the csv, civicrm still assigns the field as empty but not the default value. This was replicated on various versions from 4.7 to 5.22.1. The error was also reported on https://civicrm.stackexchange.com/questions/34903/expected-import-behavior-when-setting-custom-field-to-view-only .
<h2>Expected Behaviour</h2>
CiviCRM should not change the default value of the custom field since it is only a view only field and should retain the default for every case.https://lab.civicrm.org/dev/core/-/issues/1621cascade delete of civicrm_financial_type to civicrm_entity_financial_account2023-02-20T05:04:09ZJoeMurraycascade delete of civicrm_financial_type to civicrm_entity_financial_account1. Background
The civicrm_entity_financial_account table stores, amongst other things, the relationships between civicrm_financial_type and civicrm_financial_account records.
2. Current situation
When financial types are deleted, the...1. Background
The civicrm_entity_financial_account table stores, amongst other things, the relationships between civicrm_financial_type and civicrm_financial_account records.
2. Current situation
When financial types are deleted, there are stranded records in civicrm_entity_financial_account with no referent for their financial_type_id.
3. Proposed change
When a financial type with id=n is going to be deleted, first
```sql
DELETE FROM civicrm_entity_financial_account WHERE financial_type_id=n;
```
On upgrade, run something like
```sql
DELETE efa.* FROM civicrm_entity_financial_account efa LEFT JOIN civicrm_financial_type ft ON efa.financial_type_id=ft.id WHERE ft.id IS NULL;
```seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1620Extend content array of hook_civicrm_alterMailContent2023-03-18T05:03:32ZscardiniusExtend content array of hook_civicrm_alterMailContentOverview
----------------------------------------
Extend `$content` array of alterMailContent hook
Example use-case
----------------------------------------
More fields improve possibilities durign processing the hook.
Current behavio...Overview
----------------------------------------
Extend `$content` array of alterMailContent hook
Example use-case
----------------------------------------
More fields improve possibilities durign processing the hook.
Current behaviour
----------------------------------------
According to doc https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterMailContent/ the `$content` array should have mailing_id field/index. However during sending mailings there are only 'html', 'text' and 'subject' indexes.
Proposed behaviour
----------------------------------------
The `$content` is generated by CRM_Mailing_BAO_Mailing->getTemplates() method. This method should always adds more fields, like 'mailing_id' or 'campaign_id' which can be used during processing the hook.
Comments
----------------------------------------
This modification is used for altering urls with utm params, see https://github.com/WeMoveEU/utmaltorhttps://lab.civicrm.org/dev/core/-/issues/1618When extensions do upgrades and add fields to tables, trigger-based logging t...2022-07-28T04:01:43ZDaveDWhen extensions do upgrades and add fields to tables, trigger-based logging tables require the extension to do the right thingThis isn't technically a bug, but following on from [chat](https://chat.civicrm.org/civicrm/pl/t5a4atn9eiynin3gkbu888prqh), it was discovered that there might be several extensions that make database updates in upgraders but don't rebuil...This isn't technically a bug, but following on from [chat](https://chat.civicrm.org/civicrm/pl/t5a4atn9eiynin3gkbu888prqh), it was discovered that there might be several extensions that make database updates in upgraders but don't rebuild logging tables the same way core does after core upgrades (https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Upgrade/Form.php#L794), leading to missing log table fields. So the question came up of what part of the system should do that.
Is it:
1. a core issue,
2. a civix issue,
3. something that just requires a developer documentation update.
Core
----
----
It seems it's by design that all core does is start a queue, and run the upgrades the extension provides. See https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Admin/Page/ExtensionsUpgrade.php#L16. The corresponding CRM_Extension_Upgrades class is equally sparse. So this seems intentional to leave it up to the extension to do everything it needs to.
Civix
------------
------------
There's an argument it can't be up to civix to enforce because you don't technically need civix to write extensions. At the same time, that's how everyone makes extensions, so maybe the [template](https://github.com/totten/civix/blob/v20.02.0/src/CRM/CivixBundle/Resources/views/Code/upgrader.php.php) that civix generates should be updated to add some info/examples.
Side note: The template should probably also encourage using functions like addColumn(). https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Upgrade/Incremental/Base.php#L140
Dev docs
--------
--------
Probably there could be a docs update. Maybe at
https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-upgrader
or
https://docs.civicrm.org/dev/en/latest/framework/upgrade/5.43.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1616Activity Search doesn't display activities with no "With Contact"2023-02-16T15:15:35ZJonGoldActivity Search doesn't display activities with no "With Contact"To replicate:
* Create a new activity without anyone listed as "With Contact".
* Search for the activity from **Find Activities**.
I hadn't considered the use case of an activity with no "With Contact", but apparently my client has - an...To replicate:
* Create a new activity without anyone listed as "With Contact".
* Search for the activity from **Find Activities**.
I hadn't considered the use case of an activity with no "With Contact", but apparently my client has - and it's not a required field. So it seems that these activities should show up in search.https://lab.civicrm.org/dev/core/-/issues/1615Migrate installers to "setup" API2024-02-07T01:05:15ZtottenMigrate installers to "setup" APIOverview
----------------------------------------
The aim of this filing is to do a round of consolidation/reconciliation in the Civi installer code: get rid of `install/*.php` and instead use `civicrm-setup`. The latter offers:
* Bett...Overview
----------------------------------------
The aim of this filing is to do a round of consolidation/reconciliation in the Civi installer code: get rid of `install/*.php` and instead use `civicrm-setup`. The latter offers:
* Better APIs and better organization - e.g. you can drill-down on most installation tasks by browsing the [plugins](https://github.com/civicrm/civicrm-setup/tree/master/plugins/) (esp `installFiles` and `installDatabase`); inspect the list of event-listeners; and [programmatically manage plugins](https://github.com/civicrm/civicrm-setup/blob/master/docs/plugins.md).
* More sensible UX - the list of options is more useful for a new admin initializing the system.
![Screen_Shot_2020-02-14_at_6.03.12_PM](/uploads/f107602f3ebd5f60b6870322711629a5/Screen_Shot_2020-02-14_at_6.03.12_PM.png)
Some background: https://civicrm.org/blog/totten/developers-revising-the-civicrm-installer-library-cli-wordpress
Use-cases
----------------------------------------
There are several different use-cases for performing installation; most permutations of the following variables are fair:
1. __UF/CMS__: Civi can be installed on top of Backdrop, Drupal 6/7/8, Joomla, WordPress.
2. __Medium__: Civi can be installed through:
* Web installation screens (e.g. `civicrm/install/index.php` and the Joomla installer)
* CLI installers (e.g. `cv core:install`)
* Scripts/packagers (e.g. Drupal "profiles", `civibuild`, `docker`)
3. __Options__: Civi can be configured with:
* CMS DB or separate DB
* Empty data or demo data
* "Components" (enabled/disabled)
* "Extensions" (enabled/disabled)
* "Settings" (defaults/overrides)
* Path/URL definitions (defaults/overrides)
Current behavior
----------------------------------------
There are separate installers. There are number of arbitrary differences and un-DRY things.
Proposed behavior
----------------------------------------
All installers use a PHP API for Civi installation.
Process
----------------------------------------
There are several things to consolidate here; it's not just one commit or PR. Suggested tasks (in approximate order):
* [x] __Move code from `civicrm-setup.git` into `civicrm-core.git`__ (*done, [#16618](https://github.com/civicrm/civicrm-core/pull/16618)*):
* `civicrm-setup` started as a separate repo so that I could iterate quickly in the early stages. However, as this gets rolled into more use-cases, it's likely to get referenced in more places (e.g. `civicrm-drupal-8.git`, `civicrm-drupal.git`, `civicrm-wordpress.git`, `civicrm-backdrop.git`), and it is also reasonable to expect a few small patches. Unfortunately, juggling small patches in that arrangement would be mentally draining. Migrating the code into `civicrm-core.git` will remove one layer of complexity.
* Like the API framework or DB framework, the *installer* is sufficiently important to `civicrm-core` go into the main repo.
* [x] __Move docs from `civicrm-setup.git` into `civicrm-dev-docs.git`__ (*done, see [Dev Guide: Setup Reference](https://docs.civicrm.org/dev/en/latest/framework/setup/)*)
* [ ] __Update Civi-WordPress__:
* [x] (Phase 1) Switch the default from `install/` UI to `civicrm-setup` UI. (*It's currently available opt-in. Switch to opt-out.*)
* [x] (Phase 2) Update `wp-cli/civicrm.php` so that WP-CLI uses `civicrm-setup` API.
* [ ] (Phase 3) Ensure that all tasks (e.g. registering base-pages or permissions) are called in WP-oriented `*.civi-setup.php` plugin.
* [ ] __Update Civi-D8/D9__
* [x] (Phase 1) Update `civicrm.install` to call `civicrm-setup` APIs (related: https://github.com/civicrm/civicrm-drupal-8/pull/37)
* [ ] (Phase 2) Update `civicrm.drush.inc` so that D7/BD use `civicrm-setup` API.
* [ ] __Update Civi-D7/BD__
* [x] (Phase 1) Update `install/index.php` so that D7/BD default to loading the `civicrm-setup` UI. The sysadmin docs may continue pointing admins to `install/index.php`. Optionally, allow one to use a parameter to opt-out and get the old UI.
* [ ] (Phase 2) Update `civicrm.drush.inc` so that D7/BD use `civicrm-setup` API.
* [x] __Update Civi-Joomla__
* [x] (Phase 2) Update to use `civicrm-setup` API
* [x] __Ignore Civi-D6__
* [ ] __Update civibuild__
* [ ] (Phase 2) Switch implementation from `civicrm_install()` to `civicrm_install_cv()` (related WIP: https://github.com/civicrm/civicrm-buildkit/pull/673)
* [ ] (Phase 3) Remove old implementation
* [ ] (Phase ??) Convert `civicrm_make_test_settings_php()` to a `civicrm-setup` plugin. Document an installer-option to initialize test/dev-harness.
* [ ] __Remove all opt-outs. Final pass to double-check/remove all remaining logic from `install/` folder__
* (*This is the last step, after all the others.*)https://lab.civicrm.org/dev/core/-/issues/1610Notice: Array to string conversion in CRM_Utils_Address::format() (line 167 o...2023-02-15T05:03:30ZbrianhNotice: Array to string conversion in CRM_Utils_Address::format() (line 167 of CRM/Utils/Address.php).This seems to be spamming our logs, I checked and `$fields['world_region']` is indeed an array.This seems to be spamming our logs, I checked and `$fields['world_region']` is indeed an array.https://lab.civicrm.org/dev/core/-/issues/1609Duplicate key entry in cache2023-03-18T06:35:52ZsamuelsovDuplicate key entry in cacheFor the user, the problem occurred when he has tried to send a test email and I was able to reproduce when opening an draft mass emailing (non-mosaico).
![Capture_d_écran_2020-02-20_à_16.37.23](/uploads/7b9a93d367468b1c63b37b8077ea750...For the user, the problem occurred when he has tried to send a test email and I was able to reproduce when opening an draft mass emailing (non-mosaico).
![Capture_d_écran_2020-02-20_à_16.37.23](/uploads/7b9a93d367468b1c63b37b8077ea750a/Capture_d_écran_2020-02-20_à_16.37.23.png)
I've noticed in the log of several of our sites a few instances of this problem over the years and was able to see it in the database.
First the log :
```
[debug_info] => UPDATE civicrm_cache SET data = '...', created_date = FROM_UNIXTIME(1582213285), expired_date = FROM_UNIXTIME(1582234886) WHERE group_name = "contact-20fields" AND path = "custom importableFields 95d8b67bffebbc8912554acdd22d0310"
[nativecode=1062 ** Duplicate entry 'contact-20fields-custom importableFields 95d8b67bffebbc8912554ac' for key 'UI_group_path_date']
```
In the civicrm_cache table, there are indeed 2 entries that correspond and that are updated at the same time - hence the duplicate key entry :
```
select id, created_date from civicrm_cache where group_name = "contact-20fields" AND path = "custom importableFields 95d8b67bffebbc8912554acdd22d0310";
+-------+---------------------+
| id | created_date |
+-------+---------------------+
| 79704 | 2020-02-20 04:29:51 |
| 79709 | 2020-02-20 04:29:52 |
+-------+---------------------+
2 rows in set (0.001 sec)
```
The problem seems to have resolved itself after some auto-cleanup of the cache (the duplicate entries were in the database for 7 hours)
I suppose we could solve this by one of the following :
* if we don't have the created_date, do not update based on group_name + path alone, delete + insert instead
* forbid creation of 2 entries with the same group_name + path (but i'm pretty sure there a good reason for allowing that so probably not a good idea)
Anyway, it seems to be a rare case and really not sure if the solution above would create more problem that it resolves.
I don't plan to work on this. Feel free to close if the priority is too low in comparison to the complexity to solve it.https://lab.civicrm.org/dev/core/-/issues/1587Show full description under select2 options2020-02-12T02:11:04ZMonish DebShow full description under select2 optionsOverview
----------------------------------------
Show full description under select2 options
Current behavior
----------------------------------------
Visit the export field option or Event name select2 filter in 'Find Participant' se...Overview
----------------------------------------
Show full description under select2 options
Current behavior
----------------------------------------
Visit the export field option or Event name select2 filter in 'Find Participant' search form. It trims the description with a teaser.
![Screen_Shot_2020-02-11_at_8.29.30_PM](/uploads/ec0400cff8072e1a25f31aeeda449b5f/Screen_Shot_2020-02-11_at_8.29.30_PM.png)
![Screen_Shot_2020-02-11_at_8.30.03_PM](/uploads/3237148bddd75af1a1fc497a9139990a/Screen_Shot_2020-02-11_at_8.30.03_PM.png)
Proposed behavior
----------------------------------------
Show the full description of select2 options. Make the change option by introducing a special attribute and handle accordingly in js and css to support that. For further details check next section.
Technical details
----------------------------------------
Introduce a special boolean setting attribute to select2 option array (in PHP) say ```fullDescription``` = TRUE/FALSE. Based on these setting it will add a CSS class say ```crm-select2-row-full-description``` via js and then make style changes to show full description.5.24.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1586Add ? option? to NOT log to civicrm_log when logging is enabled2023-11-30T05:03:16ZeileenAdd ? option? to NOT log to civicrm_log when logging is enabledI was under the impression that we didn't use the civicrm_log table when we enable logging - certainly it becomes inaccessible through the UI. However, I have discovered that the table has swollen to 32 GB and that new entries are regula...I was under the impression that we didn't use the civicrm_log table when we enable logging - certainly it becomes inaccessible through the UI. However, I have discovered that the table has swollen to 32 GB and that new entries are regularly logged.
I feel like this duplicates the function of logging / is kind of 'logging-lite' and I thought for that reason we didn't do it. However, I realise changing it might cause issues. All I can think of is a setting to not log o civicrm_log if logging is enabled.
@seamuslee @pfigel @jitendra any thoughts?https://lab.civicrm.org/dev/core/-/issues/1581search results do not show primary data if searchPrimaryDetailsOnly = false2023-02-19T05:03:21ZMonish Debsearch results do not show primary data if searchPrimaryDetailsOnly = falseOverview
----------------------------------------
The search result should show the primary data consistently even if the searchPrimaryDetailsOnly = false.
Reproduction steps
----------------------------------------
1. Go to search se...Overview
----------------------------------------
The search result should show the primary data consistently even if the searchPrimaryDetailsOnly = false.
Reproduction steps
----------------------------------------
1. Go to search settings and turn searchPrimaryDetailsOnly off.
2. Then created a new contact with two email addresses. Consider the second email address as primary
3. Now conduct a search to find that record.
Current behavior
----------------------------------------
The search results will show the lower id/first email in the listing, even if it isn't the primary email.
Expected behavior
----------------------------------------
The search results should consistently display the primary data, so it should show the second email address in the list5.23.0Monish DebMonish Debhttps://lab.civicrm.org/dev/wordpress/-/issues/45Apply for listing in WordPress directory2023-12-11T12:27:09Zjoshjosh@civicrm.orgApply for listing in WordPress directoryIssue to track progress and outstanding issues related to listing CiviCRM in WP directory.Issue to track progress and outstanding issues related to listing CiviCRM in WP directory.https://lab.civicrm.org/dev/core/-/issues/1568scheduled reminder: select participant role permissions require admin & don't...2020-02-17T15:15:52ZDLaurysscheduled reminder: select participant role permissions require admin & don't match rest of scheduled reminder permissionsIn scheduled reminders, with all relevant event-level permissions, a person can set up almost every aspect of a scheduled reminder. However, if they choose 'limit to' or 'also include' and then opt for 'participant role', the drop-down b...In scheduled reminders, with all relevant event-level permissions, a person can set up almost every aspect of a scheduled reminder. However, if they choose 'limit to' or 'also include' and then opt for 'participant role', the drop-down box for which participant role does not appear.
This seems to be a bug, as viewing the drop-down box of roles and selecting a participant role to 'limit to' or 'also include' is not a higher level action than any of the other aspects of setting up a scheduled reminder.
I'm not a developer, just a user hoping that we don't have to keep giving staff administrative permissions just so they can set up this one minor aspect of a scheduled reminder. Thanks!https://lab.civicrm.org/dev/core/-/issues/1561"Primary" email option in Search Builder behaves as "Any"2023-06-04T05:03:24ZBobS"Primary" email option in Search Builder behaves as "Any"Overview
----------------------------------------
If Primary is selected as the email location in Search Builder, then contacts with a matching email address which is not primary are returned in the search results.
Reproduction steps
--...Overview
----------------------------------------
If Primary is selected as the email location in Search Builder, then contacts with a matching email address which is not primary are returned in the search results.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Search Builder**.
1. Create a search term **Contact | Email | Primary | = | <email_address>**.
1. Click **Search**.
Current behaviour
----------------------------------------
Contacts having <email_address> as a non-primary email are returned. Primary seems to function like "Any". Same problem with other operators, e.g. Like, RegEx.
Expected behaviour
----------------------------------------
Only contacts having a matching email address which is primary should be returned.
Environment information
----------------------------------------
* __CiviCRM:__ _5.21.0_
* __PHP:__ _7.2_
* __CMS:__ _Drupal 7.69_
* __Database:__ _MariaDB 10.0_
* __Web Server:__ _Apache 2.4.41_
Comments
----------------------------------------
The current behavior is useful, but should be called "Any" rather than "Primary", and a working "Primary" option should by provided as well.
Confirmed on [demo site](https://demo.circle-interactive.co.uk/civicrm)https://lab.civicrm.org/dev/core/-/issues/1559Use markdown in php docblocks2023-02-05T05:03:36ZcolemanwUse markdown in php docblocks**tl;dr:** I propose we standardize the format of our docblocks to use markdown.
To-date, docblocks in CiviCRM haven't been very visible (or very much of anything). The APIv4 Explorer is starting to change that. For example, this docblo...**tl;dr:** I propose we standardize the format of our docblocks to use markdown.
To-date, docblocks in CiviCRM haven't been very visible (or very much of anything). The APIv4 Explorer is starting to change that. For example, this docblock:
```php
/**
* ACL (Access Control List).
*
* An ACL record consists of:
*
* - an Operation (e.g. 'View' or 'Edit')
* - a set of Data that the operation can be performed on (e.g. a group of contacts)
* - and a Role that has permission to do this operation.
*
* Creating a new ACL requires at minimum a entity table, entity ID and object_table.
*
* @see https://docs.civicrm.org/user/en/latest/initial-set-up/permissions-and-access-control
* @package Civi\Api4
*/
class ACL extends Generic\DAOEntity {
```
Displays in the explorer like this:
![image](/uploads/2a04dad923b43fc4f5e739bef6feb064/image.png)
I've been doing my best to make them render nicely, for example it turns ticks into bullets, `@see` annotations into links, and double-line-breaks into paragraphs... but that's about it so far. It would be really nice if we could fully support markdown for formatting, lists, tables, code blocks, etc. etc.
Apparently using markdown in PHP docblocks is gaining popularity. [PHPStorm now supports it, as does PHPDocumentor](https://blog.jetbrains.com/phpstorm/2014/04/phpstorm-8-markdown-support-in-phpdoc-blocks/).
I suggest we jump on that bandwagon. If there's no objections I'll add a markdown parser to the APIv4 Explorer and start using markdown syntax in more docblocks.https://lab.civicrm.org/dev/core/-/issues/1557Quick Search doesn't respect "Search Primary Details Only" flag2023-02-19T05:03:21ZJonGoldQuick Search doesn't respect "Search Primary Details Only" flagQuick Search doesn't respect the "Search Primary Details Only" flag. To replicate:
* Create a contact with two addresses.
* Attempt to use Quick Search to find them by the non-primary street address.
I know "Search Primary Details Onl...Quick Search doesn't respect the "Search Primary Details Only" flag. To replicate:
* Create a contact with two addresses.
* Attempt to use Quick Search to find them by the non-primary street address.
I know "Search Primary Details Only" is a controversial feature, but I think in this particular case, we avoid the concerns that accompany this feature. See PR for details.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1551Advanced search links on mailing reports page give "DB Error: syntax error"2020-02-16T20:02:37ZIan WilsonAdvanced search links on mailing reports page give "DB Error: syntax error"After a mailing has been sent, all of the "Advanced Search" links on the mailing report page give a "DB Error: syntax error" page.
Steps to reproduce:
1. create a new mailing
1. wait for cron or execute the mailings scheduler job from /...After a mailing has been sent, all of the "Advanced Search" links on the mailing report page give a "DB Error: syntax error" page.
Steps to reproduce:
1. create a new mailing
1. wait for cron or execute the mailings scheduler job from /civicrm/admin/job
1. go to /civicrm/mailing/browse/scheduled?reset=1&scheduled=true and click on the report link for the completed mailing
1. click any of the "Advanced Search" links on the right side of the rows
Logs from ConfigAndLog show:
```sql
SELECT DISTINCT LEFT(contact_a.sort_name, 1) as sort_name
FROM civicrm_contact contact_a
LEFT JOIN civicrm_mailing_recipients ON civicrm_mailing_recipients.contact_id = contact_a.id
LEFT JOIN civicrm_mailing ON civicrm_mailing.id = civicrm_mailing_recipients.mailing_id
WHERE ( AND civicrm_mailing.id IN (15403) ) AND (contact_a.is_deleted = 0)
GROUP BY sort_name
ORDER BY sort_name asc
[nativecode=1064 ** You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use near
'AND civicrm_mailing.id IN (15403) ) AND (contact_a.is_deleted = 0)
```
The error occurs in 5.21.2 (we are testing this in preparation for the next ESR release) and I am also able to reproduce the problem on https://dmaster.demo.civicrm.org. The error doesn't occur in 5.13.8.5.23.0