Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-03-11T12:47:44Zhttps://lab.civicrm.org/dev/core/-/issues/2019Civicase: Wrong Details in Change Custom Data Activity when filling an empty ...2021-03-11T12:47:44ZAndreasandreas.howiller@civiservice.deCivicase: Wrong Details in Change Custom Data Activity when filling an empty fieldOverview
----------------------------------------
When custom case data is changed in CiviCase a Custom Data Activity is created logging the change in the activity details. This is working well in most circumstances but in some circumsta...Overview
----------------------------------------
When custom case data is changed in CiviCase a Custom Data Activity is created logging the change in the activity details. This is working well in most circumstances but in some circumstances the change log contains misleading content.
Reproduction steps
----------------------------------------
1. Create custom case field eg. of type text called "Custom text".
2. Go to any case and change the data of this field from empty to "short text" (save changes), and then again from "short text" to "short text" (same text, save again).
3. View the details of the two Custom Data Activity created.
Current behaviour
----------------------------------------
When changing the data of a custom text field called "Custom text" from "short text" to "a second short text" it will log: "Custom text: short text => a second short text".
**However under the following two conditions this produces misleading logging:**
1. When the text field above is empty in the beginning what you get is "Custom text: short text => short text". In practice this behavior may produce misunderstandings as it suggests that "short text" was already there and in use cases like application processes this may make a huge difference.
2. When the text field contains the same string a Custom Data Activity is created with Details empty.
Expected behaviour
----------------------------------------
1. In the first case one would expect something like "Custom text: [ ] => short text".
2. In the second case probably the best behaviour would be not to create an activity at all and showing an appropriate message instead.
Environment information
----------------------------------------
* __Browser:__ Firefox 80.0.1
* __CiviCRM:__ 5.28.1 on drupal 7 and 5.28.2 on WordPess 5.5.15.37.0https://lab.civicrm.org/dev/translation/-/issues/50Locale-aware recaptcha2020-12-14T04:07:55Zmattwiremjw@mjwconsult.co.ukLocale-aware recaptchaThe library in use by CiviCRM is a *very* old version and is not locale-aware. See https://civicrm.stackexchange.com/questions/11533/recaptcha-update-language/37503 for more info.
We should update the library and make recaptcha in CiviC...The library in use by CiviCRM is a *very* old version and is not locale-aware. See https://civicrm.stackexchange.com/questions/11533/recaptcha-update-language/37503 for more info.
We should update the library and make recaptcha in CiviCRM respect the locale of the form.https://lab.civicrm.org/dev/core/-/issues/2017Remove unused functions -2023-05-12T05:03:32ZeileenRemove unused functions -Finding a few unused functions at the moment - mostly because I opened the open id code to try to find where an extraneous query is coming from.... isAllowedToLoginFinding a few unused functions at the moment - mostly because I opened the open id code to try to find where an extraneous query is coming from.... isAllowedToLoginhttps://lab.civicrm.org/dev/core/-/issues/2016Disabling a section in advanced search keeps its parameters2023-05-04T05:03:18ZBastien HoDisabling a section in advanced search keeps its parametersOverview
----------------------------------------
In Contact Advanced Search, after a fist submit, if we "remove" an accordion, by clicking on the cross at its upper-right, we expect its fields to be excluded from search. But they're not...Overview
----------------------------------------
In Contact Advanced Search, after a fist submit, if we "remove" an accordion, by clicking on the cross at its upper-right, we expect its fields to be excluded from search. But they're not.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Advanced Search**.
1. Entered **gmail.com** in email field and **31%** in postal code field, clicked **Search**.
1. Click on the cross at the top right corner of the address pane. Fields are collapsed, clicked **Search**.
1. The search query still contain postal code and a join on address.
Current behaviour
----------------------------------------
Unless we use the "full" reset button and re-fill fields, it seems impossible to make a partial reset.
It also seems that opening a pane (eg: Activity) generates a SQL `JOIN`, even if no field in it is filled, and there is no way to reset it.
Expected behaviour
----------------------------------------
Click on a pane header toggle its content, without reseting its fields: ok
Click on the cross should reset all fields in the pane et remove the `JOIN`
Environment information
----------------------------------------
* __Browser:__ _Firefox 80_
* __CiviCRM:__ _5.28/..._
* __PHP:__ _7.4_
* __CMS:__ _WordPress 5.5/..._
* __Database:__ _MariaDB 10.4/..._
* __Web Server:__ _Apache 2.4..._https://lab.civicrm.org/dev/financial/-/issues/148Deprecate BaseIPN functions validateData & LoadObject2021-01-22T20:28:33ZeileenDeprecate BaseIPN functions validateData & LoadObjectWe've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it...We've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it
1) loads a couple of things - one of which is needed - contribution
2) it checks a couple of things
3) it calls loadObjects which in turn does very little over & above calling
```
$contribution->loadRelatedObjects($input, $ids)
```
Most of the things thus-loaded are unused - except in some specific ways within the processor classes & the stuff around $ids['paymentProcessor'] = $paymentProcessorID; could go if we just passed that as an input to the other functions.
In the past sometimes we have duplicated functions in order to unravel them. On a number of occasions this has worked out well. On others I think we are still paying the price. In particular I think it works when you duplicate code & then keep actively cleaning it up. The mess in the batch update task feels like a case where the code was probably duplicated but then left for a looooonnnnggg time.
In this case I think we can duplicate the contents back with a 'light clean' - since we've already gotten it down to fairly minimal code chunk.5.35.0https://lab.civicrm.org/dev/core/-/issues/2015composer-downloads-plugin and civicrm-asset-plugin need updates for composer v22023-05-03T05:03:19Ztottencomposer-downloads-plugin and civicrm-asset-plugin need updates for composer v2At time of writing, `composer` is preparing for their next major release (v1 => v2). See also:
* https://github.com/composer/composer/issues/8726
* https://github.com/composer/composer/blob/master/UPGRADE-2.0.md#for-integrators-and-plug...At time of writing, `composer` is preparing for their next major release (v1 => v2). See also:
* https://github.com/composer/composer/issues/8726
* https://github.com/composer/composer/blob/master/UPGRADE-2.0.md#for-integrators-and-plugin-authors
From what I've seen so far, there is an easy part and a hard part for updating `composer-downloads-plugin`:
* _Easy part_: The `PluginInterface` expects a few more methods. Just add placeholders. (Ex: https://github.com/composer/composer/blob/master/UPGRADE-2.0.md#for-integrators-and-plugin-authors)
* _Hard part_: The download system has been reorganized to use ReactPHP `Promise`s, and an internal `download()` method has been rearranged into multiple methods (`download()`, `prepare()`, `install()`).
* _Note to self: think more about the relationship between `Composer\Installer\InstallationManager` (which takes a lot of effort to coordinate the on-going promises) and `LastCall\DownloadsPlugin\Plugin::installUpdateDownloads()` (which also coordinates multiple actions)._https://lab.civicrm.org/dev/core/-/issues/2014Search on line items Ability to aggregate on a different field2020-09-22T01:06:13ZeileenSearch on line items Ability to aggregate on a different fieldGoal is to search on line items and group by financial type but aggregate the line total and tax columns, getting a total by financial type (we hit a variant of this the other day with basically the same thing on contributions)
@colemanwGoal is to search on line items and group by financial type but aggregate the line total and tax columns, getting a total by financial type (we hit a variant of this the other day with basically the same thing on contributions)
@colemanw5.31.0https://lab.civicrm.org/dev/core/-/issues/2013Line Item support in 'create search' - create smart group2020-10-07T19:45:57ZeileenLine Item support in 'create search' - create smart groupSo in trying to define a way in which line items in search might be useful I have this issue to define a first use case
Goal - create a smart group of all contacts with the line items of price field value 'General' in Price set 'Members...So in trying to define a way in which line items in search might be useful I have this issue to define a first use case
Goal - create a smart group of all contacts with the line items of price field value 'General' in Price set 'Membership Amount' (this is a bit of an artificial choice of line item but it's on default installs)
I had some success but could not link back to contacts...
![Screen_Shot_2020-09-11_at_11.26.29_AM](/uploads/1f07529473cd70d6d7d58cdac8cbbc37/Screen_Shot_2020-09-11_at_11.26.29_AM.png)
@colemanw5.31.0https://lab.civicrm.org/dev/core/-/issues/2012Document impact of css / html buttons merged to 5.31 that may require action ...2021-03-01T13:07:40ZeileenDocument impact of css / html buttons merged to 5.31 that may require action by integrators(from @andrewhunt in chat) PR #18410 just merged to master that changes how nearly all buttons in CiviCRM are formed. The good news is that buttons will look better, be easier to theme, and be handled consistently with things we make loo...(from @andrewhunt in chat) PR #18410 just merged to master that changes how nearly all buttons in CiviCRM are formed. The good news is that buttons will look better, be easier to theme, and be handled consistently with things we make look like buttons. The bad news is that you may need to update your extensions to accommodate the change. You can read more details in the PR and the two earlier ones it referred to (changes were originally to come in 5.29, but it got deferred to early in the 5.31 cycle so there's time for everyone to accommodate them).
The most important change is that
```<input type="submit">``` and ```<input type="button"> ```
are replaced with
```<button type="submit">``` and ```<button type="button">``` across the board.
There are three main ways you may need to accommodate this:
Check your CSS-style selectors. If you have something like ```$("input#mybutton").click()```, it won't work anymore. Same with ```.crm-button input``` --the <button> elements themselves are the wrapper now, so all those ```<span class="crm-button">``` elements are toast. To handle the old and new ways, you might look for specific IDs, classes, names, and/or types rather than just switching input to button.
Check how you add buttons. The helper ```CRM_Core_Form::addButtons()``` has been updated to work the new way, so if that's all you do, you're safe. However, if you do something like
PHP
```$form->addElement('submit', 'submit_button', ts('Submit'));```
You'll want to replace it with something like
PHP
```
$form->addElement(
'xbutton',
'submit_button',
ts('Submit'),
[
'type' => 'submit',
'class' => 'crm-button',
]
);
```
In your template, you won't need to add a wrapper, but if you don't give the <button> element the crm-button class, it won't look like the others. Please note that xbutton is not a typo. Quickform, in it's wisdom, uses button for creating <input type="button"> elements. You must use xbutton to create an actual <button>.
Check how you identify the button that was clicked. The text on an <input> button is the value attribute, and if that button was clicked, the button's name comes through on the submitted params. However, a <button> element wraps around the button text and may have no value. If there's no value, you won't see a value for it in the params. Instead of looking for this, you might consider using $form->controller->getButtonName() to identify the button that was clicked. That said, core now gives most buttons a value of 1 because there were too many instances where the code looked for the value in the params.
E.g. of code to change
![Screen_Shot_2020-09-11_at_10.48.04_AM](/uploads/d0ac6d6e54d53e2ba1afc04c5419da0e/Screen_Shot_2020-09-11_at_10.48.04_AM.png)
e.g of backward compatible code change
![Screen_Shot_2020-09-11_at_10.58.14_AM](/uploads/6d8ed3f6461d3a5b872d2eedca377851/Screen_Shot_2020-09-11_at_10.58.14_AM.png)
https://gitlab.com/physician-health-program-of-bc/saveandnewcopy/-/commit/441a165ea1debf15c335f291d3251aecc68dc5f2https://lab.civicrm.org/dev/core/-/issues/2011Extension display UI improvement - separate out processors2023-05-02T05:03:21ZeileenExtension display UI improvement - separate out processorsA while back JohnFF did a PR to split the extension screen out into topics. It stalled because aspects around the categorisation were problematic & I understand there was some issue that became blocking.
However, I think we all agreed t...A while back JohnFF did a PR to split the extension screen out into topics. It stalled because aspects around the categorisation were problematic & I understand there was some issue that became blocking.
However, I think we all agreed the UI outcome was good.
We discussed today that we could bring this back in a more phased way - ie
1) scan for extensions with the tag topic:payment-processor
https://docs.civicrm.org/dev/en/latest/extensions/info-xml/#tags
If some are detected then display them in a separate PaymentProcessor's tab instead of the main tab
2) encourage payment processors to add the tab & add it to those we can
3) once people can see how it works with one generally agreed categorisation open up the discussion as to what other taxonomy we should use - I would expect the permitted ones in the original implementation would just be an array - so this would be technically easy but the discussion would be probably fairly extensive. Payment processors stand out, however, as being the part of the discussion that could be easily picked off
https://github.com/civicrm/civicrm-core/pull/12924https://lab.civicrm.org/dev/financial/-/issues/147Clicking orange Paypal Button with Paypal Pro results in form validation jque...2020-10-06T16:44:40ZStoobClicking orange Paypal Button with Paypal Pro results in form validation jquery error![ppp](/uploads/71d9a6ca4181196465ce3259f771e76e/ppp.png)
Reproduce by:
1. setting up Paypal Pro processor
2. clicking the orange button *should* send you to Paypayl.com to login instead of paying by card
3. instead it immediately trigg...![ppp](/uploads/71d9a6ca4181196465ce3259f771e76e/ppp.png)
Reproduce by:
1. setting up Paypal Pro processor
2. clicking the orange button *should* send you to Paypayl.com to login instead of paying by card
3. instead it immediately triggers the jquery form validation required fields for card5.29.1https://lab.civicrm.org/dev/core/-/issues/2010Contact Reference in profile display2023-05-09T05:03:24ZaniesshsethhContact Reference in profile displayI am trying to reference the contact reference field's email id in the civicrm group profile, but it is not going beyond level 2, that is it is happily referencing the field itself, but I cannot reference email from this contact referenc...I am trying to reference the contact reference field's email id in the civicrm group profile, but it is not going beyond level 2, that is it is happily referencing the field itself, but I cannot reference email from this contact reference. Is this a valid issue?!
And yes, I have tried this on the demo site as well
https://demo.circle-interactive.co.uk/civicrm/admin/uf/group/field?reset=1&new=1&gid=15&action=browse
[Image_2020-09-11_at_1.39.07_AM](/uploads/5f22a79c2b269c85948f227d98a04d8e/Image_2020-09-11_at_1.39.07_AM.png)https://lab.civicrm.org/dev/core/-/issues/2009Grant dashboard counts trashed contacts2020-09-10T22:21:10ZlcdwebGrant dashboard counts trashed contactsThe grant dashboard tallies include contacts that are trashed and shouldn't. To reproduce:
* observe current dashboard stats for a specific status
* create a contact and create a grant with that same status
* trash the contact
* observe...The grant dashboard tallies include contacts that are trashed and shouldn't. To reproduce:
* observe current dashboard stats for a specific status
* create a contact and create a grant with that same status
* trash the contact
* observe the dashboard stats. it will have incremented by 1, including the trashed record
If you click the hyperlink to search for grants the trashed record is properly excluded. It's just the dashboard stats that are off.5.31.0lcdweblcdwebhttps://lab.civicrm.org/dev/financial/-/issues/146alterPaymentProcessorParams hook and propertyBag2020-09-15T15:35:00Zmattwiremjw@mjwconsult.co.ukalterPaymentProcessorParams hook and propertyBagSee https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all t...See https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all the quirks of checking different array keys for one thing.
> - ✔ any setting the hook does in a prop bag ensures forward consistency for the next process in the chain (another hook or the main process)
> - ✖ It's possible that the reason for a hook is something pretty darn weird needs doing; in which case the raw array may be more useful.
>
> 2. pass the original array to the hook
>
> - ✖ hook has to do all work arounds
> - ✖ hook is free to implement bad practise in altering the array
> - ✔ hook can do whatever it likes.
>
> I think (1).
And example from Stripe where we're currently passing an array for compatibility (but this should not be used as a model as Stripe ignores the return values from the hook anyway).
https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/Stripe.php#L484-489
// @fixme DO NOT SET ANYTHING ON $propertyBag or $params BELOW THIS LINE (we are reading from both)
$params = $this->getPropertyBagAsArray($propertyBag);
// We don't actually use this hook with Stripe, but useful to trigger so listeners can see raw params
$newParams = [];
CRM_Utils_Hook::alterPaymentProcessorParams($this, $params, $newParams);https://lab.civicrm.org/dev/financial/-/issues/145Adding "standard" params to propertyBag2020-09-16T00:42:12Zmattwiremjw@mjwconsult.co.ukAdding "standard" params to propertyBagThis came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor th...This came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor that has been converted to use propertyBag is likely to break existing implementations.
Accessing params that are later added as "standard" params to propertyBag when a payment processor is already converted internally to propertyBag (eg. most of the ones written by me Stripe, authnetecheck, Smartdebit).
Example Issues:
- authnetecheck accesses `$params['credit_card_number']` which disappears once mapped to a propertyBag because only the standardised `cardNumber` field is available.
- If authnetecheck was using `$propertyBag->getCustomProperty('credit_card_number')` it would throw an "InvalidArgumentException" because you are not allowed to use `getCustomProperty` for a "standard" property.
Similar issues will apply to any other properties that are already in use by a payment processor.
@eileen @artfulrobot @seamuslee @tottenhttps://lab.civicrm.org/dev/core/-/issues/2006Token Processor refactoring (make core token classes accessible outside sched...2021-10-02T05:30:43ZseamusleeToken Processor refactoring (make core token classes accessible outside scheduled reminder context)Gitlab for pR https://github.com/civicrm/civicrm-core/pull/16983Gitlab for pR https://github.com/civicrm/civicrm-core/pull/169835.43.0https://lab.civicrm.org/dev/core/-/issues/2005Token Sub Type improvements2023-09-20T05:03:28ZseamusleeToken Sub Type improvementsGitlab for PR https://github.com/civicrm/civicrm-core/pull/16982Gitlab for PR https://github.com/civicrm/civicrm-core/pull/16982https://lab.civicrm.org/dev/core/-/issues/2004Hierarchical groups don't always get the correct group IDs in a "groups" prof...2020-10-21T21:04:31ZJonGoldHierarchical groups don't always get the correct group IDs in a "groups" profile fieldWhen you have a profile with the "Groups" field, under certain circumstances the wrong group IDs get assigned to the various input elements - so folks are subscribed to the wrong group. In some scenarios, where the group ID doesn't exis...When you have a profile with the "Groups" field, under certain circumstances the wrong group IDs get assigned to the various input elements - so folks are subscribed to the wrong group. In some scenarios, where the group ID doesn't exist, you get a constraint violation.
I'm having some trouble replicating this on a test site, so while I have a fix, I don't have a test yet.
The issue lies somewhere in `CRM_Contact_BAO_Group::getGroupsHierarchy()`, which returns an array of groups where the key is (usually) the group's ID. Under certain circumstances they return in an incorrect order.
I don't have time at present to track it down, so I'm just posting a patch here in case others find the issue. If I have time to find the exact set of circumstances that lead to this issue, I'll write a test and submit a PR.
```diff
diff --git a/sites/all/modules/civicrm/CRM/Contact/Form/Edit/TagsAndGroups.php b/sites/all/modules/civicrm/CRM/Contact/Form/Edit/TagsAndGroups.php
index 9299246d..361311dc 100644
--- a/sites/all/modules/civicrm/CRM/Contact/Form/Edit/TagsAndGroups.php
+++ b/sites/all/modules/civicrm/CRM/Contact/Form/Edit/TagsAndGroups.php
@@ -93,7 +93,7 @@ class CRM_Contact_Form_Edit_TagsAndGroups {
$attributes['skiplabel'] = TRUE;
$elements = [];
$groupsOptions = [];
- foreach ($groups as $id => $group) {
+ foreach ($groups as $group) {
// make sure that this group has public visibility
if ($visibility &&
$group['visibility'] == 'User and User Admin Only'
@@ -102,11 +102,11 @@ class CRM_Contact_Form_Edit_TagsAndGroups {
}
if ($groupElementType == 'select') {
- $groupsOptions[$id] = $group;
+ $groupsOptions[$group['id']] = $group;
}
else {
- $form->_tagGroup[$fName][$id]['description'] = $group['description'];
- $elements[] = &$form->addElement('advcheckbox', $id, NULL, $group['text'], $attributes);
+ $form->_tagGroup[$fName][$group['id']]['description'] = $group['description'];
+ $elements[] = &$form->addElement('advcheckbox', $group['id'], NULL, $group['text'], $attributes);
}
}
```https://lab.civicrm.org/dev/drupal/-/issues/140Improvement in member role sync to avoid unnecessary role remove and role rea...2020-09-15T18:42:04ZsadashivImprovement in member role sync to avoid unnecessary role remove and role reassignIf we turn on civicrm member role sync module and configure the membership to sync to a role then system removes the role and reassigns it when the sync function is invoked.
Steps to replicate:
1) Create a Membership type
2) Create a ro...If we turn on civicrm member role sync module and configure the membership to sync to a role then system removes the role and reassigns it when the sync function is invoked.
Steps to replicate:
1) Create a Membership type
2) Create a role in drupal
3) Enable civicrm_member_roles module
4) Configure the member role rule to add the new role on proper status of the membership
5) Configure the membership role to sync on user login or logout
6) Create a new membership for any user (note that the user now doesn't have the new role)
7) Login as the user (note that the user now has the role assigned)
8) Logout
If we see the code in the module it has a db_delete to delete the role assignment and then more code to reassign the role back, and these actions are performed on login or logout. This can be improved by not deleting the role and not saving the user again if there is no change required. This can be a improvement and will save few overhead on queries and on login/logout.
Thanks,
Sadashiv.https://lab.civicrm.org/dev/wordpress/-/issues/75Mailing List Subscription URL not using WP base page slug2020-09-29T07:28:37ZBorislavZlatanovMailing List Subscription URL not using WP base page slugEnvironment: CiviCRM 5.29.0, WordPress 5.4.2, PHP 7.3.20.
This issue started happening after an update of CiviCRM from 5.19 to 5.29: When subscribing to a mailing list, the confirmation link is missing a part, namely the WordPress CiviC...Environment: CiviCRM 5.29.0, WordPress 5.4.2, PHP 7.3.20.
This issue started happening after an update of CiviCRM from 5.19 to 5.29: When subscribing to a mailing list, the confirmation link is missing a part, namely the WordPress CiviCRM base page slug. The link is supposed to be:
https://example.org/civicrm?civiwp=CiviCRM&q=civicrm%2Fmailing%2Fconfirm&reset=1&cid=111111&sid=111&h=11111111111
and instead it is:
https://example.org/?civiwp=CiviCRM&q=civicrm%2Fmailing%2Fconfirm&reset=1&cid=111111&sid=111&h=11111111111
That is, it is missing the /civicrm part (which is the base page slug) after the domain name. This seems to lead to the CiviCRM Smarty template not being properly loaded. If I manually insert the /civicrm part in the link, then the template is loaded correctly.
The WordPress base page is correctly selected in Administer > System Settings > CMS Database Integration. The /civicrm part seems to be correctly appearing in the URL in other situations - in the links for tracking opens, tracking clicks, unsubscribing.
The piece of code generating the confirmation link seems to be in /civicrm/CRM/Mailing/Event/BAO/Subscribe.php, line 216:
```
$url = CRM_Utils_System::url('civicrm/mailing/confirm',
"reset=1&cid={$this->contact_id}&sid={$this->id}&h={$this->hash}",
TRUE, NULL, TRUE, TRUE
);
```
I don't know if this code is taking into consideration the WordPress base page or not, or if the page's slug is supposed to be added to the URL here or in some other place.
Any help appreciated. :)