CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-11-19T05:04:01Zhttps://lab.civicrm.org/dev/core/-/issues/1096Manage groups: Warning message on:hover shows edit option2022-11-19T05:04:01ZPradeep Nayakpradpnayak@gmail.comManage groups: Warning message on:hover shows edit optionSteps:
1. Click "Contact" -> "Manage Group"
2. Try to find some non-existent group
Take a look at the message: "No Groups have been created for this site."
Actual result: It is possible to edit the warning message. (See gif)
Expected ...Steps:
1. Click "Contact" -> "Manage Group"
2. Try to find some non-existent group
Take a look at the message: "No Groups have been created for this site."
Actual result: It is possible to edit the warning message. (See gif)
Expected result: It is not possible to edit the warning message.
![Groups](/uploads/7ddb5a784c299ed546f68e95311045a7/Groups.gif)https://lab.civicrm.org/dev/core/-/issues/1097Count on Groups tab changes when tab is loaded2019-07-04T15:12:28Zkirk-jacksonCount on Groups tab changes when tab is loadedIf a contact has been explicitly added to any Smart Groups, then the number on their Groups tab changes when the tab is loaded.
### Steps to reproduce
* Explicitly add a contact to a Smart Group by going to their Groups tab, clicking ...If a contact has been explicitly added to any Smart Groups, then the number on their Groups tab changes when the tab is loaded.
### Steps to reproduce
* Explicitly add a contact to a Smart Group by going to their Groups tab, clicking the "**+** Add to a group" dropdown, selecting a Smart Group and clicking the Add button.
* Refresh the page in the browser. Note the count on the Groups tab.
* Click the contact's Groups tab. Note the count on the Groups tab.
### Expected results
The count on the Groups tab should be as accurate as reasonably possible, and should not change when the Groups tab is loaded.
### Actual results
Before the Groups tab is loaded, the count does not include Smart Groups that the contact has been explicitly added to. After the Groups tab is loaded, the count changes to include Smart Groups that the contact has been explicitly added to.
### Cause
The count is calculated using the **CRM_Contact_BAO_GroupContact::getContactGroup** function, which is called by **CRM_Contact_BAO_Contact::getCountComponent** when the contact page is loaded, and by **CRM_Contact_Page_View_GroupContact::browse** when the Groups tab is loaded. The discrepancy arises because the two calls to that function pass different arguments: The first call omits the **$includeSmartGroups** argument, which defaults to **FALSE**, whereas the second call passes **TRUE** to the **$includeSmartGroups** argument.
### Proposal
I propose changing the call to **CRM_Contact_BAO_GroupContact::getContactGroup** in **CRM_Contact_BAO_Contact::getContactGroup** so that it passes **TRUE** to the **$includeSmartGroups** argument. This one-line change would ensure that the count on the Groups tab always includes Smart Groups to which the contact has been explicitly added.
Note that I'm only proposing counting groups to which the contact has been *explicitly* added; not all Smart Groups whose search criteria include the contact. Thus the change that I'm proposing avoids the [documented](https://issues.civicrm.org/jira/browse/CRM-11068) [problems](https://issues.civicrm.org/jira/browse/CRM-12466) with counting all Smart Groups. There is no significant performance hit.
I will submit a PR.https://lab.civicrm.org/dev/core/-/issues/1098Slow performance on activity search2020-08-28T04:32:05ZeileenSlow performance on activity searchI did some digging into this long term problem & have some code - basically the issue is actually when the 'acl' is applied it joins onto the option value table for activity type with a bad join.
However, it raises a couple of questions...I did some digging into this long term problem & have some code - basically the issue is actually when the 'acl' is applied it joins onto the option value table for activity type with a bad join.
However, it raises a couple of questions as to the right way to fix
I've added code comments into the PR at https://github.com/civicrm/civicrm-core/pull/15016 pointing to where I think we need to gohttps://lab.civicrm.org/dev/core/-/issues/1099CiviCRM Event - Confirm Your Registration Information page issue2019-11-29T15:07:44ZgibsonoliverCiviCRM Event - Confirm Your Registration Information page issueOn the event confirm your registration details page any Profile fields which contain a multi select field are showing incorrect values.
So the user may have selected 'Vegetarian' and 'Vegan' in a dietary requirements field.
But no matt...On the event confirm your registration details page any Profile fields which contain a multi select field are showing incorrect values.
So the user may have selected 'Vegetarian' and 'Vegan' in a dietary requirements field.
But no matter what they select on the confirm your registration details page all users will see, for example, the value 'Dairy Free' repeated.
When the event registration is saved the values 'Vegetarian' and 'Vegan' are saved correctly. So there is just an issue with the confirm your registration details page. We have seen this on 2 different systems (5.13.4). The attached file![Capture](/uploads/f994dee98fc070aebbb6099789878e26/Capture.PNG) shows an example.https://lab.civicrm.org/dev/core/-/issues/3384Confirming from waitlist counts deleted contacts2022-04-22T16:22:27ZJonGoldConfirming from waitlist counts deleted contactsTo replicate:
* Create an event with a waitlist of 1.
* Register a new contact ("User 1") for the event through the public interface (anonymously).
* Delete the contact.
* register 2 more contacts through the public interface. Note how ...To replicate:
* Create an event with a waitlist of 1.
* Register a new contact ("User 1") for the event through the public interface (anonymously).
* Delete the contact.
* register 2 more contacts through the public interface. Note how the deleted contact is NOT counted, and you can register User 2 for the event, and User 3 goes on the waitlist.
* Cancel User 2's registration and run the "Update Participant Statuses" scheduled job.
* User 3 will now receive an email to ask them to confirm they want to come off the waitlist. However, when you click the link, you're told that the event is full (because User 1, despite being deleted, is still counted).
The issue is `CRM_Event_BAO_Participant::pendingToConfirmSpaces()`. Not only does it not count deleted contacts, but it appears (haven't tested) to not count correctly if an event registration counts for multiple people.
The solution is to remove this code and replace the one place it's called with a call to `CRM_Event_BAO_Event::getParticipantCount()`.
I don't have time/funding to do this, but wanted to record my findings in case someone else encountered this problem.5.23.0https://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/3576Error on Fetch Bounces Scheduled job2022-06-11T14:54:37ZcalbasiError on Fetch Bounces Scheduled jobI get this error:
> Parameters parsed (and passed to API method):
> a:1:{s:7:"version";i:3;}
>
> Full message:
> Finished execution of Fetch Bounces with result: Error, Error message: A fatal error was triggered: No s'ha pogut connec...I get this error:
> Parameters parsed (and passed to API method):
> a:1:{s:7:"version";i:3;}
>
> Full message:
> Finished execution of Fetch Bounces with result: Error, Error message: A fatal error was triggered: No s'ha pogut connectar a MailStore per xxxxx@xxxxx.xxx@xxxxx.xxxxx.xxx
>
> Missatge d'error:
>
> Could not create /var/www/xxx/xxx/xxx/private/xxx/custom//CiviMail.ignored/2019/07/03/cur
But if I fire manually this job, it succeed!
That's why I think it's a bug.
I found a [related issue](https://civicrm.stackexchange.com/questions/4045/email-to-activity-processing-error-message-process-activities-failed)
Pay attention on this Stackexchange reporded issue talk about an error on "second run"
I'm using: CiviCRM 5.10.4.
By the way, I initially tried to use IMAP, but I was not able to connect the mail server, so I've changed to POP3. I don't think it has any relationship, but...https://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-1269https://lab.civicrm.org/dev/core/-/issues/1102If a report is sorted on a custom "Number" field, the sort should use numeric...2022-11-18T05:03:23ZtottenIf a report is sorted on a custom "Number" field, the sort should use numeric orderingI observed this while replicating #1081, so steps to reproduce start out similarly. Of course, it is a different issue, so the steps do become different. The steps are:
(1) Create a custom field on contribution records. Make it "Number=...I observed this while replicating #1081, so steps to reproduce start out similarly. Of course, it is a different issue, so the steps do become different. The steps are:
(1) Create a custom field on contribution records. Make it "Number=>Text" and flag it as searchable. I called the example "Frobnication Score".
![Screen_Shot_2019-07-03_at_8.59.44_PM](/uploads/a54e1537d12bbb9061620ece8d214e07/Screen_Shot_2019-07-03_at_8.59.44_PM.png)
(2) Do a search for some contribution records. Edit a few of them and fill in made-up values for the "Frobnication Score". I happened to use "100", "120", and "90.
(3) Create a "Contribution Detail" report. In "Columns", add the "Frobnication Score". In "Sorting", choose "Frobnication Score" (first) and "Contact Name (in sort format)" (second).
The column is numerical, so you would expect the ordering to be numerical (ascending, "90 => 100 => 120"; or descending, "120 => 100 => 90"). The actual ordering looks like dictionary/alphabetic ("100", "120", "90"). For numeric data, the only useful ordering would be... numerical ordering...
![Screen_Shot_2019-07-03_at_8.58.33_PM](/uploads/d650e5ca589ad2bde2b851faaa76203e/Screen_Shot_2019-07-03_at_8.58.33_PM.png)
I've observed similar behavior in 5.12.4 and 5.16.alpha1.https://lab.civicrm.org/dev/core/-/issues/3276Unreleased regression - fee levels incorrectly show sold out (in code that wi...2022-04-22T15:53:33ZeileenUnreleased regression - fee levels incorrectly show sold out (in code that will be 5.16)Fees are incorrectly showing as sold out, blocking change fee selection.
This is an unexpected consequence of
https://github.com/civicrm/civicrm-core/pull/14244
The path is that because $this->_id is now set it gets assigned to the fo...Fees are incorrectly showing as sold out, blocking change fee selection.
This is an unexpected consequence of
https://github.com/civicrm/civicrm-core/pull/14244
The path is that because $this->_id is now set it gets assigned to the form
https://github.com/civicrm/civicrm-core/blob/5774b54f47445de233daa85672ce4f793dff347a/CRM/Event/Form/Participant.php#L265
Which then gets passed to the call to load the fee block
https://github.com/civicrm/civicrm-core/blob/c4145dedecb1f3157ecf8fd85421f562e8128e73/templates/CRM/Event/Form/Participant.tpl#L411
which results in $_pid being set & as a result online being set
https://github.com/civicrm/civicrm-core/blob/90b461f1623e75e94e0f472a3c6bf23e01defbc1/CRM/Event/Form/EventFees.php#L350
which leads to the element being frozen
https://github.com/civicrm/civicrm-core/blob/90b461f1623e75e94e0f472a3c6bf23e01defbc1/CRM/Event/Form/EventFees.php#L393
which is interpretted as 'sold out'
https://github.com/civicrm/civicrm-core/blob/6b83d5bdd0f2ca546924feae6aa42aeddb1d40cf/templates/CRM/Price/Form/PriceSet.tpl#L93
This is an example of a code antipattern which is too prevalent in our codebase - ie. hanging various assumptions off a parameter.
I *think* the right answer is to assign a variable of online & then pass that through & make appropriate decisions based on that.
The first question is - do we revert https://github.com/civicrm/civicrm-core/pull/14244 out of the rc and then re-commit into master to give us more time given how awful this code path is5.16.0https://lab.civicrm.org/dev/core/-/issues/1103Activity search by date range fails when "to" is empty2019-07-05T09:41:27Zsluc23Activity search by date range fails when "to" is emptySearching by Activity date range, only entering *from* date, and leaving *to* date empty fails.
`Activity Date: Please check that your date range is in correct chronological order.`
![Peek_2019-07-04_10-33](/uploads/900e721bd2d6c4a6...Searching by Activity date range, only entering *from* date, and leaving *to* date empty fails.
`Activity Date: Please check that your date range is in correct chronological order.`
![Peek_2019-07-04_10-33](/uploads/900e721bd2d6c4a6a1888008a32a2998/Peek_2019-07-04_10-33.gif)https://lab.civicrm.org/dev/core/-/issues/1104Make admin panels hookable2019-08-01T04:07:14ZyashodhaMake admin panels hookableMake it easy to show/hide items on administer screen.Make it easy to show/hide items on administer screen.5.17.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1105Users who can add price options can't reorder them2022-11-19T05:04:00ZJKingsnorthUsers who can add price options can't reorder themThe permission to be able to add price sets, and price options is related to: `access CiviCRM,access CiviEvent`
However, in order to re-arrange price set options, the user needs to have `administer CiviCRM`.
This leads to a weird scena...The permission to be able to add price sets, and price options is related to: `access CiviCRM,access CiviEvent`
However, in order to re-arrange price set options, the user needs to have `administer CiviCRM`.
This leads to a weird scenario where users can create price options, but cannot re-order them.
The snag is: the 'weight' functionality is used all over the site. So how do we know which permissions to assign?https://lab.civicrm.org/dev/core/-/issues/3272Postal Code Suffix returns Postal Code value2022-04-22T15:53:21ZlcdwebPostal Code Suffix returns Postal Code valueWhen the postal code suffix column is displayed, it returns the postal code value instead of the suffix.When the postal code suffix column is displayed, it returns the postal code value instead of the suffix.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/3275A mental health plan for search2022-04-22T15:53:29ZeileenA mental health plan for searchI've been thinking a lot about how to move forwards with search functionality of late. When I think about the sorts of bugs and regressions we were dealing with 2 years ago versus today there are a lot of areas of the code that were cons...I've been thinking a lot about how to move forwards with search functionality of late. When I think about the sorts of bugs and regressions we were dealing with 2 years ago versus today there are a lot of areas of the code that were constantly breaking or requiring changes 2 years ago that we now rarely touch. We have added barrage of unit tests & retrofitted sanity into the code & eventually reached the end of the line on the whackamole in a lot of areas. Not so much searches & reports....
Part of the problem is that we were late to the party getting searches and reports under unit testing - or at least some of the more obscure search functionality. But much more of the problem is the poor underlying code structure for searches and the in-built reports. In addition search builder and advanced search expose much more functionality than actually works well - creating a back door for new tricky functionality. Compounding this, the original search code had a lot of security holes in it which have sent us into various cycles of whackamole.
When we talk about search people want to
- be able to retrieve data
- take actions on that data
- create groups based on the data
In many cases they can use a report or some custom form to retrieve a group of contacts but then they can't take the actions they want on those contacts. In particular it's currently impossible to create a smart group or utilise our bank of actions without working off the search framework. The problem with getting away from our quickform search structure is that we have a lot of assets tied up with it and so creating a non-quickform search quickly runs into the fact that various actions cannot be accessed and the lift involved in getting past that is too much - so we wind up with 'yet another custom search' or another change to core to bad code.
I don't think we can break the situation where we are spending a tonne of sunk time on search functionality in the short-term. I think adding thises & thats to search & custom searches and reports will continue at least for another year. The [data processor extension](https://lab.civicrm.org/extensions/dataprocessor/tree/master) by @jaapjansma does a pretty good of retrofitting sanity onto the quickform search structure, but I think we should set a goal that in a year's time quickform search structure and BAO_Query object are out of active development and there is a viable alternative.
We already have a pretty good alternative for retrieving the data - apiv4. When you look at apiv4 explorer if 'feels like' all you need to turn that into a replacement for search builder is a 'create smart group function'
Many of the things that work badly in search builder already work well in the apiv4 explorer but it is missing the ability to leverage our 'action-bank'. Going down the apiv4-as-smart-groups path also sets us up to offer the ability to have custom apiv4 apis that can also create smart groups and leverage actions.
That was a pretty long intro but the point of this ticket was more to spell out a path that I think allows us to start chipping away at this and to divert some of our 'product maintenance effort' towards breaking the cycle. These are the steps I think need taking (not necessarily in this order). Any of the steps, but in particular 3 & 4 would be suitable as funded CT work & that would speed them up & this whole process considerably, but I think there are things we can be doing now towards the end result.
1) create the ability to programaticially create a smart group based on an apiv4 explorer 'get' action. I think this is actually not that tricky. We would need to define the format of the array saved to 'form_values' - something like ['module' => 'apiv4', 'entity' => 'x', 'where' => [], 'select' => [], 'orderBy => []]. Perhaps ->createSavedSearch() would be an action that can be taken from apiv4? We would need to hobble UI functionality related to the smart group that might not work - ie suppress actions that don't work & the 'edit smart group search criteria' link in the group settings page - we can be a bit clunky on this in this step since it would not be exposed unless a developer exposed it. I feel like this step is pretty manageable & could be done in the next couple of releases. Since I think we should start on this I have created https://lab.civicrm.org/dev/core/issues/1107 for specific discussion on this issue
2) consider extending the above to cover other api actions - we talked about the idea of it being possible to create a smart group off a report. This is mostly a conversation about what sort of api an extension needs to create for it to be available for a saved search & what metadata is required. It would also involved creating a protocol to configure a url for 'edit smart group search criteria'. This could be done in conjunction with making smart groups possible from extended reports via an apiv4 action as experimental functionality. I don't see this as ever being a feature in core reports as I hope that by the time we've matured all of this we'll be figuring out how to leave them behind, but it seems like a way of opening up the transition process to leaping by extension.
3) tackle the search actions - figure out how to make them less tied to the QF architecture they sit on - could they be apis? Or just a much more sensible php interface? This is probably the deeper dive of this work and it might be a big lift but I also feel it's the sort of thing that we routinely chip away at in the product maintenance sphere & we could do that here. I suspect @mattwire has more idea than I do of that code at the moment...
4) Copy & adapt (or extract & componentise) the api v4 explorer to be search oriented. Mostly tie the search part of the interface with an action selector. Alternatively look at something like https://querybuilder.js.org/ - I feel like this piece is something CT should do as a dedicated chunk of work & which could be done at any point in the process by soliciting funding.
@totten @mattwire @colemanw @seamuslee @jitendra @monish.deb @pradeep @yashodha @bgm @lcdweb @johntwyman @mfb @pfigel @DaveD @justinfreemanhttps://lab.civicrm.org/dev/core/-/issues/1106A mental health plan for search2020-04-05T08:07:41ZeileenA mental health plan for searchI've been thinking a lot about how to move forwards with search functionality of late. When I think about the sorts of bugs and regressions we were dealing with 2 years ago versus today there are a lot of areas of the code that were cons...I've been thinking a lot about how to move forwards with search functionality of late. When I think about the sorts of bugs and regressions we were dealing with 2 years ago versus today there are a lot of areas of the code that were constantly breaking or requiring changes 2 years ago that we now rarely touch. We have added barrage of unit tests & retrofitted sanity into the code & eventually reached the end of the line on the whackamole in a lot of areas. Not so much searches & reports....
Part of the problem is that we were late to the party getting searches and reports under unit testing - or at least some of the more obscure search functionality. But much more of the problem is the poor underlying code structure for searches and the in-built reports. In addition search builder and advanced search expose much more functionality than actually works well - creating a back door for new tricky functionality. Compounding this, the original search code had a lot of security holes in it which have sent us into various cycles of whackamole.
When we talk about search people want to
- be able to retrieve data
- take actions on that data
- create groups based on the data
In many cases they can use a report or some custom form to retrieve a group of contacts but then they can't take the actions they want on those contacts. In particular it's currently impossible to create a smart group or utilise our bank of actions without working off the search framework. The problem with getting away from our quickform search structure is that we have a lot of assets tied up with it and so creating a non-quickform search quickly runs into the fact that various actions cannot be accessed and the lift involved in getting past that is too much - so we wind up with 'yet another custom search' or another change to core to bad code.
I don't think we can break the situation where we are spending a tonne of sunk time on search functionality in the short-term. I think adding thises & thats to search & custom searches and reports will continue at least for another year. The [data processor extension](https://lab.civicrm.org/extensions/dataprocessor/tree/master) by @jaapjansma does a pretty good of retrofitting sanity onto the quickform search structure, but I think we should set a goal that in a year's time quickform search structure and BAO_Query object are out of active development and there is a viable alternative.
We already have a pretty good alternative for retrieving the data - apiv4. When you look at apiv4 explorer if 'feels like' all you need to turn that into a replacement for search builder is a 'create smart group function'
Many of the things that work badly in search builder already work well in the apiv4 explorer but it is missing the ability to leverage our 'action-bank'. Going down the apiv4-as-smart-groups path also sets us up to offer the ability to have custom apiv4 apis that can also create smart groups and leverage actions.
That was a pretty long intro but the point of this ticket was more to spell out a path that I think allows us to start chipping away at this and to divert some of our 'product maintenance effort' towards breaking the cycle. These are the steps I think need taking (not necessarily in this order). Any of the steps, but in particular 3 & 4 would be suitable as funded CT work & that would speed them up & this whole process considerably, but I think there are things we can be doing now towards the end result.
1) create the ability to programaticially create a smart group based on an apiv4 explorer 'get' action. I think this is actually not that tricky. We would need to define the format of the array saved to 'form_values' - something like ['module' => 'apiv4', 'entity' => 'x', 'where' => [], 'select' => [], 'orderBy => []]. Perhaps ->createSavedSearch() would be an action that can be taken from apiv4? We would need to hobble UI functionality related to the smart group that might not work - ie suppress actions that don't work & the 'edit smart group search criteria' link in the group settings page - we can be a bit clunky on this in this step since it would not be exposed unless a developer exposed it. I feel like this step is pretty manageable & could be done in the next couple of releases. Since I think we should start on this I have created https://lab.civicrm.org/dev/core/issues/1107 for specific discussion on this issue
2) consider extending the above to cover other api actions - we talked about the idea of it being possible to create a smart group off a report. This is mostly a conversation about what sort of api an extension needs to create for it to be available for a saved search & what metadata is required. It would also involved creating a protocol to configure a url for 'edit smart group search criteria'. This could be done in conjunction with making smart groups possible from extended reports via an apiv4 action as experimental functionality. I don't see this as ever being a feature in core reports as I hope that by the time we've matured all of this we'll be figuring out how to leave them behind, but it seems like a way of opening up the transition process to leaping by extension.
3) tackle the search actions - figure out how to make them less tied to the QF architecture they sit on - could they be apis? Or just a much more sensible php interface? This is probably the deeper dive of this work and it might be a big lift but I also feel it's the sort of thing that we routinely chip away at in the product maintenance sphere & we could do that here. I suspect @mattwire has more idea than I do of that code at the moment...
4) Copy & adapt (or extract & componentise) the api v4 explorer to be search oriented. Mostly tie the search part of the interface with an action selector. Alternatively look at something like https://querybuilder.js.org/ - I feel like this piece is something CT should do as a dedicated chunk of work & which could be done at any point in the process by soliciting funding.
@totten @mattwire @colemanw @seamuslee @jitendra @monish.deb @pradeep @yashodha @bgm @lcdweb @johntwyman @mfb @pfigel @daved @justinfreeman https://lab.civicrm.org/dev/core/-/issues/1107create the ability to programaticially create a smart group based on an apiv4...2024-01-16T05:03:24Zeileencreate the ability to programaticially create a smart group based on an apiv4 explorer 'get' actionSub issue of https://lab.civicrm.org/dev/core/issues/1106Sub issue of https://lab.civicrm.org/dev/core/issues/1106https://lab.civicrm.org/dev/core/-/issues/1108Unsubscribe broken if mailing sent to previous mailing recipients with an exc...2019-11-17T19:42:12ZRichUnsubscribe broken if mailing sent to previous mailing recipients with an excluded groupI think <https://lab.civicrm.org/dev/core/commit/96fce13bb554201fa9eae10b02160ed7b5644806> broke the unsubscribe in various situations.
The logic is pretty hard to follow because the options create zillions of use cases, however, having...I think <https://lab.civicrm.org/dev/core/commit/96fce13bb554201fa9eae10b02160ed7b5644806> broke the unsubscribe in various situations.
The logic is pretty hard to follow because the options create zillions of use cases, however, having been hit by this I can report that the following situation created it:
1. send a mailing (A) to a mailing group
2. send a second mailing (B) to the recipients of mailing (A), excluding those in a group (C).
Recipients of (B) will not be able to unsubscribe.
This is because (as I have understood so far):
1. The unsubscribe code is supposed to find all the lists of contacts (I'm deliberately using _lists_ to avoid ambiuities with _groups_ -if I say _group_ it means a CiviCRM group as you would see on a contact's record.) that were used to select recipients of the mailing. These "lists" might be groups or previous mailings.
2. After the initial fetch - for the mailing that triggered the unsubscribe - there is a recursive fetch loop that goes back up the tree of mailings that were used to include contacts in the lists, finding all their included groups.
The code introduced by the commit above makes (1) return no records, and therefore the second step is never triggered, resulting in no groups whatsoever being identified as the ones to unsubscribe (remove) contacts from.
This is getting orgs using CiviMail in this way in hot water as you can imagine.5.21.0RichRichhttps://lab.civicrm.org/dev/core/-/issues/1109Contact Reference fields are not updated when merging contacts2019-08-08T03:27:12ZPatrick Figelpfigel@greenpeace.orgContact Reference fields are not updated when merging contactsWhen contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at som...When contacts are merged, any Contact Reference custom fields pointing to the contact that was deleted will not be updated to point to the remaining contact.
This is not a recent regression. It used to work in 4.6, but was broken at some point after that. (Confirmed as broken in 5.7, 5.13 and master.)5.17.0https://lab.civicrm.org/dev/core/-/issues/1110Contribution Summary Report does not update the Total Amount and Total Contri...2023-02-08T05:03:14ZCésarContribution Summary Report does not update the Total Amount and Total Contributions with some filtersHello,
In contribution summary report doesn't update the total amount and total contributions in statistics with this filters:
- total_amount_value
- non_deductible_amount_value
- total_sum_value
- total_avg_value
- total_count_value
...Hello,
In contribution summary report doesn't update the total amount and total contributions in statistics with this filters:
- total_amount_value
- non_deductible_amount_value
- total_sum_value
- total_avg_value
- total_count_value
Other filters are working good and show correct statistics based in final expected result.
Im testing this report on 5.15.1