Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-02-09T05:03:20Zhttps://lab.civicrm.org/dev/core/-/issues/3533Rewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.2024-02-09T05:03:20ZtottenRewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`...## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`, `extern/rest.php`, or `extern/cxn.php`. More broadly, *all test suites and CLI processes* use a standalone bootstrap script. (These entry-points are distinct from the front-end entry-points typically associated with the UI.)
There are a number of technical details and happenstance we can go into, but there are two fundamental nubs in writing and executing a standalone script:
* *It doesn't know which CMS is active.* There's usually some *hard-coding* to the find the CMS.
* *Bootstrapping the CMS adds overhead.* Many admins have written-off this consideration as cost of doing business - but for someone, somewhere, at some point it mattered.
## Background: `civicrm.config.php` protocol
The original protocol for standalone bootstrap originated many years ago (circa 1.x or 2.x?). It's still used in several cases. It's key design elements:
* `civicrm.config.php` is *generated* at build-time to match the CMS. The tarball/zipball for each CMS includes a different build of this file. It's main purpose is to locate `civicrm.settings.php`.
* `civicrm.settings.php` includes a `define` for the `CIVICRM_UF` (among many others).
* `CRM_Utils_System::*` includes functions like `loadBootStrap()`.
* __Original protocol__: A standalone script would include `civicrm.config.php`, which would locate the `civicrm.settings.php` using a CMS-specific search. It then boots Civi by loading `civicrm.settings.php` and calling `CRM_Core_Config::singleton()`. Optionally, it also boots the CMS by calling `CRM_Utils_System_*::loadBootStrap()`.
The original boot protocol has some major consequences -- for example:
1. It requires creating an extra settings file (`civicrm.settings.php`) on every build.
2. Depending on how the page-load starts, the Civi settings file and CMS settings may load in different orders. It's not valid to infer Civi settings based on CMS settings (and vice-versa).
3. You need to figure the *absolute or relative* path of `civicrm.config.php`. This is *possible* in `civicrm-core` -- but it's basically impossible with any other publishable deliverable.
4. Reading/understanding the boot protocol requires having multiple builds of Civi (one for each CMS) -- *that's the only way to see each version of `civicrm.config.php`.
## Background: `cv` bootstrap protocol
A few years ago, I combined the various `civicrm.config.php` files with the aim of producing a universal boot script that solved `#3` and `#4`. This produced https://github.com/civicrm/cv/blob/master/src/Bootstrap.php which eventually became the heart of the `cv` command. This endeavor preserved a bunch of assumptions from the original protocol... but it made a key change: *dynamically discovering* the boot info.
The dynamic discovery works a bit like this:
* Do a file-system search (from PWD) to figure out the CMS.
* Do a file-system search (from CMS dir) to figure out where `civicrm.settings.php` is.
* Unless... you really want a faster bootstrap. Then you can set an environment variable with your boot info (and bypass the searches).
IMHO, dynamic CMS discovery (with optional env-var for optimization) is a pretty good way to make the code more robust to deploying in a variety of environments and file-structures.
There's just one problem: the *implementation* grew out of `civicrm.config.php` and kept some of the assumptions, so the implementation still shares issues `#1` and `#2`.
## Proposal: Provide a universal, CMS-first bootstrap script -- and knock over some dominoes
The basic idea is to write a CLI helper which bootstraps the CMS first -- and then bootstraps Civi. The logic is roughly:
```php
function boot($startDir) {
$parentDirectories = array($startDir, parent($startDir), grandparent($startDir), ...);
foreach ($parentDirectories as $dir)
if ($dir has Drupal) { bootDrupal(); bootCivi(); return; }
elseif ($dir has Joomla) { bootJoomla(); bootCivi(); return; }
elseif ($dir has WordPress) { bootWordPress(); bootCivi(); return; }
elseif ($dir has Backdrop) { bootBackdrop(); bootCivi(); return; }
}
}
```
This helper still provides standalone bootstrap, so we can still have all our standalone scripts/unit-tests/commands/etc. But it makes a fundamental change:
* **You can always rely on having the CMS bootstrapped first**.
* Therefore, you can detect things like `CIVICRM_BASEURL` using CMS API's -- because they're always available.
* Therefore, you don't need `civicrm.settings.php` to store those settings.
* Therefore, you don't need `install/index.php` to create `civicrm.settings.php`.
* Therefore, you don't need write-access to create `civicrm.settings.php` (in the typical case).
* Therefore, you don't need to migrate or preserve `civicrm.settings.php` (in the typical case).
*Note: Of course, the entire CiviCRM install-base currently uses `civicrm.settings.php`, and some of them use it to accomplish special ends (like custom multidomain/multisite/multitenant arrangements). Therefore, I wouldn't argue for complete removal of the file -- but, instead, it should be an optional/advanced thing.*
## General Tasks
* Write the new bootstrap script.
* Phase-in the new bootstrap script for use by `cv` and `civicrm-core`.
* Update `civicrm-core` to compute values for all those constants (`define('CIVICRM_FOO',...)`) at runtime using CMS functions.
* Update the installer to omit `civicrm.settings.php`
* Update docs to describe the advanced/optional use of `civicrm.settings.php`.https://lab.civicrm.org/dev/core/-/issues/3554On 'New Mailing' review page, it doesn't show recipients count2022-06-11T14:50:56ZMonish DebOn 'New Mailing' review page, it doesn't show recipients countSimply visit the second page of `New Mailing` and you will notice that 'Recipients' section has an inappropriate message instead of recipient count.
## Context
This appears to be a regression in 4.7.31. Related PR - https://github.com/...Simply visit the second page of `New Mailing` and you will notice that 'Recipients' section has an inappropriate message instead of recipient count.
## Context
This appears to be a regression in 4.7.31. Related PR - https://github.com/civicrm/civicrm-core/pull/110915.0.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/5CiviMail Mailing Accounts allow duplicate names, but breaks processing.2023-06-23T17:54:21ZjohnffCiviMail Mailing Accounts allow duplicate names, but breaks processing.If two CiviMail Mailing Accounts have the same name, even if they have different roles, only the first will be used in either case.
The offending line of code is somewhere in the path of: CRM_Utils_Mail_EmailProcessor::_process -> CRM_M...If two CiviMail Mailing Accounts have the same name, even if they have different roles, only the first will be used in either case.
The offending line of code is somewhere in the path of: CRM_Utils_Mail_EmailProcessor::_process -> CRM_Mailing_MailStore::getStore.
To replicate (Drupal, 4.7.27):
1. Create two mailing accounts.
The first one should be "Email to Activity" and have no username / password settings
The second should be "Bounce processing" and have username / password settings
(order of creation is important, and give them both the same name)
2. Run the scheduled job "fetch bounces".
3. In watchdog, observe the error "could not connect" using the credentials of email to activity processor, even though it should use the Bounce Processing one.
4. Clear the watchdog logs.
5. Rename them to have different names, then retry
6. Check the watchdogs, and observe no error.https://lab.civicrm.org/dev/core/-/issues/14Creating a relationship fails for an organization contact which has NULL valu...2023-06-23T17:54:21ZEvanCreating a relationship fails for an organization contact which has NULL values in start/end/join fields of a membershipWhen creating a relationship between an Individual and an Organizational contact, the relationship fails to be created and throws the following error if the Organizational contact record has a membership with NULL values in the start/end...When creating a relationship between an Individual and an Organizational contact, the relationship fails to be created and throws the following error if the Organizational contact record has a membership with NULL values in the start/end/join fields, such as might happen if a payment failed and the membership was created in a "Pending" state:
`unknown relationship create error The membership cannot be saved because the status cannot be calculated for start_date: null end_date null join_date null as at 2018-03-09 16:43:22`
What's odd is that I wouldn't expect the relationships to be dependent on a membership object, but for some reason it is? I did some testing on a client's sandbox site and found that any membership with NULL start/end/join dates will cause a Relationship creation to fail. I found that deleting the membership with NULL dates fixes the issue i.e. allows the relationship to be created, as does simply adding dates to the membership in question.
**Backtrace:**
`Mar 09 16:43:23 [info] $backTrace = #0 /var/www/example.org/htdocs/sites/all/modules/civicrm/CRM/Core/Error.php(456): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/example.org/htdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(55): CRM_Core_Error::handleUnhandledException(Object(CRM_Core_Exception))
#2 /var/www/example.org/htdocs/sites/all/modules/civicrm/drupal/civicrm.module(345): CRM_Core_Invoke::invoke((Array:4))
#3 [internal function](): civicrm_invoke("contact", "view", "rel")
#4 /var/www/example.org/htdocs/includes/menu.inc(350): call_user_func_array("civicrm_invoke", (Array:3))
#5 /var/www/example.org/htdocs/index.php(17): menu_execute_active_handler()
#6 {main}`
**NB:** I am unable to manually re-create this scenario on the demo site (I tried) as a start date is required when creating a membership.https://lab.civicrm.org/dev/core/-/issues/3312A Contact with a Pending membership cannot be merged with another Contact due...2022-04-22T16:16:45Zjustinfreeman (Agileware)A Contact with a Pending membership cannot be merged with another Contact due to missing membership End DateA Contact with a Pending membership cannot be merged with another Contact due to missing membership End Date.
The membership End Date is not set on a pending membership.
The sequence of events is:
1. Contact signs up for new membership
...A Contact with a Pending membership cannot be merged with another Contact due to missing membership End Date.
The membership End Date is not set on a pending membership.
The sequence of events is:
1. Contact signs up for new membership
1. Contact already exists in CiviCRM (as a non-member) - or is similar contact
1. CiviCRM Admin tries to merge the two Contacts
1. The generic: DB Error: unknown error is then raised
Copy of error from CiviCRM logs.
```
Dec 06 12:32:20 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => UPDATE civicrm_membership SET end_date = '' WHERE id=281 [nativecode=1292 ** Incorrect date value: '' for column 'end_date' at row 1]
[type] => DB_Error
[user_info] => UPDATE civicrm_membership SET end_date = '' WHERE id=281 [nativecode=1292 ** Incorrect date value: '' for column 'end_date' at row 1]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="UPDATE civicrm_membership SET end_date = '' WHERE id=281 [nativecode=12
92 ** Incorrect date value: '' for column 'end_date' at row 1]"]
)
```
Agileware Ref: CIVICRM-1122https://lab.civicrm.org/dev/core/-/issues/689Problem with postponed payment of a contribution in civicrm 5.8.22022-11-13T05:03:53ZjohansProblem with postponed payment of a contribution in civicrm 5.8.2These are the steps to see the problem:
1) I add a contribution with status "Pending" (contribution_status_id 2) and save it and close.
2) Then I open it and set it as "Completed" and save it.
3) At this point if I open it again and edi...These are the steps to see the problem:
1) I add a contribution with status "Pending" (contribution_status_id 2) and save it and close.
2) Then I open it and set it as "Completed" and save it.
3) At this point if I open it again and edit the payment details I am unable to save it: it just circles on forever.
Looking into the civicrm_financial_trxn table I find that the field "payment_instrument_id" is NULL. If I set it as one of the possible ids and repeat step 3 above it saves the record correctly.
Can anyone else verify? Is it a bug?
I just have a plain install of civicrm 5.8.2 with drupal 7.61.https://lab.civicrm.org/dev/drupal/-/issues/8Problem: How to address Bower dependencies installable via `composer`2020-07-16T17:23:37ZtottenProblem: How to address Bower dependencies installable via `composer`D8 General Availabilityhttps://lab.civicrm.org/dev/core/-/issues/8Fatal error on Print/Merge Document for Cases2023-06-23T17:54:21Zaydunsaidan.saunders@squiffle.ukFatal error on Print/Merge Document for Cases* Go to Search Cases
* Select cases
* Select Print/merge Document from Actions menu
* Result is fatal error
Possibly related to https://issues.civicrm.org/jira/browse/CRM-21382
Reproduced on dmaster.demo
```
Array
(
[callback] =>...* Go to Search Cases
* Select cases
* Select Print/merge Document from Actions menu
* Result is fatal error
Possibly related to https://issues.civicrm.org/jira/browse/CRM-21382
Reproduced on dmaster.demo
```
Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -19
[message] => DB Error: no such field
[mode] => 16
[debug_info] =>
SELECT contact_id
FROM civicrm_case
WHERE id IN ( 1,4 )
[nativecode=1054 ** Unknown column 'contact_id' in 'field list']
[type] => DB_Error
[user_info] =>
SELECT contact_id
FROM civicrm_case
WHERE id IN ( 1,4 )
[nativecode=1054 ** Unknown column 'contact_id' in 'field list']
[to_string] => [db_error: message="DB Error: no such field" code=-19 mode=callback callback=CRM_Core_Error::handle prefix="" info="
SELECT contact_id
FROM civicrm_case
WHERE id IN ( 1,4 )
[nativecode=1054 ** Unknown column 'contact_id' in 'field list']"]
)
```5.0.0https://lab.civicrm.org/dev/translation/-/issues/8Multilingual installation with logging enabled gives error when custom field ...2020-07-14T14:56:53ZtbuytaerMultilingual installation with logging enabled gives error when custom field is changedLogging of custom fields on a multilingual installation does not work, which makes it impossible to view changes if one of the changes is a custom field.
Steps to reproduce:
1. install a fresh CiviCRM installation: 5.0 (the issue also ...Logging of custom fields on a multilingual installation does not work, which makes it impossible to view changes if one of the changes is a custom field.
Steps to reproduce:
1. install a fresh CiviCRM installation: 5.0 (the issue also existed in versions before)
2. enable **Multiple Languages Support** on http://example.org/civicrm/admin/setting/localization?reset=1
3. enable **logging** on http://example.org/civicrm/admin/setting/misc?reset=1
4. change a custom field of a contact
5. view the changelog of that contact and click on the change
This results in follwing Database error:
> Database Error Code: Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist, 1146
> Additional Details:
> Array
> (
> [callback] => Array
> (
> [0] => CRM_Core_Error
> [1] => handle
> )
>
> [code] => -18
> [message] => DB Error: no such table
> [mode] => 16
> [debug_info] => SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]
> [type] => DB_Error
> [user_info] => SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]
> [to_string] => [db_error: message="DB Error: no such table" code=-18 mode=callback callback=CRM_Core_Error::handle prefix="" info="SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]"]
> )
*I replaced the actual database name with 'databasename' in the error message above*https://lab.civicrm.org/dev/financial/-/issues/8Proposal - Invoices - Add 'Payment received with thanks' to invoices for comp...2018-11-09T21:46:48Zellen_compucorpProposal - Invoices - Add 'Payment received with thanks' to invoices for completed contributions**Current:** Although the invoice amount due is £0.00 on a completed contribution invoice, clients have reported that it can be confusing to their customers and that it would be beneficial to add messaging to indicate no further payment ...**Current:** Although the invoice amount due is £0.00 on a completed contribution invoice, clients have reported that it can be confusing to their customers and that it would be beneficial to add messaging to indicate no further payment is needed.
**Proposed:** Add ‘Payment received with thanks’ as below:
[image__3_.webp](/uploads/b1c8f9527f6ac2e218f3d282a012cf11/image__3_.webp)https://lab.civicrm.org/dev/wordpress/-/issues/8Feature Request: Add AJAX Job Running2020-03-20T13:07:14ZGhost UserFeature Request: Add AJAX Job RunningOther OSS Projects like OwnCloud support AJAX based http job processes it would be nice if CiviCRM could add this for atleast some of the job as setting up 15 cron jobs or WPI CLI calls is a lot especially with how much time already goes...Other OSS Projects like OwnCloud support AJAX based http job processes it would be nice if CiviCRM could add this for atleast some of the job as setting up 15 cron jobs or WPI CLI calls is a lot especially with how much time already goes into configuring and maintaining CiviCRMhttps://lab.civicrm.org/dev/joomla/-/issues/8Navigation Menu Lost2019-02-12T18:34:28ZGhost UserNavigation Menu LostI received an update alert in the "Summary Fields" plugin. The Admin Navigation Menu has disappeared after updating. Now I get an error when I tell you to disable the plugin. The problem is that it disables other plugins. But he's giving...I received an update alert in the "Summary Fields" plugin. The Admin Navigation Menu has disappeared after updating. Now I get an error when I tell you to disable the plugin. The problem is that it disables other plugins. But he's giving error to Summary Fields.
There was no improvement in the problem I did with the cache and bus clearance. I'm using CiviCRM 5.9.1 when I do. I upgraded to 5.10.0, but the problem still has not improved.
Joomla 3.9.2
CiviCRM 5.10.0![-001233](/uploads/faabeb47f8d5209c8eb82fe4395a7da7/-001233.png)
![-001235](/uploads/860b8d52d93de7a306deb3049b4b6dbf/-001235.png)https://lab.civicrm.org/dev/release/-/issues/8D8 composer installation method for ESR versions2021-09-21T21:01:40ZjackrabbithannaD8 composer installation method for ESR versionsSince only those folks that chip in and pay into the ESR problem have access to the CiviCRM ESR tarballs, there should be a composer based method that will always provide "the latest ESR release" ..
IDK how this can be done. Will CiviCR...Since only those folks that chip in and pay into the ESR problem have access to the CiviCRM ESR tarballs, there should be a composer based method that will always provide "the latest ESR release" ..
IDK how this can be done. Will CiviCRM need a private packagist account that people that pay into the ESR can use to composer require the ESR version?
If CT ends up not providing a ESR composer method ... Skvare may provide a how-to for how to :
1) install the latest ESR version, and a process for updating the ESR version ...
Target for this should be ESR 5.13, which I believe will be the next ESR?https://lab.civicrm.org/dev/user-interface/-/issues/8Create New Donation Form Option with Better Design2022-11-08T22:36:19ZroshaniCreate New Donation Form Option with Better Design[Improvements_to_CiviCRM_Donation_Forms.docx](/uploads/13d08f094f6ecde376bf84304daaec6e/Improvements_to_CiviCRM_Donation_Forms.docx)
Improvements to CiviCRM Donation Forms
1. Convert Donation Amounts location and styling
- Change the d...[Improvements_to_CiviCRM_Donation_Forms.docx](/uploads/13d08f094f6ecde376bf84304daaec6e/Improvements_to_CiviCRM_Donation_Forms.docx)
Improvements to CiviCRM Donation Forms
1. Convert Donation Amounts location and styling
- Change the donation amount radio buttons from radio buttons to buttons with donation amounts
- Move the donation amounts below One-Time and Monthly buttons
https://ccrjustice.org/donate?track1=website&track2=wheader&track3=2016-DEC-16
Give a donation in the Amount of:
$100.00
$250.00
$500.00
$1,000.00
$5,000.00
Other Amount
2. One-Time & Monthly Donation Buttons
1. Add One-Time & Monthly Buttons above the donation amounts
Current CiviCRM Example:
Currently there is a checkbox for creating a recurring donation. Also note that donation amounts appear as radio buttons above the recurring options.
https://ccrjustice.org/donate?track1=website&track2=wheader&track3=2016-DEC-16
I want to join the CCR Justice Sustainers and contribute this amount every month
Monthly giving provides reliable funding which allows CCR to plan, leverage and allocate resources in a way that means more hope for our clients, more support for movements, more justice and accountability.
Examples:
https://secure.humanesociety.org/site/Donation2;jsessionid=00000000.app325b https://action.aclu.org/give/now
2. If someone selects Monthly, it will change the donation amounts shown.
3. Default will be One-Time donation button option.https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/8New D8 install, add CiviCRM, seems to work but the Civi menu is missing.2020-07-26T12:37:44ZHeneryHNew D8 install, add CiviCRM, seems to work but the Civi menu is missing.I installed a new D8 site and then added some modules including:
composer require civicrm/civicrm-{core,packages,drupal-8}:dev-master
composer require civicrm/civicrm-asset-plugin
when I enable the civi module and navigate to some civi ...I installed a new D8 site and then added some modules including:
composer require civicrm/civicrm-{core,packages,drupal-8}:dev-master
composer require civicrm/civicrm-asset-plugin
when I enable the civi module and navigate to some civi URLs manually they seem to work but my Civi menu is missing when I click on the CiviCRM button.
Any ideas or seen this before?
Thanks
![Screen_Shot_2020-07-10_at_7.53.31_PM](/uploads/34039d7f76138da8f8d8323228224e67/Screen_Shot_2020-07-10_at_7.53.31_PM.png)https://lab.civicrm.org/dev/core/-/issues/3239Contribution reports don't include thank-you date2022-04-22T15:51:49ZJonGoldContribution reports don't include thank-you dateThis is an issue that a couple of people have noted [on Stack Exchange](https://civicrm.stackexchange.com/questions/15374/thank-you-letter-report/15377). However, this is the first time anyone has paid me to fix it :) PR incoming.This is an issue that a couple of people have noted [on Stack Exchange](https://civicrm.stackexchange.com/questions/15374/thank-you-letter-report/15377). However, this is the first time anyone has paid me to fix it :) PR incoming.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3302Add accessible fieldset for checkboxes and radio buttons2023-11-28T12:49:35ZMonish DebAdd accessible fieldset for checkboxes and radio buttonsAs per https://www.w3.org/WAI/tutorials/forms/grouping , grouped form controls like radio buttons/checkboxes must be enclosed in ```<fieldset>``` and the ```<legend>``` element act as a header to identify the group of elements. Currently...As per https://www.w3.org/WAI/tutorials/forms/grouping , grouped form controls like radio buttons/checkboxes must be enclosed in ```<fieldset>``` and the ```<legend>``` element act as a header to identify the group of elements. Currently, when we review such block with WAVE accessibility tool, it complains about:
![Screen_Shot_2018-06-01_at_6.53.18_PM](/uploads/0782446dde4a776d6ec4a8f5c51edf47/Screen_Shot_2018-06-01_at_6.53.18_PM.png)
## Proposal
1. Enclose the checkbox/radio button block in a fieldset
2. Add a special class to that fieldset say `crm-sr-fieldset` which hides it in front-end forms (public and backoffice forms)
3. Use label of checkbox/radio buttons as its legend header.
Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3329Inherited memberships not created correctly when contact count changes.2022-04-22T16:17:19Zsamknelson@gmail.comInherited memberships not created correctly when contact count changes.(Migrating this issue from https://issues.civicrm.org/jira/browse/CRM-21463, since it's been idle there for over a year.)
Suppose you have an organization membership. Suppose the organization has 4 related contacts, each of whom inheri...(Migrating this issue from https://issues.civicrm.org/jira/browse/CRM-21463, since it's been idle there for over a year.)
Suppose you have an organization membership. Suppose the organization has 4 related contacts, each of whom inherits the membership.
Suppose you then add a related contact.
Suppose you then renew the membership.
The newly related contact does not receive the inherited membership. In fact, each time you save / update the membership, an apparently random set of 4 related contacts receives the inherited membership.
============
This turns out to be a bug in Member/BAO/Membership.php. At line 1445, we see
if ($relMembership->find(TRUE)) {
$params['id'] = $relMemIds['membership'] = $relMembership->id;
}
However, params['id'] is never initialized, so if some related memberships are not found, they are assigned the ID from the last iteration through the loop – meaning the previous contact loses their membership.
The solution is to add $params['id'] = NULL right before. (It would probably be better to set $params = NULL at the beginning of the loop, but I haven't tested that.)
I haven't submitted a patch, but it should be straightforward.5.31.0https://lab.civicrm.org/dev/core/-/issues/3525Move example data to an optional/add-on step2024-02-07T05:03:27ZtottenMove example data to an optional/add-on stepDuring installation, the installer shows a checkbox which asks whether you want to load sample data. Then:
* If you don't want sample data, it loads `sql/civicrm_data.mysql`.
* If you do want sample data, it loads `sql/civicrm_generat...During installation, the installer shows a checkbox which asks whether you want to load sample data. Then:
* If you don't want sample data, it loads `sql/civicrm_data.mysql`.
* If you do want sample data, it loads `sql/civicrm_generated.mysql`.
This has some consequences:
* You must choose whether to load sample data during *installation*. This is presented in the installer UI.
* The `civicrm_generated.mysql` takes extra work to maintain (eg `bin/regen.sh`; the output of which is not merge-friendly).
The goal here would be to have one *installation* process -- which could be headless. *Afterwards*, you should have the *option* to enable create the sample data. This *option* may be specified as at same time as other install parameters (eg via arg) or perhaps via a separate command afterwards.https://lab.civicrm.org/dev/core/-/issues/3582Using ACL to restrict mailing recipients leads to fatal error2022-06-11T14:54:50ZMonish DebUsing ACL to restrict mailing recipients leads to fatal errorSteps to replicate:
1. Assign an ACL permission for one or more contacts
2. Compose a mailing and select a recipient group. Ensure that those contacts are included in that group
3. Submit and Send Mailing immediately
Result into fatal ...Steps to replicate:
1. Assign an ACL permission for one or more contacts
2. Compose a mailing and select a recipient group. Ensure that those contacts are included in that group
3. Submit and Send Mailing immediately
Result into fatal error - https://pastebin.com/aMa2KYy0
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://github.com/civicrm/civicrm-core/pull/11142/
5.1.0Monish DebMonish Deb