CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-09-13T05:03:46Zhttps://lab.civicrm.org/dev/core/-/issues/107After creating a new case, the assignee for each activity must be selected ma...2022-09-13T05:03:46ZreneolivoAfter creating a new case, the assignee for each activity must be selected manually### Issue
After you create a new case multiples activities are created with it, but the assignee must be manually chosen for each one of them which takes considerable time since this must be done by editing each activity one at a time.
...### Issue
After you create a new case multiples activities are created with it, but the assignee must be manually chosen for each one of them which takes considerable time since this must be done by editing each activity one at a time.
![default-assignee-issue](/uploads/987455f62441d6f77bc1892b930b4a90/default-assignee-issue.png)
There are references for the roles and relationships that are interesting for the particular case, but those are there for reference, the assignee still must be selected manually.
### Solution
Allow administrators to define rules for selecting a default assignee for each one of the activities. The rules would be based on the following options:
* By relationship to case client (ex: parent, manager, or spouse of case client).
* User creating the case.
* Specific contact.
* No default assignee.
When creating a new case each case activity should be created and assigned based on these rules. The case manager could then modify the assignees as usual.
----
Core PR:
https://github.com/civicrm/civicrm-core/pull/11998https://lab.civicrm.org/dev/core/-/issues/108unable to create new event location without impacting other events2018-07-12T14:34:52Zlcdwebunable to create new event location without impacting other eventsto reproduce this issue:
* create an event. on the location tab, create a new location with the street address "test address 1"
* return to the manage event screen. click more > copy to copy the newly created event
* select the location...to reproduce this issue:
* create an event. on the location tab, create a new location with the street address "test address 1"
* return to the manage event screen. click more > copy to copy the newly created event
* select the location tab -- it will already have "test address 1" selected. click the option to "create new location" and add a street address "test address 2". save the event.
* return to the event management screen and click configure > location for the first event. note that the address now references "test address 2"
you should be able to create a new location for an event and it should have no effect on existing events that previously shared the location.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/109Categorizing case types2022-08-12T05:03:24ZreneolivoCategorizing case types#### Issue
Currently case types can have a name, but can't be grouped by a common category. Right now you can have multiple case types dealing with vacancies, (Ex: Publish available position, Conduct interview with candidate, Start recr...#### Issue
Currently case types can have a name, but can't be grouped by a common category. Right now you can have multiple case types dealing with vacancies, (Ex: Publish available position, Conduct interview with candidate, Start recruitment campaign, etc.), but there's no way to tell that these case types belong in a common conceptual group that differentiates them from other case types.
#### Proposed solution
Adding a *category* field to the *CaseType* schema.
#### Use cases
* Separating the administration of case types, such as the ones from application/vacancies.
* Using the case category to run specific actions when a new case is created or it's closed. For example, if a case with the category "Funds Raising" is closed, send a special notification to the accounts department. (this would be implemented on the extension side).
#### Core PR
https://github.com/civicrm/civicrm-core/pull/12098https://lab.civicrm.org/dev/core/-/issues/110Fix in CRM-14065 for status/date mismatch warning on activities doesn't seem ...2019-03-26T04:18:10ZDaveDFix in CRM-14065 for status/date mismatch warning on activities doesn't seem to workAnd on the public demo it doesn't seem to work either. The problem is the use of setHours() in activityStatus in templates/CRM/Activity/Form/ActivityJS.tpl.
Where it says
` var
// Ignore time, only compare dates
today = new Date()....And on the public demo it doesn't seem to work either. The problem is the use of setHours() in activityStatus in templates/CRM/Activity/Form/ActivityJS.tpl.
Where it says
` var
// Ignore time, only compare dates
today = new Date().setHours(0,0,0,0),
activityStatusId = cj('#status_id').val();`
it should be
` var
// Ignore time, only compare dates
today = new Date(),
activityStatusId = cj('#status_id').val();
today.setHours(0,0,0,0);`
because setHours() returns a timestamp and updates the object directly, and doesn't return a new Date object.https://lab.civicrm.org/dev/core/-/issues/111Support Custom Data for MembershipType entity2019-05-15T04:24:49Zmattwiremjw@mjwconsult.co.ukSupport Custom Data for MembershipType entityConvert MembershipType form to use API (for custom data support): https://github.com/civicrm/civicrm-core/pull/12118Convert MembershipType form to use API (for custom data support): https://github.com/civicrm/civicrm-core/pull/12118https://lab.civicrm.org/dev/core/-/issues/112CiviCRM locking may not account for multiple CiviCRM sites per server2018-05-13T07:14:33ZxurizaemonCiviCRM locking may not account for multiple CiviCRM sites per server* [MySQL's `GET_LOCK()` uses server-wide lock names.](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_get-lock)
* [CiviCRM's lock name generation does not seem to include the current CiviCRM site / DB name /...* [MySQL's `GET_LOCK()` uses server-wide lock names.](https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_get-lock)
* [CiviCRM's lock name generation does not seem to include the current CiviCRM site / DB name / identifier](https://github.com/eileenmcnaughton/civicrm-core/blob/b551edf53eff0019a9daed7cc950cf86f70f2e6f/CRM/Core/Lock.php#L111)
* Therefore, multiple CiviCRM sites on the same DB server may compete for the same lock names.
https://lab.civicrm.org/dev/core/-/issues/113Add new api handler 'current_domain' along the lines of 'user_contact_id'2022-06-13T01:56:11ZeileenAdd new api handler 'current_domain' along the lines of 'user_contact_id'Several api accept domain_id & in almost all cases the value passed is the current domain id. I think we should be able to set that as a default for api like membership type, instead of requiring it to be passed in as is currently the ca...Several api accept domain_id & in almost all cases the value passed is the current domain id. I think we should be able to set that as a default for api like membership type, instead of requiring it to be passed in as is currently the case.
With this we could change
```
function _civicrm_api3_membership_type_create_spec(&$params) {
// todo could set default here probably
$params['domain_id']['api.required'] = 1;
```
to
```
function _civicrm_api3_membership_type_create_spec(&$params) {
$params['domain_id']['api.default'] = 'current_domain';
```
We have a similar thing in place for 'user_contact_id' here
https://github.com/eileenmcnaughton/civicrm-core/blob/fee14197b427c1781e369e5bfd36816afad6d7ee/api/v3/utils.php#L2086 and I feel we could expand that piece of code.
Pinging @totten because Tim re-wrote that earlier handling of user_contact_id & may have some points he wishes to interjecthttps://lab.civicrm.org/dev/core/-/issues/114Email-Invoices fails since 4.7.31 because of invalid From-Addresses2018-05-16T02:43:17Zthomas_SYSTOPIAEmail-Invoices fails since 4.7.31 because of invalid From-AddressesReproduce:
1. Enable Tax and Invoicing (in "CiviContribute Component Settings")
2. Setup a From-Email-Adress
3. Create a Contribution
4. Use "Email Invoice" to send an Invoice.
You get: "**Validation failed for: from-email-address**"
T...Reproduce:
1. Enable Tax and Invoicing (in "CiviContribute Component Settings")
2. Setup a From-Email-Adress
3. Create a Contribution
4. Use "Email Invoice" to send an Invoice.
You get: "**Validation failed for: from-email-address**"
The reason could be found in CRM/Contribute/Form/Task/Invoice.php[460:465]:
```
$fromEmail = CRM_Core_BAO_Email::getFromEmail();
// from email address
if (isset($params['from_email_address'])) \{
$fromEmailAddress = CRM_Utils_Array::value($params['from_email_address'], $fromEmail);
}
```
The values of $fromEmail are html-escaped versions of the email-adresses. They might be useful for Select-Options in HTML-Forms. But they won't work for real email-headers.5.2.0https://lab.civicrm.org/dev/core/-/issues/115Proposal - create fields array standard & generic field template/s for it & f...2022-10-11T15:26:36ZeileenProposal - create fields array standard & generic field template/s for it & for fields, work towards generic entity form templateWe have a generalised issue where we want people to write extensions to alter CiviCRM but in many cases the way CiviCRM is structured makes that difficult and unmaintainable. As part of pushing people out to extensions we also need to wo...We have a generalised issue where we want people to write extensions to alter CiviCRM but in many cases the way CiviCRM is structured makes that difficult and unmaintainable. As part of pushing people out to extensions we also need to work to improve core code to support that purpose.
In the 5.x series we have made it easier for extension writers to store entity specific data by extending custom fields to (almost) all entities via the api*. However, it is still very difficult for extension writers to inject these fields, or other fields, into forms or to remove or re-order them. In general our approach has been to make things more metadata driven but we have not really standardised how to do this for templates. Conversely we already have examples in our code of templates that have been re-written to support output being modified by a php hook - (notably it is possible to alter the Billing fields on the payment form & the output columns in the contribution search from a php hook because metadata is assigned to the template & processed in the template) but we have not standardised those approaches into a recommendation.
To be clear - this proposal is NOT about going through all our forms and altering them to be more editable - it's about agreeing what we are working towards when we ARE editing forms. Currently it is possible to say
* "we are working towards replacing jcalendar.tpl with datepicker fields and when we touch date fields we should attempt to convert them"
* "we are working towards replacing non-metadata ways of adding fields to a form with addField and when we touch fields not added that way we should attempt to convert them"
Conversely we would say "if you are trying to fix the way a datefield is handling date defaults and the field is a jcalendar field we expect the fix to be converting it to a datepicker field rather than adding extra mangling for the legacy method".
In this case we would say
* "we are working towards assigning a standardised array of fields to a form & a tpl way of handling them and when we are working on a form we should seek to convert them"
(Generally we do require that PRs are improving the consistency & quality of our codebase & compliance with code-directions when we merge them)
I would note that complex forms like Contribution & Event forms might make poor candidates for tpl standardisation but a lot of our forms are simple settings forms or editing basic entities and these are good candidates for being generic & standardised. (This is allied with fixing the forms such that IF custom data is enabled on the entity THEN it can be altered via the form - which I will cover separately)
There are 2 open PRs which revolve around making tpls more generic, more metadata driven & more form-alterable
https://github.com/civicrm/civicrm-core/pull/12128/files#diff-1f76de158e02dfb7afa76303ef60e9ebR27
and https://github.com/civicrm/civicrm-core/pull/12078
The proposal would be that where it is possible to iterate through fields we assign them to the tpl in an array that looks like
```
$this-assign('entityFields', [
'field_1' => [
'name' => 'field_1',
'description' => ts("description to show below field"),
'help' => ['id' => 'id-field_1, 'file' => 'CRM/Contact/Form/Contact',
'is_add_translate_dialog' => 1,
],
'field_1' => ['name' => 'field_1'],
'money_field' => ['name' => 'money', 'formatter' => 'crmMoney'],
'weird_looking_field' => [
'name' => 'weird_looking_field',
'template' => CRM/Member/Form/MembershipType/weird_looking_field.tpl',
```
In practice some helpers would be involved in building the array so that fields like is_add_translate_dialog are derived from existing metadata. That would also potentially apply to keys like description, help & formatter. It is expected that if a field were to use a field specific template it would be under the path of the form.
The form template would then work towards looking more like
```
{foreach from=$entityFields item=fieldSpec}
{assign var=fieldName value=$fieldSpec.name}
<tr class="crm-{$entityInClassFormat}-form-block-{$fieldName}">
{include file="CRM/Core/Form/Field.tpl"}
</tr>
{/foreach}
```
With the tpl being
```
{if $fieldSpec.template}
{include file=$fieldSpec.template}
{else}
<td class="label">{$form.$fieldName.label}
{if $fieldSpec.help}{assign var=help value=$fieldSpec.help}{capture assign=helpFile}{if $fieldSpec.help}
{$fieldSpec.help}
{else}''{/if}
{/capture}{help id=$help.id file=$help.file}{/if}
{if $action == 2 && $fieldSpec.is_add_translate_dialog}{include file='CRM/Core/I18n/Dialog.tpl' table=$entityTable field=$fieldName id=$entityID}{/if}
</td>
<td>{if $form.$fieldName.html}{if $fieldSpec.formatter === 'crmMoney'}{$form.$fieldName.html|crmMoney}{else}{$form.$fieldName.html}{/if}{else}{$fieldSpec.place_holder}{/if}<br />
{if $fieldSpec.description}<span class="description">{$fieldSpec.description}</span>{/if}
</td>
{/if}
```
In some cases it might be too hard to make the form iterate through an array but individual fields could be converted - either in order to make that field hook alterable - (ie. the hook could then change the description metadata, or suppress a field) or as part of chipping away at the conversion
```
{assign var=fieldName value='my_converted_field'}
<tr class="crm-{$entityInClassFormat}-form-block-{$fieldName}">
{include file="CRM/Core/Form/Field.tpl"}
</tr>
```
* Note to enable custom data for a new type in an extension use code like the following
```
$optionValues = civicrm_api3('OptionValue', 'get', [
'option_group_id' => 'cg_extend_objects',
'name' => 'civicrm_relationship_type'
]);
if (!$optionValues['count']) {
civicrm_api3('OptionValue', 'create', [
'option_group_id' => 'cg_extend_objects',
'name' => 'civicrm_relationship_type',
'label' => ts('Relationship Type'),
'value' => 'RelationshipType',
]);
}
```https://lab.civicrm.org/dev/core/-/issues/116Search builder searches on primary addresses are producing unexpected results2018-05-21T11:34:30ZAndryg8Search builder searches on primary addresses are producing unexpected resultsLooking at civicrm.demo.civihosting.com v5.0.0. as well as our v5.2beta1 dev site, I am getting weird results for various search builder searches:
Contacts > Country > Primary is empty - returns many addresses, many of which have countr...Looking at civicrm.demo.civihosting.com v5.0.0. as well as our v5.2beta1 dev site, I am getting weird results for various search builder searches:
Contacts > Country > Primary is empty - returns many addresses, many of which have country field AND are set to primary
Contacts > Country > Home is empty - seems to behave correctly.
Contacts > Country > Primary is NULL - same as above
Contacts > Country > Primary is regex - produces an error:
`
^united$ is not of the type Positive`
Hope that's useful info! Our 5.2Beta1 site has the fixes for https://lab.civicrm.org/dev/core/issues/1065.3.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/117Remove usage of each() This is deprecated in php7.22018-05-28T02:48:08ZseamusleeRemove usage of each() This is deprecated in php7.2The following parts of the code still used each() which is an older format of foreach
```
CRM/Activity/BAO/Query.php: while (list(, $k) = each($value)) {
CRM/Activity/BAO/Query.php: while (list($k, $v) = each($value)...The following parts of the code still used each() which is an older format of foreach
```
CRM/Activity/BAO/Query.php: while (list(, $k) = each($value)) {
CRM/Activity/BAO/Query.php: while (list($k, $v) = each($value)) {
CRM/Case/XMLProcessor/Report.php: while (list($gid, $group_values) = each($groupTree)) {
CRM/Case/XMLProcessor/Report.php: while (list($id, $field_values) = each($group_values['fields'])) {
CRM/Event/Form/Participant.php: while (list($k, $dupeCheckContactId) = each($this->_contactIds)) {
CRM/Member/Form/MembershipView.php: $dir = each($relDirection);
CRM/Member/BAO/Membership.php: while (($available > 0) && ($params = each($queue))) {
CRM/Pledge/BAO/Pledge.php: list($field, $value) = each($startDate);
CRM/Pledge/BAO/PledgeBlock.php: list($field, $value) = each($date);
CRM/Report/Form/Contribute/Recur.php: while (list(, $suffix) = each($date_suffixes)) {
CRM/Report/Form/ActivitySummary.php: while (list(, $suffix) = each($date_suffixes)) {
CRM/Utils/Migrate/Import.php: while (list($group_id, $fields) = each($fields_indexed_by_group_id)) {
CRM/Utils/Migrate/Import.php: while (list(, $customFieldXML) = each($fields)) {
CRM/Utils/Token.php: while (list($key) = each($greetingTokens)) {
```
ping @eileen @monish.deb5.3.0https://lab.civicrm.org/dev/core/-/issues/118Fix where count() is used on an object that isn't an array nor implements Cou...2018-12-19T14:11:24ZseamusleeFix where count() is used on an object that isn't an array nor implements Countable for php7.2 (tested instances)```
<error type="PHPUnit_Framework_Error_Warning">CRM_Contribute_Import_Parser_ContributionTest::testImportParserWithSoftCreditsByExternalIdentifier with data set #0 ('.')
count(): Parameter must be an array or an object that...```
<error type="PHPUnit_Framework_Error_Warning">CRM_Contribute_Import_Parser_ContributionTest::testImportParserWithSoftCreditsByExternalIdentifier with data set #0 ('.')
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Contribute/Import/Parser/ContributionTest.php:67
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
</testcase>
<testcase name="testImportParserWithSoftCreditsByExternalIdentifier with data set #1" assertions="8" time="0.685860">
<error type="PHPUnit_Framework_Error_Warning">CRM_Contribute_Import_Parser_ContributionTest::testImportParserWithSoftCreditsByExternalIdentifier with data set #1 (',')
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Contribute/Import/Parser/ContributionTest.php:67
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgePaymentTest::testRetrieveZeroPledeID
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgePaymentTest.php:100
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgePaymentTest::testRetrieveStringPledgeID
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgePaymentTest.php:113
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgePaymentTest::testRetrieveKnownPledgeID
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgePaymentTest.php:127
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgePaymentTest::testDeletePledgePaymentsNormal
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgePaymentTest.php:137
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgePaymentTest::testDeletePledgePaymentsNullId
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgePaymentTest.php:160
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgeTest::testRetrieveZeroPledeID
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php:106
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
</testcase>
<testcase name="testRetrieveStringPledgeID" class="CRM_Pledge_BAO_PledgeTest" file="/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php" line="112" assertions="1" time="0.143334">
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgeTest::testRetrieveStringPledgeID
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php:117
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
</testcase>
<testcase name="testRetrieveKnownPledgeID" class="CRM_Pledge_BAO_PledgeTest" file="/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php" line="123" assertions="1" time="0.165138">
<error type="PHPUnit_Framework_Error_Warning">CRM_Pledge_BAO_PledgeTest::testRetrieveKnownPledgeID
count(): Parameter must be an array or an object that implements Countable
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php:147
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
</testcase>
<testcase name="testGetPledgeStartDate" class="CRM_Pledge_BAO_PledgeTest" file="/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php" line="153" assertions="1" time="0.149295">
<error type="PHPUnit_Framework_Error_Deprecated">CRM_Pledge_BAO_PledgeTest::testGetPledgeStartDate
The each() function is deprecated. This message will be suppressed on further calls
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/CRM/Pledge/BAO/Pledge.php:1203
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Pledge/BAO/PledgeTest.php:163
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:182
/home/seamus/buildkit/bin/phpunit5:598
</error>
```
ping @eileen @monish.deb5.4.0https://lab.civicrm.org/dev/core/-/issues/3261Membership Detail Report fails when ACLs are enabled2022-04-22T15:53:02ZJonGoldMembership Detail Report fails when ACLs are enabledDuring a tidy-up on the Membership Detail Report, the `from()` method was modified to use `CRM_Report_Form::setFromBase()`, which concatenates `$this->aclFrom`. However, concatenating `$this->aclFrom` was never removed from the child cl...During a tidy-up on the Membership Detail Report, the `from()` method was modified to use `CRM_Report_Form::setFromBase()`, which concatenates `$this->aclFrom`. However, concatenating `$this->aclFrom` was never removed from the child class, so it's added to the SQL statement twice.5.3.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/119Notice error2018-11-09T22:11:44ZJoeMurrayNotice errorhttp://dmaster.demo.civicrm.org/civicrm/contact/map/event?eid=3&reset=1
Notice: Undefined variable: is_public in CRM_Contact_Form_Task_Map_Event->preProcess() (line 54 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Contact/...http://dmaster.demo.civicrm.org/civicrm/contact/map/event?eid=3&reset=1
Notice: Undefined variable: is_public in CRM_Contact_Form_Task_Map_Event->preProcess() (line 54 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Contact/Form/Task/Map/Event.php).5.8Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/120Advanced Search - Contacts throws Fatal Error v 5.1.12018-05-17T02:11:00ZkcristianoAdvanced Search - Contacts throws Fatal Error v 5.1.1Advanced Search for Contacts White Screens - It works for Participants, Members, but not contacts.
Tested on official Download of CiviCRM 5.1.1.
Tested with:
Drupal 7
CiviCRM 5.1.1
php 7.0
MariaDB 10.1
WP 4.9.5
CiviCRM 5.1.1
php 7...Advanced Search for Contacts White Screens - It works for Participants, Members, but not contacts.
Tested on official Download of CiviCRM 5.1.1.
Tested with:
Drupal 7
CiviCRM 5.1.1
php 7.0
MariaDB 10.1
WP 4.9.5
CiviCRM 5.1.1
php 7.0
MariaDB 10.2
WP 4.9.5
CiviCRM 5.1.1
php 7.0
MariaDB 10.1
WP 4.9.5
CiviCRM 5.1.1
php 7.0
MySQL 5.6
All fail on a contact search with `PHP Fatal error: Uncaught Error: Call to undefined method CRM_Core_DAO::disableFullGroupByMode() in /home/ranger/public_html/wp-content/plugins/civicrm/civicrm/CRM/Contact/BAO/Query.php:4848 `
These commits are in 5.1.1 - https://github.com/civicrm/civicrm-core/pull/12074 https://github.com/civicrm/civicrm-core/pull/11996
but https://github.com/civicrm/civicrm-core/pull/12043 is not in 5.1.1
Will test adding https://github.com/civicrm/civicrm-core/pull/12043 and see if that fixes.5.1.0https://lab.civicrm.org/dev/core/-/issues/121Can't change 'Accept profile submissions from external sites' on Joomla2020-02-27T20:16:18Zaydunsaidan.saunders@squiffle.ukCan't change 'Accept profile submissions from external sites' on JoomlaJoomla 3.8.7 CiviCRM 5.1.1
Administration > System Settings > Misc accepts changes and 'Save' does not show any errors but the new value for 'Accept profile submissions from external sites' is not saved, so reloading the page shows the ...Joomla 3.8.7 CiviCRM 5.1.1
Administration > System Settings > Misc accepts changes and 'Save' does not show any errors but the new value for 'Accept profile submissions from external sites' is not saved, so reloading the page shows the original unmodified setting.
However, @kcristiano tested on Joomla successfullyhttps://lab.civicrm.org/dev/core/-/issues/122Wrong Action Links Shown for Reserved and Locked Option Groups2018-05-19T06:07:03ZmichaelWrong Action Links Shown for Reserved and Locked Option GroupsIn #55 I hid the "delete" link for options in a locked option group. This has a bug as it will already not have the "delete" link if the option value is reserved:
```
if ($dao->is_reserved) {
$action = CRM_Core_Action::UPDATE;
}
```
...In #55 I hid the "delete" link for options in a locked option group. This has a bug as it will already not have the "delete" link if the option value is reserved:
```
if ($dao->is_reserved) {
$action = CRM_Core_Action::UPDATE;
}
```
So subtracting the `CRM_Core_Action::DELETE` will result in a negative value for `$action` and more links than expected will be shown.
This can be fixed by first checking if the `CRM_Core_Action::DELETE` flag is active before unsetting it.
---
Link to PR: https://github.com/civicrm/civicrm-core/pull/12154/files5.3.0https://lab.civicrm.org/dev/core/-/issues/3540Hardcoded filesystem paths in JS strings in cache2022-06-11T14:45:13ZherbdoolHardcoded filesystem paths in JS strings in cacheI've noticed hardcoded filesystem paths in civicrm_cache where group_name = js_strings. With dynamic containers on a host this could mean that the JS can't be found if it switches containers. Is there a way to make this relative?I've noticed hardcoded filesystem paths in civicrm_cache where group_name = js_strings. With dynamic containers on a host this could mean that the JS can't be found if it switches containers. Is there a way to make this relative?https://lab.civicrm.org/dev/core/-/issues/123Import - Participant - Custom participant date fields are not formatted2022-06-11T16:02:19ZtschuettlerImport - Participant - Custom participant date fields are not formattedThe date fields are not converted from the import date format to the default date format and thus end up beeing imported with a date value of 0.
![image](/uploads/dda9843f54de137b5060553f4785655f/image.png)
Additionally 2 notice errors...The date fields are not converted from the import date format to the default date format and thus end up beeing imported with a date value of 0.
![image](/uploads/dda9843f54de137b5060553f4785655f/image.png)
Additionally 2 notice errors appear for each mapped custom particpant field in the import file:
>Notice: Undefined offset: 8 in CRM_Event_Import_Parser_Participant->import() (line 296 of /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Event/Import/Parser/Participant.php).
>Notice: Undefined offset: 8 in CRM_Event_Import_Parser_Participant->import() (line 300 of /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Event/Import/Parser/Participant.php).
Steps to reproduce:
1. Create a custom date field for participants
1. Import a participant with a non default date format: [participant_test.csv](/uploads/83f09e28f2435b819b41e120a9e28968/participant_test.csv)
See https://issues.civicrm.org/jira/browse/CRM-19386 for the same issue with activity imports.
A PR will be provided.5.3.0https://lab.civicrm.org/dev/core/-/issues/124Registration approval issues2018-06-17T23:18:36Zaydunsaidan.saunders@squiffle.ukRegistration approval issuesFor events requiring approval:
1) The confirmation screen generates a warning:
`Warning: A non-numeric value encountered in XXX/civicrm/CRM/Event/Form/Registration/Confirm.php on line 262`
2) The pre-approval confirmation and post-appr...For events requiring approval:
1) The confirmation screen generates a warning:
`Warning: A non-numeric value encountered in XXX/civicrm/CRM/Event/Form/Registration/Confirm.php on line 262`
2) The pre-approval confirmation and post-approval confirmation emails both have the subject 'Registration Confirmation' which is confusing to recipients.
3) The pre-approval confirmation mail includes a Fees section which shows fees of 0 since the fees have not been selected at this stage. So it would be better to remove the Fees section from the pre-approval confirmation (but not the post-approval confirmation)5.4.0aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.uk