CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-08-12T05:03:24Zhttps://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/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/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/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/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/128Add deprecated warning helper function2018-05-28T02:48:08Zmattwiremjw@mjwconsult.co.ukAdd deprecated warning helper functionOverview
----------------------------------------
This adds a standard method to log a deprecated function warning.
PR: https://github.com/civicrm/civicrm-core/pull/12040
Before
----------------------------------------
Deprecated func...Overview
----------------------------------------
This adds a standard method to log a deprecated function warning.
PR: https://github.com/civicrm/civicrm-core/pull/12040
Before
----------------------------------------
Deprecated function warnings were inconsistent and you have to put too much detail in the log line.
After
----------------------------------------
One simple function that autogenerates the log message based on caller.
Comments from previous PR #12007
----------------------------------------
@totten:
> I think @totten tried to enhance deprecated output at some point
Probably this: https://chat.civicrm.org/civicrm/pl/cf1p7hgkkprp9kthkosq98qrer
@mattwire
> A standalone helper function is more pithy than the Civi::log...civi.tag=>deprecated.... Pithy is good.
From r-code perspective, I don't like having that helper in CRM_Utils_System. That class is too heavy already, and deprecatedFunctionWarning() is qualitatively different from every other function in the class.
Yes, I agree. I wasn't sure where to "dump" the function. Maybe `CRM/Core/Error/Log.php` would be a better place for it?
> My main hesitation with cf1p7hgkkprp9kthkosq98qrer was that findNonLogCaller() felt a little heavy-handed. It's nice how deprecatedFunctionWarning() doesn't have to dig as far back into the callstack.
> On the other hand, it's nice how cf1p7hgkkprp9kthkosq98qrer works with the existing coding convention.
We don't actually log deprecated very much so I don't think it's a big change to convention.5.3.0https://lab.civicrm.org/dev/core/-/issues/129Make Event Participant form use more generic custom data functions2022-08-11T05:03:23Zmattwiremjw@mjwconsult.co.ukMake Event Participant form use more generic custom data functionsUse more generic custom data functions for event forms. Waiting for generic custom data functions to be finalised.
Ref: https://github.com/civicrm/civicrm-core/pull/12119Use more generic custom data functions for event forms. Waiting for generic custom data functions to be finalised.
Ref: https://github.com/civicrm/civicrm-core/pull/12119https://lab.civicrm.org/dev/core/-/issues/132'Current Member' field in searches does not perform as expected2022-10-25T20:35:58Zeileen'Current Member' field in searches does not perform as expectedReplacing https://issues.civicrm.org/jira/browse/CRM-21403 with gitlab issue - much discussion over on the original proposed code change - https://github.com/civicrm/civicrm-core/pull/11968 and it's not clear what changes should be madeReplacing https://issues.civicrm.org/jira/browse/CRM-21403 with gitlab issue - much discussion over on the original proposed code change - https://github.com/civicrm/civicrm-core/pull/11968 and it's not clear what changes should be madehttps://lab.civicrm.org/dev/core/-/issues/133Reply-to field with empty string get saved in DB as NULL2018-06-18T20:41:13ZvarshithReply-to field with empty string get saved in DB as NULL**Issue:**
Somehow our client's mailing got saved with 'NULL' reply-to field and was causing problems.
On looking into it and trying to reproduce the issue, 'reply to' field can be NULL in the following case
- Add a new mailing (or reus...**Issue:**
Somehow our client's mailing got saved with 'NULL' reply-to field and was causing problems.
On looking into it and trying to reproduce the issue, 'reply to' field can be NULL in the following case
- Add a new mailing (or reuse one)
- Select a 'reply to' email (I had to enable "Enable Custom Reply-To" in 'civicrm/admin/mail')
- Fill in other fields as usual
- Under 'Responses' tab, check "Track Replies" checkbox. This brings up a warning message on the top right saying 'reply-to' has been cleared out (but still allows user to save mailing)
- Proceed to next step and save mailing
**Proposed Fix:**
I am not sure how to fix this as the user is expected to see the warning message and act accordingly. But I think we can check and not allow NULL values for reply-to in DB.
In CRM_Mailing_BAO_Mailing.php when adding a new mailing (add() method), there is a condition to check if 'reply-to' field is set and if it is not set, then 'from-email' is used.
here instead if using
if(\!isset($params['replyto_email']))...
we should use
if(empty($params['replyto_email']))...
so that empty string like '' will also be considered and reply-to could not be NULL5.4.0https://lab.civicrm.org/dev/core/-/issues/3320Admin Membership type is displayed on Public contribution page.2022-04-22T16:17:02ZjitendraAdmin Membership type is displayed on Public contribution page.When visibility of membership type is updated to `Admin`, it is still displayed on front-end contribution pages. Steps to replicate -
- Create a membership type.
- Add it to a contribution page.
- Set visibility of the type to `Admin`.
...When visibility of membership type is updated to `Admin`, it is still displayed on front-end contribution pages. Steps to replicate -
- Create a membership type.
- Add it to a contribution page.
- Set visibility of the type to `Admin`.
- Navigate to contribution page - the membership type is still displayed on the page.jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/135Non Numeric value encountered in CRM_Batch_Form_entryTest on PHP7.1 and 7.22018-11-04T20:33:27ZseamusleeNon Numeric value encountered in CRM_Batch_Form_entryTest on PHP7.1 and 7.2```
<error type="PHPUnit_Framework_Error_Notice">CRM_Batch_Form_EntryTest::testMembershipRenewalDates
A non well formed numeric value encountered
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/CRM/Price/BAO/LineItem.php:...```
<error type="PHPUnit_Framework_Error_Notice">CRM_Batch_Form_EntryTest::testMembershipRenewalDates
A non well formed numeric value encountered
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/CRM/Price/BAO/LineItem.php:374
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/CRM/Price/BAO/PriceSet.php:747
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/CRM/Batch/Form/Entry.php:761
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/CRM/Batch/Form/Entry.php:922
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CRM/Batch/Form/EntryTest.php:256
/home/seamus/buildkit/build/47.demo/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:192
/home/seamus/buildkit/bin/phpunit5:598
</error>
```
The relevant code is here https://github.com/civicrm/civicrm-core/blob/master/CRM/Price/BAO/LineItem.php#L374 i'm guessing its most likely going to be $qty that is NULL maybe5.3.0https://lab.civicrm.org/dev/core/-/issues/140Add missing pseudoconstant for option_group_id in CustomField2018-11-04T20:40:17ZMichael McAndrewAdd missing pseudoconstant for option_group_id in CustomFieldPseudoconstant tag was missing from the XML definition, meaning that one could not create custom fields and specify their select options without knowing the numerical ID.Pseudoconstant tag was missing from the XML definition, meaning that one could not create custom fields and specify their select options without knowing the numerical ID.5.4.0https://lab.civicrm.org/dev/core/-/issues/141Custom groups with different names but same title would not be saved2018-07-14T01:25:44ZjaapjansmaCustom groups with different names but same title would not be savedI have created two custom groups from within my extension:
* Name: group_areas, Title: Areas
* Name: contact_areas, Title: Areas
When I now edit the custom group it will fail because both custom groups have the same title but a differe...I have created two custom groups from within my extension:
* Name: group_areas, Title: Areas
* Name: contact_areas, Title: Areas
When I now edit the custom group it will fail because both custom groups have the same title but a different name.
Is this correct behaviour?
See this stack exchange question: https://civicrm.stackexchange.com/questions/25102/https-civicrm-org-extensions-areas-causing-error/25104#25104
Tested on CiviCRM version 5.0.0 and CiviCRM version 5.1.aplha15.5.0https://lab.civicrm.org/dev/core/-/issues/142States and Counties don't chain in Search Builder2022-07-01T20:25:48ZMonish DebStates and Counties don't chain in Search BuilderMany states and counties have common names. Maryland could be in Liberia or the United States. There are 3 states named "Distrito Federal". Within the US, there are 18 counties named Montgomery.
The Search Builder state and county field...Many states and counties have common names. Maryland could be in Liberia or the United States. There are 3 states named "Distrito Federal". Within the US, there are 18 counties named Montgomery.
The Search Builder state and county fields don't filter with reference to the country or state fields that are within the same AND grouping. The state field displays the states from the countries that have states enabled, and the county field displays all counties in alphabetical order.
This presents two problems:
1. If you have multiple options with the same name, you have no idea which is which. Is "Distrito Federal" in Brazil, Mexico, or Venezuela? Which of the 31 "Washington" counties is the right one? There's no way to input the ID anymore if you happen to know.
2. If you are looking for a state that's not in one of the countries you have set for "available states and provinces", you're out of luck.
Two proposed alternatives:
1. Make the states drop-down depend upon a country of the same location type, within the same "AND" grouping. Do the same for the counties with regard to the states. This would require some kind of parameter to be sent to the address/getoptions API to filter the list, but it would make them work in the same way as elsewhere in CiviCRM.
2. Have a new context for address/getoptions that prefixes the state name with the country and prefixes the county name with the state. (We can probably safely assume that the same county/state combinations appear in multiple countries--no Montgomery County, Maryland, Liberia.) This means that a user doesn't need to add redundant criteria to the search.
For the second option, that doesn't solve the problem of picking states in other countries, but maybe a checkbox could alternate between showing all countries' states (maybe setting the context as "get" instead of "search").
JIRA ticket : https://issues.civicrm.org/jira/browse/CRM-17572Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/144getCustomFieldID switch to API, add caching, add full string return option2018-06-17T23:18:27Zmattwiremjw@mjwconsult.co.ukgetCustomFieldID switch to API, add caching, add full string return optionIn most of my extensions I implement something like this: https://github.com/mattwire/uk.co.mjwconsult.recurmaster/blob/master/CRM/Recurmaster/Utils.php#L14
Because I want the lookup to be cached so I can use it multiple times without a...In most of my extensions I implement something like this: https://github.com/mattwire/uk.co.mjwconsult.recurmaster/blob/master/CRM/Recurmaster/Utils.php#L14
Because I want the lookup to be cached so I can use it multiple times without a performance issue (eg. within hooks). It is also useful to be able to return the full string equivalent (ie. custom_123 instead of 123) as it can then be used directly in parameter arrays like `$key = getCustomFieldID()` without doing: `$key = 'custom_' . getCustomFieldID()`
This is a proposal to update the core function getCustomFieldID so that it is more useful. It should also help towards https://lab.civicrm.org/dev/core/issues/1095.4.0https://lab.civicrm.org/dev/core/-/issues/145CRM-20637 extend expired price fields in backend2022-08-13T05:03:47ZeileenCRM-20637 extend expired price fields in backendPlace to agree correct approach per discussions on
https://github.com/civicrm/civicrm-core/pull/10423 and https://github.com/civicrm/civicrm-core/pull/10804Place to agree correct approach per discussions on
https://github.com/civicrm/civicrm-core/pull/10423 and https://github.com/civicrm/civicrm-core/pull/10804https://lab.civicrm.org/dev/core/-/issues/147One of parameters is not of the type MysqlColumnNameOrAlias when using Non-AS...2019-04-29T20:20:11ZMonish DebOne of parameters is not of the type MysqlColumnNameOrAlias when using Non-ASCII display names.To reproduce, change Display Name of a location type (http://dmaster.demo.civicrm.org/civicrm/admin/locationType) to some Non-ASCII text (or just install civicrm on some Non-ASCII language, in my case Russian). When go to Search Builder ...To reproduce, change Display Name of a location type (http://dmaster.demo.civicrm.org/civicrm/admin/locationType) to some Non-ASCII text (or just install civicrm on some Non-ASCII language, in my case Russian). When go to Search Builder (http://dmaster.demo.civicrm.org/civicrm/contact/search/builder) and try to search contacts with phone, or email, or address of that location type.
Get an error message:
Sorry but we are not able to provide this at the moment.
One of parameters (value: Дом-email) is not of the type MysqlColumnNameOrAlias
Ref : https://issues.civicrm.org/jira/browse/CRM-19089Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/148Activity Separation field changes the default behaviour2022-08-13T05:03:48ZyashodhaActivity Separation field changes the default behaviourSome of the users without realizing might select the first option that is *Create separate activities for each contact* which might confuse them since that's not how it behaved earlier.Some of the users without realizing might select the first option that is *Create separate activities for each contact* which might confuse them since that's not how it behaved earlier.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/149Fatal Error on customvalue get api2018-06-01T12:12:09ZjitendraFatal Error on customvalue get apiReplicated on dmaster http://dmaster.demo.civicrm.org/civicrm/api#explorer
Entity = `CustomValue` Action = `get`
Fields to return => `custom_1`
Parameter => `entity_id = <any contact id>`
$result = civicrm_api3('CustomValue', 'get'...Replicated on dmaster http://dmaster.demo.civicrm.org/civicrm/api#explorer
Entity = `CustomValue` Action = `get`
Fields to return => `custom_1`
Parameter => `entity_id = <any contact id>`
$result = civicrm_api3('CustomValue', 'get', [
'sequential' => 1,
'return' => "custom_1",
'entity_id' => 202,
]];
Result -
"is_error": 1,
"error_message": "A fatal error was triggered: is not of type String"jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/150Chain select for country/state in Search Builder does not stay within OR grou...2018-07-17T06:54:34ZAndie HuntChain select for country/state in Search Builder does not stay within OR groupingsdev/core#142 introduces a chained select for picking states from countries and picking counties from states. The changes there correctly limit the chaining to be within the same location type. However, picking a country will modify *al...dev/core#142 introduces a chained select for picking states from countries and picking counties from states. The changes there correctly limit the chaining to be within the same location type. However, picking a country will modify *all* state/province fields of that location type, even if they're in different "Also include contacts where" sections.
To recreate, let's say you are planning an event in Detroit:
1. Search for contacts in Michigan:
```
Contacts | Country | Home | = | United States
Contacts | State | Home | = | Michigan
```
2. Search for contacts in Ontario by clicking "Also include contacts where" and setting up:
```
Contacts | Country | Home | = | Canada
Contacts | State | Home | = | Ontario
```
Notice that the state dropdown where Michigan had been selected now has nothing selected and offers only Canadian provinces.
The same thing happens if you have a state field on its own (without country) and you pick a country in another `OR` grouping.5.5.0Monish DebMonish Deb