Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-01-21T05:03:40Zhttps://lab.civicrm.org/dev/core/-/issues/1432Wordpress: after 5.19.2 to 5.19.3 upgrade, civicrm_root is miscalculated2023-01-21T05:03:40ZdavejWordpress: after 5.19.2 to 5.19.3 upgrade, civicrm_root is miscalculatedSys admin reports that on two of two Wordpress sites attempted (both on a cPanel server), after the 5.19.2 to 5.19.3 upgrade (which is specifically for a Wordpress path issue), civicrm_root is miscalculated even though it is set correctl...Sys admin reports that on two of two Wordpress sites attempted (both on a cPanel server), after the 5.19.2 to 5.19.3 upgrade (which is specifically for a Wordpress path issue), civicrm_root is miscalculated even though it is set correctly in civicrm.settings.php .
civicrm root in settings file:
```
$civicrm_root = '/home/mysite/public_html/wp-content/plugins/civicrm/civicrm/';
```
However the UI reports e.g.
```
/home/wordpress-5.2.3/wp-content/plugins/civicrm
```
and subsequently the menu css is trying to use https://mysite.org.uk/home/mysite/public_html/wp-content/uploads/civicrm/persist/contribute/dyn/crm-menubar.012442d397c3bdbb78690c18db0cb6eb.css
Rolling back to 5.19.2 resolved the problem.
`/home/mysite/public_html` is a symbolic link to `wordpress` (in the same directory), which may be relevant: perhaps path matching against the real path is failing.https://lab.civicrm.org/dev/core/-/issues/1433CRM_Case_XMLProcessor::allActivityTypes() doesn't do caching right2020-06-16T11:13:35ZDaveDCRM_Case_XMLProcessor::allActivityTypes() doesn't do caching rightThis isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActiv...This isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActivityType($indexName, $all);
}
return self::$activityTypes;
}
```
So it works fine the first time in any given page run, but then if you call it again with different parameters it just returns the thing it cached last time regardless of the parameters. It isn't used very often and so I guess it doesn't come up in a typical page run, but it was driving me a bit nuts while trying to write a unit test and not getting what I was expecting.
PR coming, just debating whether it's worth trying to eliminate completely since it isn't used in that many places, i.e. deprecate it and replace everywhere it's used in core with CRM_Case_PseudoConstant::caseActivityType which does its own caching anyway.5.28.0https://lab.civicrm.org/dev/core/-/issues/1434DB error in Mail Clickthroughs bar chart display2019-12-02T04:47:10ZxurizaemonDB error in Mail Clickthroughs bar chart displayOverview
----------------------------------------
When viewing the Mail Clickthroughs report, the table view works but the bar chart view does not.
Reproduction steps
----------------------------------------
1. Log into demo & view http...Overview
----------------------------------------
When viewing the Mail Clickthroughs report, the table view works but the bar chart view does not.
Reproduction steps
----------------------------------------
1. Log into demo & view https://dmaster.demo.civicrm.org/civicrm/report/instance/35
2. Select "Bar chart" display
3. Click View
Current behaviour
----------------------------------------
Error will read "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."
The SQL which fails is:
```sql
SELECT contact_civireport.id as civicrm_contact_id, contact_civireport.sort_name as civicrm_contact_sort_name, mailing_civireport.name as civicrm_mailing_mailing_name, mailing_civireport.name as civicrm_mailing_mailing_name_alias, email_civireport.email as civicrm_email_email, mailing_trackable_url_civireport.url as civicrm_mailing_trackable_url_url, COUNT(.id) as civicrm_mailing_click_count
FROM civicrm_contact contact_civireport
INNER JOIN civicrm_mailing_event_queue
ON civicrm_mailing_event_queue.contact_id = contact_civireport.id
LEFT JOIN civicrm_email email_civireport
ON civicrm_mailing_event_queue.email_id = email_civireport.id
INNER JOIN civicrm_mailing_event_trackable_url_open mailing_event_trackable_url_open_civireport
ON mailing_event_trackable_url_open_civireport.event_queue_id = civicrm_mailing_event_queue.id
INNER JOIN civicrm_mailing_trackable_url mailing_trackable_url_civireport
ON mailing_event_trackable_url_open_civireport.trackable_url_id = mailing_trackable_url_civireport.id
INNER JOIN civicrm_mailing_job
ON civicrm_mailing_event_queue.job_id = civicrm_mailing_job.id
INNER JOIN civicrm_mailing mailing_civireport
ON civicrm_mailing_job.mailing_id = mailing_civireport.id
AND civicrm_mailing_job.is_test = 0
WHERE ( 1 ) AND mailing_civireport.sms_provider_id IS NULL GROUP BY mailing_civireport.id
```
The error message is:
> 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 ') as civicrm_mailing_click_count
Looks like the culprit is generating `COUNT(.id) as civicrm_mailing_click_count`
Expected behaviour
----------------------------------------
The report should show as a beautiful bar graph.
(I've never seen this bar chart, I'm reporting the issue on behalf of a community user.)
Environment information
----------------------------------------
* __CiviCRM:__ 5.19.3, verified on https://dmaster.demo.civicrm.org/
* __PHP:__ 7.2
* __CMS:__ Drupal 7
* __Database:__ 10.1.43-MariaDB-0ubuntu0.18.04.15.21.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1435Membership and Event Related Contributions - shows all contributions2019-12-05T03:06:22Zaydunsaidan.saunders@squiffle.ukMembership and Event Related Contributions - shows all contributionsOverview
----------------------------------------
When viewing a membership or participant record, the related contributions show *all* contributions, not those related to the membership.
Reproduction steps
-----------------------------...Overview
----------------------------------------
When viewing a membership or participant record, the related contributions show *all* contributions, not those related to the membership.
Reproduction steps
----------------------------------------
1. Go to a contact's Memberships tab. (Or Events tab)
1. Click View on the Membership (Or Event)
Current behaviour
----------------------------------------
Observe that the 'Related Contributions' shows all contributions, not just those related to the membership/event.
Expected behaviour
----------------------------------------
Related Contributions should only show those related to the membership.
Comments
----------------------------------------
This used to work correctly - eg in 5.18.4
The membership view uses CRM_Contribute_Form_Search and passes a `contactId` and `memberId`. The handling of forced searches and the use of `$this->_formValues` in CRM_Contribute_Form_Search and CRM_Core_Form_Search has changed with the result that `memberId` is not passed into the query.
In https://github.com/civicrm/civicrm-core/blob/5.18/CRM/Contribute/Form/Search.php#L108 forced searches are performed after `$this->_formValues['contribution_membership_id']` is set at https://github.com/civicrm/civicrm-core/blob/5.18/CRM/Contribute/Form/Search.php#L101
The forced search is now carried out in `parent::preProcess()`. Retrieving `memberId` from the URL needs to happen somewhere before the query. Note that with the changes to setFormValues(), getFormValues() just assigning to `$this->_formValues['contribution_membership_id']` is not the right approach. The question (probably for @eileen) is what the right approach is now.
The issue applies to `participantId` and events.5.19.4https://lab.civicrm.org/dev/core/-/issues/1436Do not CC or BCC (Event) Contribution invoice2020-02-20T17:40:16Zmagnolia61Do not CC or BCC (Event) Contribution invoiceContribution Invoices were send to CC and BCC email address that were configured only for Event Confirmation purposes.
When sending an invoice to a user it automatically also got send to the CC and BCC email that were configured for Eve...Contribution Invoices were send to CC and BCC email address that were configured only for Event Confirmation purposes.
When sending an invoice to a user it automatically also got send to the CC and BCC email that were configured for Event Confirmation purposes. While these email addresses are in use to let the event leaders know how many participants can be expected and info on their diet etcetera, it is an unexpected and undesired result when sensitive contribution details (payment arrangements etcetera) are automatically send by CC and BCC to these people.
**Configuration in Event**
![Screenshot_from_2019-12-02_16-25-29](/uploads/02934b423041e99dcd27d8bcc5be575a/Screenshot_from_2019-12-02_16-25-29.png)
**UI Screen when sending a contribution invoice**
![Screenshot_from_2019-12-02_16-28-47](/uploads/cde183dc5e233693133a4e98472c3b6a/Screenshot_from_2019-12-02_16-28-47.png)
https://lab.civicrm.org/dev/core/-/issues/1437Creating relationship with start date in future incorrectly shows relationshi...2023-01-17T01:36:45Zellen_compucorpCreating relationship with start date in future incorrectly shows relationship as activeOverview
----------------------------------------
Creating relationship with start date in future incorrectly shows relationship as active
Reproduction steps
----------------------------------------
1. Go to a contact record, then go to...Overview
----------------------------------------
Creating relationship with start date in future incorrectly shows relationship as active
Reproduction steps
----------------------------------------
1. Go to a contact record, then go to the relationships tab
1. Create a new relationship of any type
1. Give the relationship a start date that is in the future
1. Save the new relationship
Current behaviour
----------------------------------------
The relationship is saved correctly, but displays within 'current relationships' in the top half of the relationships tab.
![6AD41E8B-5DD7-4497-84A5-96600B621E9A](/uploads/a43484418ac5b913033190c9e3a52f73/6AD41E8B-5DD7-4497-84A5-96600B621E9A.jpg)
Expected behaviour
----------------------------------------
As the relationship has not yet started, the relationship should show as inactive up until the start date; at which point it should show as current.
Environment information
----------------------------------------
* __Browser:__ Chrome
* __CiviCRM:__ 5.19 (also tested on 5.15 on this test site and contact record: https://civicrm.demo.civihosting.com/civicrm/contact/view?reset=1&cid=98)
* __PHP:__ _7.0
* __CMS:__ Drupal
Comments
----------------------------------------
Contact record from my testing on a demo site: https://civicrm.demo.civihosting.com/civicrm/contact/view?reset=1&cid=98
cc @jamienovick1 @shitijghttps://lab.civicrm.org/dev/core/-/issues/1438when importing contributions, can't match contact on phone number2020-02-17T15:27:10Zjamiewhen importing contributions, can't match contact on phone numberOverview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule ca...Overview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule calls the phone field "phone_numeric" yet the contact list of importable fields lists the field as "phone" - so no match is every made.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Find and Merge Duplicate Contacts**.
1. Click **Add rule for Individuals**.
1. Rule Name: Phone, Used: Unsupervised, Select field Phone and enter weight: 1, Threshhold: 1 and **Save**
1. Click **Contributions -> Import Contributions**
1. Upload any CSV file, choose defaults
1. Click Next
1. See that Phone is not listed in fields to import
Current behaviour
----------------------------------------
When the field mapper screen appears and you have an supervised dedupe rule with a phone field, you get a missing index error, a phantom "match to contact" option in the field list, and the phone field is not listed.
![phone-import-error](/uploads/26b39da7bed124937c3666d4fb275a03/phone-import-error.png)
Expected behaviour
----------------------------------------
The phone field should be listed (with "match to contact").
Environment information
----------------------------------------5.24.0https://lab.civicrm.org/dev/core/-/issues/1439No way to identify 'deceased' contacts when viewing or reporting on relations...2023-01-15T05:03:21Zellen_compucorpNo way to identify 'deceased' contacts when viewing or reporting on relationshipsOverview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, which makes sense overall (for example, if a contact was marked as de...Overview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, which makes sense overall (for example, if a contact was marked as deceased and then a scheduled job were to automatically expire all it's relationships, it would be very manual and annoying to reverse that if 'is_deceased' had been added by accident. However, it would be extremely useful (a) when viewing relationships on contact records and (b) when reporting on relationships, to know whether one of the contacts involved in the relationship is deceased.
Example use-case
----------------------------------------
On a contact record:
1. Create a contact (contact A)
1. Add a relationship to another contact (contact B)
1. Mark contact A as deceased
1. View relationships tab on contact record for contact B
Within reports:
1. Go to create new relationships report (/civicrm/report/instance/5?reset=1&output=criteria)
1. View columns/ filters tabs; no configurations available relating to 'is_deceased'
Current behaviour
----------------------------------------
On a contact record:
- No change to relationship (or relationship display) when one of the contacts is marked as deceased
Within reports:
- As described above
Proposed behaviour
----------------------------------------
On a contact record:
- Propose that - on the relationships tab of the contact record - after the name of the contact that is deceased is added in red "(deceased)" in the same way that it is added next to the main display name at the top of the contact record for a deceased contact currently.
![3DC980F2-DC13-440B-A9D3-6875552B2006](/uploads/fb62f7fa05eeaa9002a9298cff5813d5/3DC980F2-DC13-440B-A9D3-6875552B2006.png)
On reports:
- Propose that a filter is added so that 'deceased' contacts can be excluded from relationships reports
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/1440lineitem smarty variable mismatch in thankyou page2020-09-17T22:57:32Zagileware_pengyilineitem smarty variable mismatch in thankyou pageOverview
----------------------------------------
We recently got this issue while testing [Agileware's eWay payment processor](https://github.com/agileware/au.com.agileware.ewayrecurring).
![eway_thnak-you_page_bug](/uploads/da16ec7938...Overview
----------------------------------------
We recently got this issue while testing [Agileware's eWay payment processor](https://github.com/agileware/au.com.agileware.ewayrecurring).
![eway_thnak-you_page_bug](/uploads/da16ec793821650c7640c3717e4b367f/eway_thnak-you_page_bug.png)
After submitting a contribution, the line items are trying to get line item details from a string instead of an array. This does not happen with other processors, and is not a problem when an explicit price set is used.
Reproduction steps
----------------------------------------
To reproduce this issue, you will need to have the eWay payment processor or a payment processor with `billing_mode = 4` and call `Contribution.completetransaction` during the thankyou page.
1. Open a contribution page, like https://domain/civicrm/contribute/transact?reset=1&id=1
1. Use the mentioned payment processor to complete the form
1. Comfirm and go to thankyou page
Current behaviour
----------------------------------------
The thankyou page shows broken information.
The smarty variable `lineItem` is
```
Array
(
[248] => Array
(
[qty] => 1
[label] => Booster
[unit_price] => 10.00
[line_total] => 10.00
[price_field_id] => 2
[participant_count] => 0
[price_field_value_id] => 4
[field_title] => Contribution Amount
[html_type] => Radio
[description] =>
[entity_id] => 225
[entity_table] => civicrm_contribution
[contribution_id] => 225
[financial_type_id] => 1
[financial_type] => Donation
[membership_type_id] =>
[membership_num_terms] =>
[tax_amount] =>
[price_set_id] => 3
[tax_rate] =>
[subTotal] => 10
)
)
```
Expected behaviour
----------------------------------------
The thankyou page should show the total amount only.
It should not show the lineitem table at all in this case.
However, for lineitem, the expected smarty variable based on [the template](https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Price/Page/LineItem.tpl) is:
```
Array
(
[3] => Array
(
[4] => Array
(
[price_field_id] => 2
[price_field_value_id] => 4
[label] => Booster
[field_title] => Contribution Amount
[description] =>
[qty] => 1
[unit_price] => 10.000000000
[line_total] => 10
[participant_count] => 0
[max_value] =>
[membership_type_id] =>
[membership_num_terms] =>
[auto_renew] =>
[html_type] => Radio
[financial_type_id] => 1
[tax_amount] =>
[non_deductible_amount] => 0.00
)
)
)
```
Environment information
----------------------------------------
* __CiviCRM:__ 5.19.3
* __PHP:__ 7.2
* __CMS:__ Drupal 7.30 and WordPress 5.3
Comments
----------------------------------------
I believe this is a core issue because the eWay payment processor does not create the contribution during this workflow. It calls `Contribution.completetransaction` when it comes to the thankyou page, and that is the critical action that causes the output.
If this is the expected behaviour for Civi, what should the payment processor do?
Agileware ref: CIVIEWAY-144https://lab.civicrm.org/dev/core/-/issues/1441Report ignoring "Campaign is Null"2020-05-13T06:29:53ZCoreyBurgerReport ignoring "Campaign is Null"CiviCRM 5.19.2
I have created an report with a criteria of "Campaign is null", yet the report includes Campaign emails and the Developer tab shows that in any of the where strings, there is no "Campaign is null" or equivalent. See attac...CiviCRM 5.19.2
I have created an report with a criteria of "Campaign is null", yet the report includes Campaign emails and the Developer tab shows that in any of the where strings, there is no "Campaign is null" or equivalent. See attached screenshot and SQL code
![CiviCRMCiviReportBug](/uploads/63791c355d71bc10d84e11b7b4756512/CiviCRMCiviReportBug.png)
[SQLCiviReportBug.txt](/uploads/5b94e502fe817a767cd670d682a18891/SQLCiviReportBug.txt)https://lab.civicrm.org/dev/core/-/issues/1442Use "Active Membership" to describe a "current member" to avoid confusion wi...2022-10-25T21:30:07Zjustinfreeman (Agileware)Use "Active Membership" to describe a "current member" to avoid confusion with the "current" membership statusOverview
----------------------------------------
Use "**Active Membership**" to describe a "current member" to avoid confusion with the "current" membership status. Using the same word for two different meanings is confusing to users a...Overview
----------------------------------------
Use "**Active Membership**" to describe a "current member" to avoid confusion with the "current" membership status. Using the same word for two different meanings is confusing to users and problematic on the screens as the purpose is not explicit.
As being discussed here, https://civicrm.stackexchange.com/questions/33946/search-find-memberships-difference-between-membership-status-current-and-curr/33948
Example use-case
----------------------------------------
1. User wants to find all contacts with membership.
2. Goes to the Find Memberships screen.
3. Unable to decide if they select "membership status = current" or "Current Member? Yes"
4. User selects both options and is shown an **incorrect** list of contacts.
5. The selection has excluded "New" and "Grace" statuses.
Having "**Active Membership**" is a clearer choice in this case.
Current behaviour
----------------------------------------
Same terminology is being used to refer to the membership status and a grouping of multiple membership statuses.
Proposed behaviour
----------------------------------------
Use "**Active Membership**" to describe a "current member" to avoid confusion with the "current" membership status
Screenshots of current situation
----------------------------------------
![chrome_XmRm57E4cR](/uploads/ae20f559b5f222e87a6148b4a3936b76/chrome_XmRm57E4cR.png)
![chrome_8XPF55uH7x](/uploads/dafd5cbb0fa31067cd2b1e6d18ddc82f/chrome_8XPF55uH7x.png)
![chrome_6ieI5PVZOZ](/uploads/8222442650219bedebfeb0ca6eb39f4c/chrome_6ieI5PVZOZ.png)
Agileware Ref: CIVICRM-1388https://lab.civicrm.org/dev/core/-/issues/1443hook_civicrm_post() implementation results in DB Error: already exists for cu...2019-12-10T06:44:32Zjensschuppehook_civicrm_post() implementation results in DB Error: already exists for custom field valuesOverview
----------------------------------------
When an implementation of `hook_civicrm_post()` creates custom field values for a newly created entity (e.g. a contribution), saving the entity results in
> DB Error: already exists
wit...Overview
----------------------------------------
When an implementation of `hook_civicrm_post()` creates custom field values for a newly created entity (e.g. a contribution), saving the entity results in
> DB Error: already exists
with details
> Duplicate entry '123' for key 'unique_entity_id', 1062
with 123 being the entity ID.
Reproduction steps
----------------------------------------
1. Install an extension with an implementation of `hook_civicrm_post()` that creates a custom value for a newly created entity
e.g.:
```php
/**
* Implements hook_civicrm_post().
*/
function test_civicrm_post( $op, $objectName, $objectId, &$objectRef ) {
if ($op=='create' && $objectName=='Contribution') {
civicrm_api3('CustomValue', 'create', array(
'entity_id' => $objectId,
'custom_123' => 'foobar',
));
}
}
```
1. Try to create an entity of that type (UI or API)
1. Notice the error
Environment information
----------------------------------------
CiviCRM >= 5.16.0
Technical background
----------------------------------------
Commit 46fe0a66dc6bfc0fb63bfc0344ea6ff70ca40c8c [added a condition](https://lab.civicrm.org/dev/core/commit/46fe0a66dc6bfc0fb63bfc0344ea6ff70ca40c8c#7c141e5308ec9ecf64d1bff21cb3af527d47cb22_260_264) for the `ON DUPLICATE KEY UPDATE` clause to only be added when the `$parentOperation` is not `'create'`. However, `hook_civicrm_post()` is being invoked before the transaction that creates the entity is committed and without any `$parentOperation`. Thus, the hook implementation is the first to create a record in the respective custom group table. When the entity creation transaction is about to be committed, there already is a record and the `INSERT` clause without `ON DUPLICATE KEY UPDATE` fails with _DB Error: already exists_.
Proposed solution
----------------------------------------
The condition for not adding the `ON DUPLICATE KEY UPDATE` is of course there for a reason. So maybe removing it is not the best solution. My feeling is that `hook_civicrm_post()` should be invoked later, which might not be that easy, since adding custom field values may not apply to all entity types.
Handing down the `$parentOperation` into the hook will not work, since anything can happen in there and the API (as in the example code above) will not respect it anyway.
Comments
----------------------------------------
Maybe there should be an extension in the testing framework that adds this scenario as a test case, so that changes to code that's invoking hooks can be more sensitive in respect to common or known use cases.5.21.0https://lab.civicrm.org/dev/core/-/issues/1444Activities not visible if they have a campaign_id & contact does not have 'ad...2020-01-23T21:20:51ZeileenActivities not visible if they have a campaign_id & contact does not have 'administer CiviCampaign'The activity tab in Civi adds the filter campaign_id = NULL where the contact does not have the 'Administer CiviCRM' permission.
This seems wrong...The activity tab in Civi adds the filter campaign_id = NULL where the contact does not have the 'Administer CiviCRM' permission.
This seems wrong...5.21.0https://lab.civicrm.org/dev/core/-/issues/1445Related / Inherited Memberships: New Relationship added to membership does no...2023-01-23T08:54:21ZkainukRelated / Inherited Memberships: New Relationship added to membership does not copy custom fieldsOverview
----------------------------------------
CiviCRM offers the option to share a membership between a group of contacts. For example the employees of a company or the members of a household. In the databases this is ensured by crea...Overview
----------------------------------------
CiviCRM offers the option to share a membership between a group of contacts. For example the employees of a company or the members of a household. In the databases this is ensured by creating a copy of each membership record. On of them is the parent record, the interface allows to change it. Alle the properties are subsequently copied to the other membership records.
A membership can have customfields, and these are copied as well (in the near future after the merge of https://github.com/civicrm/civicrm-core/pull/15884).
When a new contact is added to the group, by creating the new relationship, a new copy of the membership is created. However the creation of the corresponding custom fields is ommited.
Reproduction steps
----------------------------------------
The bug can reproduced on a copy of the dmaster database 5.21.alpha1
1. Install https://github.com/civicrm/civicrm-core/pull/15884)
1. Create a new Household Membership Membership. Add the following to relationships to the membership. _Head of Household_ is and _Household Member is_
![bug01](/uploads/5ac404bc504217bc7e42207cdb8d4221/bug01.png)
1. Create a custom field that is valid for this membership:
![bug02](/uploads/1e961bca40e0ff198ba53377d9ca19a1/bug02.png)
1. Make the Grant family a member. Fill the custom field with a value. The membership is copied nicely to all the Grant Children and parents. In the records there is copy of the custom value.
1. Now add a new Relationship with the type Household Member (Of if see the need a second Head of the Household). Create a in the process, and name it Luke Grant
Current behaviour
----------------------------------------
Go the contact card of Luke Grant and inspect is membership. The custom field is empty:
![bug03](/uploads/a6da7ce5622b77e543ceaa13101783e8/bug03.png)
Expected behaviour
----------------------------------------
The custom field should have the same value as the parent membership.
Comments
----------------------------------------
The issue is related to https://lab.civicrm.org/dev/core/issues/1365https://lab.civicrm.org/dev/core/-/issues/1446Find Activities search has no link to return to search results2023-01-16T05:03:34ZandyburnsFind Activities search has no link to return to search resultsIf you run Find Activities Search and click on the Name of the Contact, when you get to the Contact Summary Screen and do whatever it was you meant to do, there is no way to Return To the Search Results of the Find Activities Search, lik...If you run Find Activities Search and click on the Name of the Contact, when you get to the Contact Summary Screen and do whatever it was you meant to do, there is no way to Return To the Search Results of the Find Activities Search, like there is in Advanced Search. You have to rerun the Find Activities Search if you want to continue reviewing the selected records.
Find Activities Search:
![no_return_to_search_results](/uploads/7837e790055427f3db3b6b4a902697c0/no_return_to_search_results.PNG)
Advanced Search:
![search-results-link](/uploads/a6a308144f95216548f8e56e34d7b3d0/search-results-link.PNG)
There is also no `previous` or `next` paging when on the contact summary screen.https://lab.civicrm.org/dev/core/-/issues/14475.21-RC upgrade fails if there are similar-named Option Groups2019-12-07T18:07:08Zbgm5.21-RC upgrade fails if there are similar-named Option GroupsOn civicrm.org we ran into a fatal error due to:
```
CRM_Upgrade_Incremental_php_FiveTwentyOne::fixOptionGroupName()
```
Error message:
```
UPDATE civicrm_option_group SET name = 'numeric_rating' WHERE ( civicrm_option_group.id =...On civicrm.org we ran into a fatal error due to:
```
CRM_Upgrade_Incremental_php_FiveTwentyOne::fixOptionGroupName()
```
Error message:
```
UPDATE civicrm_option_group SET name = 'numeric_rating' WHERE ( civicrm_option_group.id = 357 )
[nativecode=1062 ** Duplicate entry 'numeric_rating' for key 'UI_name']
```
Pre-upgrade data:
```
> select * from civicrm_option_group where name like '%numeric%';
+-----+-------------------------------+----------------+----------------------------+-------------+-----------+-----------+-----------+
| id | name | title | description | is_reserved | is_active | is_locked | data_type |
+-----+-------------------------------+----------------+----------------------------+-------------+-----------+-----------+-----------+
| 357 | Numeric Rating | Numeric Rating | numeric rating from 1 to 5 | 1 | 1 | 0 | Integer |
| 358 | numeric_rating | Numeric Rating | NULL | 1 | 1 | 0 | Integer |
| 359 | numeric_rating_20171003141125 | Numeric rating | NULL | 0 | 1 | 0 | String |
+-----+-------------------------------+----------------+----------------------------+-------------+-----------+-----------+-----------+
```
To make matters worse, the id=357 group does not have an option values. I have no idea where it's used. (and exists from before enabling detailed-log, 2019-02)
Nonetheless, I feel like this should require a pre-upgrade check?
cc @seamuslee5.21.0https://lab.civicrm.org/dev/core/-/issues/1448Upgrade - confirm navigation away from page2023-01-15T05:03:23ZarborrowUpgrade - confirm navigation away from pageSo yesterday, I had one of those moments where I just wanted to kick myself while upgrading CiviCRM. I had fired off the database upgrade (civicrm/upgrade?reset=1) and saw a bunch of notices related to templates which I copied for docume...So yesterday, I had one of those moments where I just wanted to kick myself while upgrading CiviCRM. I had fired off the database upgrade (civicrm/upgrade?reset=1) and saw a bunch of notices related to templates which I copied for documentation purposes while the database upgrade continued.
I intended to switch over to a new browser tab and paste the documentation into a document there when before I new it I had migrated away from the upgrade page abandoning the upgrade mid-process. Hoping against hope, I went back and thought perhaps it might be able to pickup where it left off. No such luck. The installation had been interrupted and it was suggested that I restore my backup (which of course I hadn't done because well I never have these sorts of troubles :p) and then try the upgrade process again.
I suspect I am not the first to do this but believe it would be a good idea to add some type of confirmation button on the database upgrade page to save me from myself and make it one step harder to interrupt the upgrade process with a "are you sure you want to continue to interrupt the database upgrade". It just seems a little too easy to interrupt this crucial process.
I was thinking something along the lines of: https://code-maven.com/prevent-leaving-the-page-using-plain-javascripthttps://lab.civicrm.org/dev/core/-/issues/14495.20 Upgrade fails when CiviCase is enabled and you have an extension that ca...2019-12-09T20:42:09Zseamuslee5.20 Upgrade fails when CiviCase is enabled and you have an extension that calls hook_civicrm_pre/post and the hook function uses a class within the extensionOverview
----------------------------------------
5.20 Upgrade fails if you use an extension e.g. mailchimp extension and you have CiviCase enabled and you have a case type created that will be affected by the upgrade
Reproduction steps...Overview
----------------------------------------
5.20 Upgrade fails if you use an extension e.g. mailchimp extension and you have CiviCase enabled and you have a case type created that will be affected by the upgrade
Reproduction steps
----------------------------------------
1. Create a case type with the roles of Benefit Specilalist, Spouse of, and Case Coordinator
1. Install mailchimp extension latest version
1. Try running the upgrade in the UI
1. Upgrade stops after the CiviCase label step and doesn't progress and see a PHP error about missing class.
Expected behaviour
----------------------------------------
Upgrade works
Environment information
----------------------------------------
* __CiviCRM:__ _5.20.0_
* __PHP:__ _7.2__
* __CMS:__ _Drupal 7.30_5.20.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1453DB Error from CRM_Contact_BAO_Contact::triggerInfo when enabling/disabling ex...2023-01-17T05:03:31ZcolemanwDB Error from CRM_Contact_BAO_Contact::triggerInfo when enabling/disabling extensionsI just switched to a new localhost with a bleeding-edge LAMPP stack:
- PHP 7.3.11
- MariaDB 10.4.8
- Apache 2.4.41
I was able to setup buildkit and install a site, but when enabling/disabling an extension I get: `DB Error: unknown erro...I just switched to a new localhost with a bleeding-edge LAMPP stack:
- PHP 7.3.11
- MariaDB 10.4.8
- Apache 2.4.41
I was able to setup buildkit and install a site, but when enabling/disabling an extension I get: `DB Error: unknown error` bubbling up from `Civi\Core\SqlTriggers->rebuild()`. The offending query is `"DROP FUNCTION IF EXISTS civicrm_strip_non_numeric"` called by `CRM_Contact_BAO_Contact::triggerInfo`.
"Unknown error" isn't much to go on so I'm posting this to see if anyone has encountered this as well. If my ~~theory~~ hunch is right then it's due to my newer-than-recommended MariaDB version.
So far I've tried removing the `DROP FUNCTION` query and having it just do the subsequent `CREATE FUNCTION` (I appended `IF EXISTS`) but that too crashes with "unknown error".https://lab.civicrm.org/dev/core/-/issues/1455Contribution tab sort by Type column not working with db error2019-12-08T21:33:03ZStoobContribution tab sort by Type column not working with db errorWhen clicking Type to sort by Financial Type in the Contributions tab, a Network Error occurs. "Database Error Code: Column 'financial_type_id' in order clause is ambiguous, 1052"
**The full error is attached.**[type-error.txt](/upload...When clicking Type to sort by Financial Type in the Contributions tab, a Network Error occurs. "Database Error Code: Column 'financial_type_id' in order clause is ambiguous, 1052"
**The full error is attached.**[type-error.txt](/uploads/a3e2347b0dfa04c24fa7c68783a892aa/type-error.txt)
![type](/uploads/683755c044a7cb017d3bcc09b20ad355/type.png) <--- this button
The error began after the update from 5.13 to 5.19, and version currently in use is 5.19.4.5.20.0