CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2020-02-27T21:27:09Zhttps://lab.civicrm.org/dev/core/-/issues/1158mailing label primary address selection ignored if global option searchPrimar...2020-02-27T21:27:09Zlcdwebmailing label primary address selection ignored if global option searchPrimaryDetailsOnly disabledTo reproduce:
1. set Search Preferences > Search Primary Details Only to No
2. create a contact and add two distinguishable addresses
3. search for the contact
4. from the search actions task list, select Mailing Labels
5. choose p...To reproduce:
1. set Search Preferences > Search Primary Details Only to No
2. create a contact and add two distinguishable addresses
3. search for the contact
4. from the search actions task list, select Mailing Labels
5. choose primary and generate the labels
The non-primary address will be created. Note -- under the hood, it appears that when no location type or is_primary is selected, the lowest address ID is what will be included in the mailing label. You may need to tweak the raw address records to ensure the non-primary address has a lower ID in order to replicate.lcdweblcdwebhttps://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/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/799While upgrading from CiviCRM 4.6 to 5.10.x , old smartgroups stopped refreshi...2020-07-13T02:47:16ZVangelisPWhile upgrading from CiviCRM 4.6 to 5.10.x , old smartgroups stopped refreshing contactsSteps to reproduce:
1) Save a smartgroup that was using eg. a customfield value on a CiviCRM 4.6.x environment
2) Migrate to the latest CiviCRM
3) Change a contact so that the change can reflect to that smartgroup
4) Do a simple search ...Steps to reproduce:
1) Save a smartgroup that was using eg. a customfield value on a CiviCRM 4.6.x environment
2) Migrate to the latest CiviCRM
3) Change a contact so that the change can reflect to that smartgroup
4) Do a simple search using this smartgroup. Contact should not appear. `drush cvapi job.group_rebuild` doesn't fix the issue.
Resolution:
We traced this down to the fact that old form values and in general saved search settings were not being converted to new form values during the upgrade process.
There are 2 possible solutions on this:
1) Open the smartgroup criteria, do a search and `update smartgroup`. This is efficient if there are not many smartgroups in the installation.
2) Include a fix during the upgrade process that will call in essence those lines:
```php
// Read the existing form values
$formValues = CRM_Contact_BAO_SavedSearch::getFormValues($SavedSearchId);
// Update saved search record.
$savedSearch = new CRM_Contact_BAO_SavedSearch();
$savedSearch->id = $SavedSearchId;
$savedSearch->form_values = serialize(CRM_Contact_BAO_Query::convertFormValues($formValues));
$savedSearch->save();
```
In our case, we followed this path:
1) We've made a custom API call to do a search for all smartgroups and then apply the above fix on each one of these.
2) Then we issued a `TRUNCATE TABLE civicrm_group_contact_cache`.
3) Lastly, we issued a `drush cvapi job.group_rebuild` to force a smartgroup rebuild.
It seems that it's fixing our issue.
Do you believe that the upgrader needs a patch to resolve this situation?https://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/772Warnings on importing contacts - PHP 7.22019-12-25T22:06:45ZsbyrneWarnings on importing contacts - PHP 7.2While importing contacts from a CSV file, seeing the following on hitting "Continue" immediately following file upload:
```
Warning: count(): Parameter must be an array or an object that implements Countable in HTML_QuickForm_hierselect...While importing contacts from a CSV file, seeing the following on hitting "Continue" immediately following file upload:
```
Warning: count(): Parameter must be an array or an object that implements Countable in HTML_QuickForm_hierselect->setValue() (line 262 of ...civicrm/packages/HTML/QuickForm/hierselect.php).
Warning: count(): Parameter must be an array or an object that implements Countable in HTML_QuickForm_hierselect->setValue() (line 262 of ...civicrm/packages/HTML/QuickForm/hierselect.php).
Warning: count(): Parameter must be an array or an object that implements Countable in HTML_QuickForm_hierselect->setValue() (line 262 of ...civicrm/packages/HTML/QuickForm/hierselect.php).
Warning: count(): Parameter must be an array or an object that implements Countable in HTML_QuickForm_hierselect->setValue() (line 262 of ...civicrm/packages/HTML/QuickForm/hierselect.php).
```
Using the following settings if this helps replicate (everything else set at default:
* First Row Contains Column headers on
* Duplicate contacts set to fill
* Dedupe rule checking name and address
* Geocoding address on import5.18.0eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/767Add 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Det...2019-03-04T13:47:10ZGhost UserAdd 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Detail Contributions ReportAdd the fields and filters 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Detail Contributions Report.Add the fields and filters 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Detail Contributions Report.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/748Deadlocks and performance issues when using smartgroups / ACLs extensively2021-03-28T20:28:08Zmattwiremjw@mjwconsult.co.ukDeadlocks and performance issues when using smartgroups / ACLs extensivelyThis is an issue to track work on resolving performance issues (deadlocks) with Smartgroups / ACLs.
Specific details of a site where this is a major issue:
* About 80 staff login each day and create/update cases/activities.
* Access to c...This is an issue to track work on resolving performance issues (deadlocks) with Smartgroups / ACLs.
Specific details of a site where this is a major issue:
* About 80 staff login each day and create/update cases/activities.
* Access to cases/activities controlled via ACLs and smartgroups.
* Approximately 12000 contacts, 12000 cases, 62000 activities. MySQL 5.5.61
Related:
* https://lab.civicrm.org/dev/core/issues/395
* https://github.com/civicrm/civicrm-packages/pull/197
* https://issues.civicrm.org/jira/browse/CRM-18120
* https://github.com/civicrm/civicrm-core/pull/13672 (closed)
* https://github.com/civicrm/civicrm-core/pull/13714 (closed/ replaced?)
* https://github.com/civicrm/civicrm-core/pull/13772 (merged)
* https://github.com/civicrm/civicrm-core/pull/13732 (merged)https://lab.civicrm.org/dev/core/-/issues/735Query performance - suppress 'product' and related fields where products are ...2019-04-26T06:50:00ZeileenQuery performance - suppress 'product' and related fields where products are not in the databaseMost people hate the fact we waste an output field on premium on the contribution tab. They all think it should be replaced - but all have different replacements.
I don't want to solve that - I think the right solution for that is to f...Most people hate the fact we waste an output field on premium on the contribution tab. They all think it should be replaced - but all have different replacements.
I don't want to solve that - I think the right solution for that is to find funding to leap the interface.
What I DO think we can solve is the fact we are doing unnecessary joins / queries / processing to generate & display premiums - regardless of whether the site uses them. I think we could short-circuit that pretty cleanly by just doing a quick
"select id FROM civicrm_product_premium LIMIT 1' (cached) before adding product fields to our default return properties (with a small tpl tweak too)5.13.0https://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/692Unable to use url search arguments in 'Advanced Search' using force=12023-02-25T05:03:38ZMonish DebUnable to use url search arguments in 'Advanced Search' using force=1Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm...Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm-core/blob/5.10/CRM/Contact/Form/Search.php#L636L647).
Following are the steps to support URL search arguments Civi component-wise:
1. All the search forms extends the parent class ```CRM_Core_Form_Search``` that will define a new function ```loadSearchParamsFromUrl()```. Definition as follows
```php
function loadSearchParamsFromUrl() {
// In case no component is defined then lookout for basic contact search fields + all enanbled components search fields
if (!$this->_component) {
if (method_exists('CRM_Contact_Form_Search', 'setSearchParamFromUrl')) {
CRM_Contact_Form_Search::setSearchParamFromUrl($this);
}
foreach ($enabledComponents as $component) {
$searchClass = $component->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
$searchClass::setSearchParamFromUrl($form);
}
}
}
elseif (array_key_exists($this->_component, $enabledComponents)) { // $_component = 'CiviMail'
$searchClass = $enabledComponents[$this->_component]->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
// call CRM_Mailing_Form_Search::setSearchParamFromUrl()
$searchClass::setSearchParamFromUrl($form);
}
}
}
```
2. This function will be called by respective search form to find the search arguments from URL and set them accordingly. And will be handled in ```SearchClass::setSearchParamFromUrl($form);``` as:
```php
class CRM_Contact_Form_Search {
...
public static function setSearchParamFromUrl(&$form) {
foreach (CRM_Contact_Form_Search_Criteria::getBasicSearchFields() as $name => $type) {
if ($value = CRM_Utils_Request::retrieve($name, $type)) {
$form->_formValues[$name] = $value;
}
}
$form->_params = CRM_Contact_BAO_Query::convertFormValues($form->_formValues);
$form->set('formValues', $form->_formValues);
$form->set('queryParams', $form->_params);
}
}
```
The intent is to generalize the workflow and let each component's search form decide and hosts its list of search arguments (on basis of enabled component) rather than manually handling them in different places.5.11Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/669Custom Field is_required and is_view set to NULL instead of 0 if checkboxes n...2022-09-28T05:03:35ZjackrabbithannaCustom Field is_required and is_view set to NULL instead of 0 if checkboxes not checked on edit formMay need two separate issues created for this, depends on if we think these are bugs or new expected behavior.
Noticed doing a 'get' API call, CustomField entity, that the is_required and is_view properties are no longer present in API ...May need two separate issues created for this, depends on if we think these are bugs or new expected behavior.
Noticed doing a 'get' API call, CustomField entity, that the is_required and is_view properties are no longer present in API results if they are not checked via the standard custom field edit form.
replicable on dmaster.demo.civicrm.org
Create a custom field, and use the API explorer to look at it's properties
```
$result = civicrm_api3('CustomField', 'get', [
'sequential' => 1,
'id' => 13,
]);
```
I made a field on dmaster.demo, with id 13
Immediately after field creation, is_required showed 0
Went back and edited the custom field and saved, is_required is not present in the values at all
In the past is_required and is_view properties were present in the results, but had a value of 0.
2 things about this.
1) The value stored in the database is now NULL and not 0, I think this is a bug, but IDK. Especially after the field has been edited, the user made a decision that the field is not required, so the data in the database should represent that decision. NULL to me represents no decision.
2) If a value is NULL is the API not including the property in the results? This is inconsistent with the 'getfields' call for an entity...the properties returned for a 'get' api action by the 'getfields' request, should match, that is even if the value is NULL, then the API should return 'is_required' => NULL .
Code down the line may depend on this property being set...like CiviCRM Entity or other API consumers...In the case of CiviCRM Entity, we specifically set up Drupal entity type metadata based on the 'getfields' call and it is expecting the properties to be there when a 'get' call is made...
for 1) this must be a problem with form post process, to be saving the value as NULL and not 0. Do people see this as a bug, are we setting the is_required and is_view columns to NULL instead of 0 on purpose?
2) Do people agree that the expected behavior should be as I describe for the API?https://lab.civicrm.org/dev/core/-/issues/522Add case tokens to email activities2021-09-13T00:04:33ZeileenAdd case tokens to email activitieshttps://lab.civicrm.org/dev/core/-/issues/521PCP Owner notification email sending before payment2023-08-14T05:03:17Zrita_compucorpPCP Owner notification email sending before paymentHi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates y...Hi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates you out from civicrm to its own payment page (like sagepay, or paypal standard) the owner notification is sent before the payment has been made.
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
- when you click confirm button on the fundraising page, you will get navigated to the payment processor you set up for the contribution page --> this is the point when the notification email is sent to the fundraiser
Expected result: notification for the owner is sent only after a successful donation to the fundraising pagehttps://lab.civicrm.org/dev/core/-/issues/519Event receipts for paid events contains extraneous information2022-09-15T05:03:47ZmadhaviEvent receipts for paid events contains extraneous informationCurrently using CiviCRM 5.3.2 and drupal 7.60
Receipts for events paid via PayPal have extra information related to contribution.
**To reproduce issue:**
1. Add custom fields of your choice for Contributions
2. Create a paid event a...Currently using CiviCRM 5.3.2 and drupal 7.60
Receipts for events paid via PayPal have extra information related to contribution.
**To reproduce issue:**
1. Add custom fields of your choice for Contributions
2. Create a paid event and assign `PayPal Standard` payment processor.
3. Enable online registration for the event and set `Send Confirmation Email` to `Yes`.
4. Register a participant for the event.
5. Check the receipt received and see if you get Contribution related custom fields in the email.
Anyone is facing this issue? May be with other payment processor?https://lab.civicrm.org/dev/core/-/issues/512Cannot update checkbox fields in activities using "Update Multiple Activities"2022-10-25T05:03:40ZalarmingcodCannot update checkbox fields in activities using "Update Multiple Activities"Error found on client site (5.3.1) replicated on sandbox today
Updating activity custom data via "Update multiple activities" (Batch update via profile)
When data in a checkbox field is updated, error message appears
```
CiviCRM_API3_...Error found on client site (5.3.1) replicated on sandbox today
Updating activity custom data via "Update multiple activities" (Batch update via profile)
When data in a checkbox field is updated, error message appears
```
CiviCRM_API3_Exception: "'' is not a valid option for field custom_15"
#0 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Activity/Form/Task/Batch.php(242): civicrm_api3("activity", "create", (Array:7))
#1 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Form.php(489): CRM_Activity_Form_Task_Batch->postProcess()
#2 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/StateMachine.php(160): CRM_Core_Form->mainProcess()
#3 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Activity_Form_Task_Batch), "next", "Next")
#4 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Activity_Form_Task_Batch), "next")
#5 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Activity_Form_Task_Batch), "next")
#6 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("next")
#7 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(309): CRM_Core_Controller->run((Array:3), (Array:1))
#8 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
#9 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#10 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/drupal/civicrm.module(445): CRM_Core_Invoke::invoke((Array:3))
#11 /srv/buildkit/build/dmaster/includes/menu.inc(527): civicrm_invoke("activity", "search")
#12 /srv/buildkit/build/dmaster/index.php(21): menu_execute_active_handler()
#13 {main}
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
'' is not a valid option for field custom_15
Return to home page.
```
Text fields, radio fields, select fields update without issue.
Issue does not arise when updating contact records via profilehttps://lab.civicrm.org/dev/core/-/issues/495CQ: Migrate simple Preferences & Settings forms to using a Generic class.2023-06-27T05:03:25ZeileenCQ: Migrate simple Preferences & Settings forms to using a Generic class.Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the cl...Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the class 'CRM_Admin_Form_Preferences_Event' and all classes that don't need special sauce would be removed & the xml would be altered to
```
<item>
<path>civicrm/admin/setting/preferences/event</path>
<title>CiviEvent Component Settings</title>
<page_callback>CRM_Admin_Form_Generic</page_callback>
</item>
```
This page would load settings based on filtering setting metadata - so any fields with a key in their metadata like this
```
settings_pages => [
'event' => ['weight' => 10]
]
```
would show up at the url above (note the last value on the url is the filter).
Extensions could use the existing alterSettingMetadata hook to add & remove fields from any pages that use the Generic form to choose their settings and extensions could add settings pages by just adding an xml entry & their metadata
We would convert simple forms & for more complex forms we would attempt to break the inheritance on the 2 existing forms (CRM_Admin_Form_Preferences & CRM_Admin_Form_Setting) in favour of using just the CRM_Admin_Form_SettingTrait in an attempt to grandfather them out.https://lab.civicrm.org/dev/core/-/issues/489Contribution reports don't show Custom Field Sets that extend Organizations o...2022-09-07T05:03:51ZguyiacContribution reports don't show Custom Field Sets that extend Organizations or HouseholdsNone of the contribution reports will show any custom field sets that are used explicitly for extending Organization or Household contact types. The same custom field set will show up if you change it in the database to extend All Contac...None of the contribution reports will show any custom field sets that are used explicitly for extending Organization or Household contact types. The same custom field set will show up if you change it in the database to extend All Contacts or Individuals.
I experienced this on a client site running CiviCRm 5.3.1 under WordPress, and tested it on the WordPress Civi master running 5.8.alpha1 at https://wpmaster.demo.civicrm.org/.https://lab.civicrm.org/dev/core/-/issues/477Print Summary is missing some contact info2018-10-29T20:49:47ZJonGoldPrint Summary is missing some contact infoFrom Stack Exchange: https://civicrm.stackexchange.com/q/27063/12
To replicate:
* Open any individual's contact.
* From the "Actions" button, select "Print Summary".
**Expected**
The contact's employer/job title should be in the print...From Stack Exchange: https://civicrm.stackexchange.com/q/27063/12
To replicate:
* Open any individual's contact.
* From the "Actions" button, select "Print Summary".
**Expected**
The contact's employer/job title should be in the print summary.
**Actual**
It's not.
The last line of `<civiroot>/templates/CRM/Contact/Page/View/Print.tpl` is:
```js
cj('#contact-summary' ).children(':first').remove();
```
The reason for this is lost to the ages, but I suspect this referred to some other DOM element that's long since been removed.
Personally I'd deprecate this whole functionality - but apparently folks are using it, so let's make it work.
If someone wants to mark this "concept: approved" I'll submit the PR.5.8https://lab.civicrm.org/dev/core/-/issues/468Missing transaction ids on reports2023-09-10T05:03:24ZfrancescbassasMissing transaction ids on reports**How to reproduce**
1. Create `contributionA` on `contactA` without assigning any *transaction_id*. A record on `civicrm_contribution` is created with `transaction_id = NULL`
2. Modify `contributionA` to assign a *transaction_id = aaaa...**How to reproduce**
1. Create `contributionA` on `contactA` without assigning any *transaction_id*. A record on `civicrm_contribution` is created with `transaction_id = NULL`
2. Modify `contributionA` to assign a *transaction_id = aaaaaa*. The record previously created on `civicrm_contribution` stills have `transaction_id = ǸULL`
3. Create `contributionB` on `contactA` with a *transaction_id = bbbbbb*
4. Visualize a *Contribution Details* report with column *transaction_id* enabled and filtering results for `contactA`
5. Note that *transaction_id* column for `contributionA` is *empty* instead of *aaaaaa* and *transaction_id* column for `contributionB` is *bbbbbb*
Same happens on *Event Participants List* report for event related contributions in which the *transaction_id* was edited a posteriori.