Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-03-11T19:06:09Zhttps://lab.civicrm.org/dev/core/-/issues/662Mail accounts don&#39;t work if the password contains &quot;2019-03-11T19:06:09ZjohnffMail accounts don't work if the password contains "Mail accounts cannot be read by the activities processor if the password contains "
The fix for this is simple - put addslashes before the password is read, and this fix is working in our production instance.Mail accounts cannot be read by the activities processor if the password contains "
The fix for this is simple - put addslashes before the password is read, and this fix is working in our production instance.Concept approvedtriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/216PHP Warning &quot;explode() expects parameter 2 to be string, array given&quot; for mul...2019-03-12T11:20:46ZjensschuppePHP Warning "explode() expects parameter 2 to be string, array given" for multi-value country fieldsDue to an unnecessary `explode()` [here](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/CustomValueTable.php#L127), a PHP warning is thrown, when trying to save a multi-select country custom field with multiple values given.
The assigned variable `$mulValues` is never used and possibly overwritten [here](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/CustomValueTable.php#L134) with the same `explode()` statement.
The line got added in [this](https://github.com/civicrm/civicrm-core/commit/ec28b24d87e6b51d4d933e3c440df41292467846#diff-927e742818deb9c89a00d2528e360bf0R125) commit without an apparent reason, so it should be removed.Due to an unnecessary `explode()` [here](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/CustomValueTable.php#L127), a PHP warning is thrown, when trying to save a multi-select country custom field with multiple values given.
The assigned variable `$mulValues` is never used and possibly overwritten [here](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/CustomValueTable.php#L134) with the same `explode()` statement.
The line got added in [this](https://github.com/civicrm/civicrm-core/commit/ec28b24d87e6b51d4d933e3c440df41292467846#diff-927e742818deb9c89a00d2528e360bf0R125) commit without an apparent reason, so it should be removed.sig:bugtriagedhttps://lab.civicrm.org/dev/core/-/issues/791Multiple form submits on contribution pages2019-03-12T12:21:27ZMartinMultiple form submits on contribution pagesThere have been 2 times (and possible more) where contribution pages have submitted more than once when a user filled them out. These have both been (on different pages) for a membership renewal using the "pay later" option. In one case there were about 6 contributions created, and 12 in the other.
This is what is showing in the apache log (edited to remove site info / ips, and removing css, etc):
`
[06/Mar/2019:14:37:19 +0000] "GET /civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605 HTTP/1.1" 200 23469 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:37:40 +0000] "GET /civicrm/ajax/l10n-js/en_US?r=0n8f3 HTTP/1.1" 200 2689 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:15 +0000] "GET /civicrm/payment/form?formName=Main&currency=CAD&&is_back_office=&id=7&processor_id=0&cid=605&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&payment_instrument_id=undefined&snippet=json HTTP/1.1" 200 2046 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 500 900 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
`
The following is in the apache error log:
`
[Wed Mar 06 14:40:25.937577 2019] [core:error] End of script output before headers: index.php, referer: https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605
`
The site has the Stripe and CiviDiscount extensions enabled.
Any help is much appreciated!There have been 2 times (and possible more) where contribution pages have submitted more than once when a user filled them out. These have both been (on different pages) for a membership renewal using the "pay later" option. In one case there were about 6 contributions created, and 12 in the other.
This is what is showing in the apache log (edited to remove site info / ips, and removing css, etc):
`
[06/Mar/2019:14:37:19 +0000] "GET /civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605 HTTP/1.1" 200 23469 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:37:40 +0000] "GET /civicrm/ajax/l10n-js/en_US?r=0n8f3 HTTP/1.1" 200 2689 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:15 +0000] "GET /civicrm/payment/form?formName=Main&currency=CAD&&is_back_office=&id=7&processor_id=0&cid=605&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&payment_instrument_id=undefined&snippet=json HTTP/1.1" 200 2046 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 302 619 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
[06/Mar/2019:14:39:21 +0000] "POST /civicrm/contribute/transact HTTP/1.1" 500 900 "https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
`
The following is in the apache error log:
`
[Wed Mar 06 14:40:25.937577 2019] [core:error] End of script output before headers: index.php, referer: https://mywebsite.com/civicrm/contribute/transact?reset=1&id=7&cs=114dc355fb504a48dddf1d51450c4a2d_1551882710_168&cid=605
`
The site has the Stripe and CiviDiscount extensions enabled.
Any help is much appreciated!needs:concept approvalneeds:steps to replicatetriagedtype:requesthttps://lab.civicrm.org/dev/core/-/issues/796Updating priceset when selected option is full2019-03-13T13:38:18ZwdecraeneUpdating priceset when selected option is fullYou want to edit as an admin the priceset of an participant, the option the participant selected is full.
![Schermafbeelding_2019-03-12_om_21.21.42](/uploads/4e6f018316f4f102805ad121f83f46d7/Schermafbeelding_2019-03-12_om_21.21.42.png)
You change the value to another option and save it.
![Schermafbeelding_2019-03-12_om_21.24.34](/uploads/cab5f64141209839934a3f517be84095/Schermafbeelding_2019-03-12_om_21.24.34.png)
After saving, the option did not change.
But, when you change the radio after the selected one it does save it.
Reason: behind the option which is selected and full, there is a hidden option field which is selected. When you select the option before this radio and post the form, the browser only post the last one (a radio field can only have one selected value). That is also the reason why the value is changed when you select the radio after the original one.
Solution ? No hidden/disabled options for admins? Should admins be able to override the max possibilities per participant?You want to edit as an admin the priceset of an participant, the option the participant selected is full.
![Schermafbeelding_2019-03-12_om_21.21.42](/uploads/4e6f018316f4f102805ad121f83f46d7/Schermafbeelding_2019-03-12_om_21.21.42.png)
You change the value to another option and save it.
![Schermafbeelding_2019-03-12_om_21.24.34](/uploads/cab5f64141209839934a3f517be84095/Schermafbeelding_2019-03-12_om_21.24.34.png)
After saving, the option did not change.
But, when you change the radio after the selected one it does save it.
Reason: behind the option which is selected and full, there is a hidden option field which is selected. When you select the option before this radio and post the form, the browser only post the last one (a radio field can only have one selected value). That is also the reason why the value is changed when you select the radio after the original one.
Solution ? No hidden/disabled options for admins? Should admins be able to override the max possibilities per participant?needs:concept approvalneeds:steps to replicatesig:bugtriagedhttps://lab.civicrm.org/dev/core/-/issues/794Expose address name in the invoice templates2019-03-13T13:39:29ZyashodhaExpose address name in the invoice templatesAllow *domain_address_name* to be used as address name in invoice template.Allow *domain_address_name* to be used as address name in invoice template.improvementneeds:concept approvaltriagedtype:proposalyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/782CiviMail not showing proper groups for multisite2019-03-13T17:54:53ZandyburnsCiviMail not showing proper groups for multisiteBecause groups are not tied to a domain, they are accessible to anyone. This means 1) they see groups that are irrelevant to them and 2) in CiviMail send mailings out to records who are not within their ACL control via this extension: https://civicrm.org/extensions/multisite-permissioning.
This leads to the question, how do we get more entities to be domain specific? There are some listed on the old documentation as desirable here: https://wiki.civicrm.org/confluence/display/CRMDOC/Multisites%2C+Multidomain%2C+and+Multilevel+ACLs#Multisites,Multidomain,andMultilevelACLs-FunctionalSeparationinMultisite, groups is not.Because groups are not tied to a domain, they are accessible to anyone. This means 1) they see groups that are irrelevant to them and 2) in CiviMail send mailings out to records who are not within their ACL control via this extension: https://civicrm.org/extensions/multisite-permissioning.
This leads to the question, how do we get more entities to be domain specific? There are some listed on the old documentation as desirable here: https://wiki.civicrm.org/confluence/display/CRMDOC/Multisites%2C+Multidomain%2C+and+Multilevel+ACLs#Multisites,Multidomain,andMultilevelACLs-FunctionalSeparationinMultisite, groups is not.Concept approvedtriagedtype:requesthttps://lab.civicrm.org/dev/core/-/issues/800Allow operator as a parameter for Advanced Filter in auto-complete Contact Re...2019-03-15T12:08:57ZyashodhaAllow operator as a parameter for Advanced Filter in auto-complete Contact Reference fieldCurrently you can specify Advanced filters for auto-complete Contact Reference fields
> EXAMPLE: To list Students in group 3: "action=get&group=3&contact_sub_type=Student"
But if I want to search all contacts with `contact_sub_type != 'Student'`
I propose that we pass operator something like` contact_sub_type_op = 'neq'`
which would do the same. This is consistent with what we are doing in reports as well.Currently you can specify Advanced filters for auto-complete Contact Reference fields
> EXAMPLE: To list Students in group 3: "action=get&group=3&contact_sub_type=Student"
But if I want to search all contacts with `contact_sub_type != 'Student'`
I propose that we pass operator something like` contact_sub_type_op = 'neq'`
which would do the same. This is consistent with what we are doing in reports as well.needs:concept approvaltriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/802Unsubscribe message doesn&#39;t display consistently2019-03-15T12:10:37ZRoseLaniganUnsubscribe message doesn't display consistentlyWhen an individual unsubscribes from a mailing group, they get a standard message confirmation message that says they have been unsubscribed (see image 001). However, the message specified in the Headers, Footers and Automated Messages list includes a link to resubscribe (image 002) that doesn't appear.
![image001](/uploads/737d703e38b8ec9a63b0baa549715a30/image001.jpg)
![image002](/uploads/457215465165297186362e2938ab07f8/image002.jpg)When an individual unsubscribes from a mailing group, they get a standard message confirmation message that says they have been unsubscribed (see image 001). However, the message specified in the Headers, Footers and Automated Messages list includes a link to resubscribe (image 002) that doesn't appear.
![image001](/uploads/737d703e38b8ec9a63b0baa549715a30/image001.jpg)
![image002](/uploads/457215465165297186362e2938ab07f8/image002.jpg)needs:concept approvaltriagedtype:proposalhttps://lab.civicrm.org/dev/drupal/-/issues/50Changing pages on Pagination from the Dashlet causes the report to go fullscreen2019-03-17T22:45:12ZmclubbChanging pages on Pagination from the Dashlet causes the report to go fullscreenAfter we updated to 5.10.3 our client reported that going to the next result (page) the dashlet would take over the full screen. There wasn't any way to minimize or close this if it was a modal. I have tested this out as well and I am able to replicate.
Drupal 7 (latest)
CiviCRM 5.10.3
To recreate:
* Create a report that will enable pagination and make sure you can add it to the dashboard
* Add the dashlet to the dashboard
* Click on the next page or some other page that is available for the report
* You should see that it goes full screen
ThanksAfter we updated to 5.10.3 our client reported that going to the next result (page) the dashlet would take over the full screen. There wasn't any way to minimize or close this if it was a modal. I have tested this out as well and I am able to replicate.
Drupal 7 (latest)
CiviCRM 5.10.3
To recreate:
* Create a report that will enable pagination and make sure you can add it to the dashboard
* Add the dashlet to the dashboard
* Click on the next page or some other page that is available for the report
* You should see that it goes full screen
Thanksneeds:concept approvalsig:bugtriagedhttps://lab.civicrm.org/dev/core/-/issues/804Address indiscrepancy in participant count in summary report - due to presenc...2019-03-17T23:01:25ZeileenAddress indiscrepancy in participant count in summary report - due to presence of currency in $0 participant recordsOpened this to track
https://github.com/civicrm/civicrm-core/pull/13037Opened this to track
https://github.com/civicrm/civicrm-core/pull/13037needs:concept approvaltriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/805CiviCRM cases don&#39;t appear on contact case tab if no activities2019-03-18T08:07:51ZAdam KwiatkowskiCiviCRM cases don't appear on contact case tab if no activitiesWhen viewing a client record, then clicking the Cases tab - The cases are not displayed if the case has no activities associated with it. This can happen if you don't have a standard timeline with the case, which typically has the open job activity.
Doing some debugging, the SQL join appears to be an INNER JOIN and not a LEFT JOIN for civicrm_activity. When changed to a LEFT JOIN, then the cases without activities show as the join doesn't filter by the join.
```
SELECT civicrm_case.id as case_id
FROM civicrm_contact contact_a
LEFT JOIN civicrm_phone
ON (contact_a.id = civicrm_phone.contact_id AND civicrm_phone.is_primary = 1)
LEFT JOIN civicrm_case_contact
ON civicrm_case_contact.contact_id = contact_a.id
INNER JOIN civicrm_case ON civicrm_case_contact.case_id = civicrm_case.id
LEFT JOIN civicrm_relationship case_relationship ON ( case_relationship.contact_id_a = civicrm_case_contact.contact_id AND case_relationship.contact_id_b = 1 AND case_relationship.case_id = civicrm_case.id )
LEFT JOIN civicrm_relationship_type case_relation_type ON ( case_relation_type.id = case_relationship.relationship_type_id AND case_relation_type.id = case_relationship.relationship_type_id )
LEFT JOIN civicrm_case_activity
ON civicrm_case_activity.case_id = civicrm_case.id
INNER JOIN civicrm_activity case_activity
ON ( civicrm_case_activity.activity_id = case_activity.id AND case_activity.is_current_revision = 1 )
LEFT JOIN civicrm_option_group option_group_activity_type
ON (option_group_activity_type.name = 'activity_type')
LEFT JOIN civicrm_option_value rec_activity_type ON (case_activity.activity_type_id = rec_activity_type.value AND option_group_activity_type.id = rec_activity_type.option_group_id )
LEFT JOIN civicrm_option_group option_group_case_status
ON (option_group_case_status.name = 'case_status')
LEFT JOIN civicrm_option_value case_status
ON (civicrm_case.status_id = case_status.value AND option_group_case_status.id = case_status.option_group_id )
LEFT JOIN civicrm_case_type ON civicrm_case.case_type_id = civicrm_case_type.id WHERE ( contact_a.id = '1' AND civicrm_case.is_deleted = 0 ) AND (contact_a.is_deleted = 0)
GROUP BY civicrm_case.id
```
Page: CRM_Case_BAO_CaseWhen viewing a client record, then clicking the Cases tab - The cases are not displayed if the case has no activities associated with it. This can happen if you don't have a standard timeline with the case, which typically has the open job activity.
Doing some debugging, the SQL join appears to be an INNER JOIN and not a LEFT JOIN for civicrm_activity. When changed to a LEFT JOIN, then the cases without activities show as the join doesn't filter by the join.
```
SELECT civicrm_case.id as case_id
FROM civicrm_contact contact_a
LEFT JOIN civicrm_phone
ON (contact_a.id = civicrm_phone.contact_id AND civicrm_phone.is_primary = 1)
LEFT JOIN civicrm_case_contact
ON civicrm_case_contact.contact_id = contact_a.id
INNER JOIN civicrm_case ON civicrm_case_contact.case_id = civicrm_case.id
LEFT JOIN civicrm_relationship case_relationship ON ( case_relationship.contact_id_a = civicrm_case_contact.contact_id AND case_relationship.contact_id_b = 1 AND case_relationship.case_id = civicrm_case.id )
LEFT JOIN civicrm_relationship_type case_relation_type ON ( case_relation_type.id = case_relationship.relationship_type_id AND case_relation_type.id = case_relationship.relationship_type_id )
LEFT JOIN civicrm_case_activity
ON civicrm_case_activity.case_id = civicrm_case.id
INNER JOIN civicrm_activity case_activity
ON ( civicrm_case_activity.activity_id = case_activity.id AND case_activity.is_current_revision = 1 )
LEFT JOIN civicrm_option_group option_group_activity_type
ON (option_group_activity_type.name = 'activity_type')
LEFT JOIN civicrm_option_value rec_activity_type ON (case_activity.activity_type_id = rec_activity_type.value AND option_group_activity_type.id = rec_activity_type.option_group_id )
LEFT JOIN civicrm_option_group option_group_case_status
ON (option_group_case_status.name = 'case_status')
LEFT JOIN civicrm_option_value case_status
ON (civicrm_case.status_id = case_status.value AND option_group_case_status.id = case_status.option_group_id )
LEFT JOIN civicrm_case_type ON civicrm_case.case_type_id = civicrm_case_type.id WHERE ( contact_a.id = '1' AND civicrm_case.is_deleted = 0 ) AND (contact_a.is_deleted = 0)
GROUP BY civicrm_case.id
```
Page: CRM_Case_BAO_Caseneeds:concept approvalsig:bugtriagedhttps://lab.civicrm.org/dev/core/-/issues/807Error in participant counts on events with waitlists2019-03-20T13:29:00ZCharlie DunlaveyError in participant counts on events with waitlistsThere seems to be a participant calculation error at a specific stage in the workflow for events using waitlists, which is making the waitlist feature unuseable.
When a place becomes available on an event with a waitlist, the reminder email is being sent correctly to the person at the top of the waitlist, but when this user clicks on the registration link in the email, they see the 'Oops, it looks like there are no spaces' message.
At the confirmation page stage, it looks like Civi is counting all participants as opposed to just those with counted set to true. Are you able to take a look?
Thank you,
CharlieThere seems to be a participant calculation error at a specific stage in the workflow for events using waitlists, which is making the waitlist feature unuseable.
When a place becomes available on an event with a waitlist, the reminder email is being sent correctly to the person at the top of the waitlist, but when this user clicks on the registration link in the email, they see the 'Oops, it looks like there are no spaces' message.
At the confirmation page stage, it looks like Civi is counting all participants as opposed to just those with counted set to true. Are you able to take a look?
Thank you,
Charlieneeds:concept approvalneeds:steps to replicatetriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/635Implement reconnect/replay-on-write for database connections2019-03-20T20:55:53ZtottenImplement reconnect/replay-on-write for database connectionsCurrently, CiviCRM always connects to a singular DSN. For epic:ro-db, we seek compatibility with a split DB architecture in which one routes MySQL requests to (a) read-only slave DBs and/or (b) read-write master DB. This issue specifically proposes a "reconnect-on-write" or "replay-on-write" (RPOW) mechanism as a general, global baseline.
## Technical Overview
One possible technique is to sprinkle flags/hints into the application to indicate which use-cases should be served by slave/rodb or by master/rwdb. *Some* of this sprinkling is likely happen, but we have a large, open-ended application (with several built-in subsystems and several third-party extensions/addons). Auditing all of these is somewhat daunting task.
RPOW aims to provide a *generic baseline* that relies primarily on MySQL semantics (and doesn't require auditing every use-case carefully). The general idea is:
1. Connect optimistically to the read-only slave (expecting a read-only use-case). We can continue using the RODB as long as requests are read-oriented (e.g. `SELECT`).
2. If there is an actual write operation (e.g. `UPDATE`), then reconnect to the read-write master.
Dynamically switching to the read-write master is not quite as simple as it sounds:
* Some SQL statements (eg `SET @foo` and `CREATE TEMPORARY TABLE`) can be legitimately used in a read-oriented operation (e.g. advanced querying/reporting) -- but they may also be prelude to a write-operation (e.g. building a temp-table with a list of targets and then updating each one). We allow these to execute on the RODB -- but, when/if we reconnect to RWDB, then we *replay* those statements.
* To support replay, we must be able to classify any SQL statement into one of three buckets:
* `READ` (Ex: `SELECT * FROM foo`): The SQL statement has no side-effects; it simply reads data.
* `BUFFER` (Ex: `SET @user_id = 123`): The SQL statement has no long-term, persistent side-effects; it can, however, have temporary side-effects during the present MySQL session.
* `WRITE` (Ex: `TRUNCATE foo`): The SQL statement has long-term, persistent side-effects and must be executed on the master. (Generally, if we can't demonstrate that something is `READ` or `BUFFER`, then we assume it is `WRITE`.)
* The MySQL query language has interesting edge-cases (e.g. `SELECT @foo := id FROM bar FOR UPDATE`) that should be handled correctly.
* We don't know anything about the delay in sync'ing between RODB and RWDB. After making a write, we'll continue sending all requests (reads or writes) to RWDB for some *period of time*. (Ex: After updating a contact in RWDB, the user's browser gets a cookie -- and, for the next 60 seconds, any additional reads should hit RWDB.)
## Limitations and Assumptions
* RPOW makes sense if user's are primarily reading from MySQL. Stock CiviCRM relies extensively on MySQL for caching and session-state, which leads to frequent writes. However, if you use the Redis integration for caches/sessions/prevnext, then this is significantly reduced.
* RPOW aims to *mitigate/reduce* the need for sprinkling use-case specific hints. However, there may still be scenarios where one wants to sprinkle hints. In particular: the contact-edit screen uses optimistic-locking (which reads the last-modified timestamp before authorizing updates); for correct oplocking, there should be a hint that any POST requests to the contact-edit screen need the RWDB.
## Relevant Tasks / Patches / Subtasks
The following are types of patches / subtasks we may expect:
* Adding a new DB driver -- an admin can opt-in to using RPOW behavior by setting `CIVICRM_DSN` to a special value (and registering DSNs for both RODBs and RWDB).
* Adding a unit-test to ensure correct classification of a range of SQL examples.
* Maintaining a cookie or session-variable to indicate that a user needs to be temporarily directed to RWDB by default.
* Updating existing use-cases to reduce gratuitous writes or to send hints about specific write-oriented use-cases.
NOTE: I've currently got a draft project in https://github.com/totten/rpow ; however, I'm filing this issue here because some of this work will need to come back into core.
## Pull Requests
* [#13394 - Reduce unnecessary SQL writes](https://github.com/civicrm/civicrm-core/pull/13394) (m)
* [#13500 - (REF) Add CRM_Utils_Cache::nack(). Use it for NaiveHasTrait](https://github.com/civicrm/civicrm-core/pull/13500) (m)
* [#13496 - Implement local array-cache for use with Redis/Memcache](https://github.com/civicrm/civicrm-core/pull/13496) (m)
* [#13489 - Deprecate CRM_Core_BAO_Cache for I/O. Optionally redirect I/O to Redis or Memcache. #13489 ](https://github.com/civicrm/civicrm-core/pull/13489) (m)
* [#13514 - CRM_Utils_Cache::nack() - Fix format](https://github.com/civicrm/civicrm-core/pull/13514) (m)Currently, CiviCRM always connects to a singular DSN. For epic:ro-db, we seek compatibility with a split DB architecture in which one routes MySQL requests to (a) read-only slave DBs and/or (b) read-write master DB. This issue specifically proposes a "reconnect-on-write" or "replay-on-write" (RPOW) mechanism as a general, global baseline.
## Technical Overview
One possible technique is to sprinkle flags/hints into the application to indicate which use-cases should be served by slave/rodb or by master/rwdb. *Some* of this sprinkling is likely happen, but we have a large, open-ended application (with several built-in subsystems and several third-party extensions/addons). Auditing all of these is somewhat daunting task.
RPOW aims to provide a *generic baseline* that relies primarily on MySQL semantics (and doesn't require auditing every use-case carefully). The general idea is:
1. Connect optimistically to the read-only slave (expecting a read-only use-case). We can continue using the RODB as long as requests are read-oriented (e.g. `SELECT`).
2. If there is an actual write operation (e.g. `UPDATE`), then reconnect to the read-write master.
Dynamically switching to the read-write master is not quite as simple as it sounds:
* Some SQL statements (eg `SET @foo` and `CREATE TEMPORARY TABLE`) can be legitimately used in a read-oriented operation (e.g. advanced querying/reporting) -- but they may also be prelude to a write-operation (e.g. building a temp-table with a list of targets and then updating each one). We allow these to execute on the RODB -- but, when/if we reconnect to RWDB, then we *replay* those statements.
* To support replay, we must be able to classify any SQL statement into one of three buckets:
* `READ` (Ex: `SELECT * FROM foo`): The SQL statement has no side-effects; it simply reads data.
* `BUFFER` (Ex: `SET @user_id = 123`): The SQL statement has no long-term, persistent side-effects; it can, however, have temporary side-effects during the present MySQL session.
* `WRITE` (Ex: `TRUNCATE foo`): The SQL statement has long-term, persistent side-effects and must be executed on the master. (Generally, if we can't demonstrate that something is `READ` or `BUFFER`, then we assume it is `WRITE`.)
* The MySQL query language has interesting edge-cases (e.g. `SELECT @foo := id FROM bar FOR UPDATE`) that should be handled correctly.
* We don't know anything about the delay in sync'ing between RODB and RWDB. After making a write, we'll continue sending all requests (reads or writes) to RWDB for some *period of time*. (Ex: After updating a contact in RWDB, the user's browser gets a cookie -- and, for the next 60 seconds, any additional reads should hit RWDB.)
## Limitations and Assumptions
* RPOW makes sense if user's are primarily reading from MySQL. Stock CiviCRM relies extensively on MySQL for caching and session-state, which leads to frequent writes. However, if you use the Redis integration for caches/sessions/prevnext, then this is significantly reduced.
* RPOW aims to *mitigate/reduce* the need for sprinkling use-case specific hints. However, there may still be scenarios where one wants to sprinkle hints. In particular: the contact-edit screen uses optimistic-locking (which reads the last-modified timestamp before authorizing updates); for correct oplocking, there should be a hint that any POST requests to the contact-edit screen need the RWDB.
## Relevant Tasks / Patches / Subtasks
The following are types of patches / subtasks we may expect:
* Adding a new DB driver -- an admin can opt-in to using RPOW behavior by setting `CIVICRM_DSN` to a special value (and registering DSNs for both RODBs and RWDB).
* Adding a unit-test to ensure correct classification of a range of SQL examples.
* Maintaining a cookie or session-variable to indicate that a user needs to be temporarily directed to RWDB by default.
* Updating existing use-cases to reduce gratuitous writes or to send hints about specific write-oriented use-cases.
NOTE: I've currently got a draft project in https://github.com/totten/rpow ; however, I'm filing this issue here because some of this work will need to come back into core.
## Pull Requests
* [#13394 - Reduce unnecessary SQL writes](https://github.com/civicrm/civicrm-core/pull/13394) (m)
* [#13500 - (REF) Add CRM_Utils_Cache::nack(). Use it for NaiveHasTrait](https://github.com/civicrm/civicrm-core/pull/13500) (m)
* [#13496 - Implement local array-cache for use with Redis/Memcache](https://github.com/civicrm/civicrm-core/pull/13496) (m)
* [#13489 - Deprecate CRM_Core_BAO_Cache for I/O. Optionally redirect I/O to Redis or Memcache. #13489 ](https://github.com/civicrm/civicrm-core/pull/13489) (m)
* [#13514 - CRM_Utils_Cache::nack() - Fix format](https://github.com/civicrm/civicrm-core/pull/13514) (m)Concept approvedepic:ro-dbsig:performancetriagedtype:paid-issue-queuetottentottenhttps://lab.civicrm.org/dev/core/-/issues/813Profile listings don&#39;t show some address/phone fields (all but &quot;main&quot;): work,...2019-03-21T08:55:25ZcalbasiProfile listings don't show some address/phone fields (all but "main"): work, home, etc. But I can see/edit it at contact recordAfter upgrade my CiviCRM (from 4.6.x to 5.10) in a Debian 8 server, with php 5.4 (I'm going to migrate to Debian 9/10 later, to meet php new requeriments) I get this error when render listings with phone/address fields:
Notice: Undefined property: CRM_Core_DAO::$Feina-phone-1 en CRM_Profile_Selector_Listings->getRows() (línea 659 de .../sites/all/modules/civicrm/CRM/Profile/Selector/Listings.php).
where "Feina" means "Work" on Catalan.
That is, I can render phone / address field if I choose "main" address/phone at profile builder, but not secondary fields (home/work/work2, etc).
But I can view/edit this info at contact record form, then, it's just a Profile listing error, what I think mean it's a bug/issue, and not just an isolated issue from my install.
I don't know if problem could be related with the use of other language than English or not.
Ps.: I've submitted a question at stackexchange, but not lucky
[there](https://civicrm.stackexchange.com/questions/28755/notice-undefined-property-crm-core-daofeina-phone-2-a-crm-profile-selector)After upgrade my CiviCRM (from 4.6.x to 5.10) in a Debian 8 server, with php 5.4 (I'm going to migrate to Debian 9/10 later, to meet php new requeriments) I get this error when render listings with phone/address fields:
Notice: Undefined property: CRM_Core_DAO::$Feina-phone-1 en CRM_Profile_Selector_Listings->getRows() (línea 659 de .../sites/all/modules/civicrm/CRM/Profile/Selector/Listings.php).
where "Feina" means "Work" on Catalan.
That is, I can render phone / address field if I choose "main" address/phone at profile builder, but not secondary fields (home/work/work2, etc).
But I can view/edit this info at contact record form, then, it's just a Profile listing error, what I think mean it's a bug/issue, and not just an isolated issue from my install.
I don't know if problem could be related with the use of other language than English or not.
Ps.: I've submitted a question at stackexchange, but not lucky
[there](https://civicrm.stackexchange.com/questions/28755/notice-undefined-property-crm-core-daofeina-phone-2-a-crm-profile-selector)needs:concept approvalneeds:steps to replicatetriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/762Financial transaction does not respect Payment Method when marking a contribu...2019-03-21T23:34:49ZguanhuanFinancial transaction does not respect Payment Method when marking a contribution as Completed**How it currently works**
Tested in the latest CiviCRM.
When marking a contribution to "Completed", a financial transaction is created. The transaction picks the default financial account as its debit account rather than taking the asset account assigned to the payment method specified in the contribution.
For example:
- payment method **Credit Card** has **1210 Credit Card Bank** assigned to it
- CiviCRM has **1200 Payment Processor Account** set as default account
- A pending contribution has payment method set to **Credit Card**
When editing the contribution and changing its status to **Completed**, a payment financial transaction is created and its debit account is **1200 Payment Processor Account**.
**How is should work**
When a contribution is marked as "Completed" in the back office forms without using a payment processor, the financial transaction should use the account assigned to the contribution payment method as its debit account.
For example:
- payment method **Credit Card** has **1210 Credit Card Bank** assigned to it
- CiviCRM has **1200 Payment Processor Account** set as default account
- A pending contribution has payment method set to **Credit Card**
When editing the contribution and changing its status to **Completed**, a payment financial transaction is created and its debit account should be **1210 Credit Card Bank**.**How it currently works**
Tested in the latest CiviCRM.
When marking a contribution to "Completed", a financial transaction is created. The transaction picks the default financial account as its debit account rather than taking the asset account assigned to the payment method specified in the contribution.
For example:
- payment method **Credit Card** has **1210 Credit Card Bank** assigned to it
- CiviCRM has **1200 Payment Processor Account** set as default account
- A pending contribution has payment method set to **Credit Card**
When editing the contribution and changing its status to **Completed**, a payment financial transaction is created and its debit account is **1200 Payment Processor Account**.
**How is should work**
When a contribution is marked as "Completed" in the back office forms without using a payment processor, the financial transaction should use the account assigned to the contribution payment method as its debit account.
For example:
- payment method **Credit Card** has **1210 Credit Card Bank** assigned to it
- CiviCRM has **1200 Payment Processor Account** set as default account
- A pending contribution has payment method set to **Credit Card**
When editing the contribution and changing its status to **Completed**, a payment financial transaction is created and its debit account should be **1210 Credit Card Bank**.Concept approvedcomp:CiviContributegit:civicrm-coresig:bugMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/641Case Activity Assignment Restriction2019-03-22T00:27:10ZshitijgCase Activity Assignment Restriction**Overview:**
We have had a few security complaints from a few clients using cases. They mistakenly assigned an activity to a contact who was not supposed to see the details of the activity.
**How it works right now**
Currently, a user can create and assign an activity to any CiviCRM contact. This in turn sends an email notification to the assignee. However, some users have reported that they mistakenly assigned activities to contacts with similar names which meant that someone who should not have access to any details of the activity got a link stating some basic details of the activity.
Whilst, the contact who received the email wasn't a CiviCRM user, so they couldn't not login and edit the activity, just some basic details in this case acted as a security breach as the table in the email already revealed more about the activity.
**New Implementation:**
We want to add the ability to restrict the assignment of case activities to a group.
Points to note- (UPDATED ON 07/01 to have this setting on the case type)
- This can live in the case type settings ie the user can define which group can an activity be assigned to per case type (civicrm/a/#/caseType/n where 'n' is the ID of the case type)
- We can have 2 options for the field "Case activity assignment to" - 1. All Users (DEFAULT) 2. Restricted by group
- On selecting 2. - the user will be able to select a group
- Once a group is selected, the user will only be able to assign a case activity to contacts within the selected group
- If an activity from outside cases is "Filed" on case - and if the assignee is not a part of that group - there should not be any new notifications going to the assignee (this is already working this way ie no notifications are sent to the assignee on filing an out of case activity to a case)
Feel free to reach out to me on Mattermost if you need any clarifications.
Thanks**Overview:**
We have had a few security complaints from a few clients using cases. They mistakenly assigned an activity to a contact who was not supposed to see the details of the activity.
**How it works right now**
Currently, a user can create and assign an activity to any CiviCRM contact. This in turn sends an email notification to the assignee. However, some users have reported that they mistakenly assigned activities to contacts with similar names which meant that someone who should not have access to any details of the activity got a link stating some basic details of the activity.
Whilst, the contact who received the email wasn't a CiviCRM user, so they couldn't not login and edit the activity, just some basic details in this case acted as a security breach as the table in the email already revealed more about the activity.
**New Implementation:**
We want to add the ability to restrict the assignment of case activities to a group.
Points to note- (UPDATED ON 07/01 to have this setting on the case type)
- This can live in the case type settings ie the user can define which group can an activity be assigned to per case type (civicrm/a/#/caseType/n where 'n' is the ID of the case type)
- We can have 2 options for the field "Case activity assignment to" - 1. All Users (DEFAULT) 2. Restricted by group
- On selecting 2. - the user will be able to select a group
- Once a group is selected, the user will only be able to assign a case activity to contacts within the selected group
- If an activity from outside cases is "Filed" on case - and if the assignee is not a part of that group - there should not be any new notifications going to the assignee (this is already working this way ie no notifications are sent to the assignee on filing an out of case activity to a case)
Feel free to reach out to me on Mattermost if you need any clarifications.
ThanksConcept approvedtriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/816Contribution Details Report double amount when Credit Card Type Column is sho...2019-03-24T18:12:53ZScottyPspulver@ibafriends.orgContribution Details Report double amount when Credit Card Type Column is shown and Contribution was changedWhen running a Contribution Details report it seems to double the amount of the contribution when you enable the Credit Card Type column and have changed the Contribution amount. See in the attached screenshot from Sandbox. But I can replicated in 5.11 and 5.10.3 with Drupal 7.65 on Apache with PHP 5.6.39 and 5.5.62 MySQL.
To replicate:
1) Enter Contribution with Total amount for $5 then save
2) Edit Contribution with Total amount to $10 then save
3) Run Contribution Details with Credit Card Type column (screenshot with ($20) and without $10)
Hopefully I'm not missing something and this is actually a bug. Thanks!
![WithCreditCardType](/uploads/0181982614aa26c60e5da0fa43b33fac/WithCreditCardType.png)
![WithoutCreditCardType](/uploads/bc2bd115149d90b9c10eb119b03fe59f/WithoutCreditCardType.png)
![Contribution](/uploads/020b93143fc4d5ff5360bd839990c1fa/Contribution.png)When running a Contribution Details report it seems to double the amount of the contribution when you enable the Credit Card Type column and have changed the Contribution amount. See in the attached screenshot from Sandbox. But I can replicated in 5.11 and 5.10.3 with Drupal 7.65 on Apache with PHP 5.6.39 and 5.5.62 MySQL.
To replicate:
1) Enter Contribution with Total amount for $5 then save
2) Edit Contribution with Total amount to $10 then save
3) Run Contribution Details with Credit Card Type column (screenshot with ($20) and without $10)
Hopefully I'm not missing something and this is actually a bug. Thanks!
![WithCreditCardType](/uploads/0181982614aa26c60e5da0fa43b33fac/WithCreditCardType.png)
![WithoutCreditCardType](/uploads/bc2bd115149d90b9c10eb119b03fe59f/WithoutCreditCardType.png)
![Contribution](/uploads/020b93143fc4d5ff5360bd839990c1fa/Contribution.png)needs:concept approvalsig:bugtriagedhttps://lab.civicrm.org/dev/core/-/issues/815Define activity types which appear in the contact quick actions list via a se...2019-03-25T02:36:24ZjamienovickDefine activity types which appear in the contact quick actions list via a setting on the activity type screen**How it works currently:**
All activity types that have Component set as Contacts and Cases will appear in the Contact actions drop down.
**How it should work:**
Users should be able to be specify that an activity type will not be shown in the contact action drop down, even if they have set the Component to be Contacts and Cases.**How it works currently:**
All activity types that have Component set as Contacts and Cases will appear in the Contact actions drop down.
**How it should work:**
Users should be able to be specify that an activity type will not be shown in the contact action drop down, even if they have set the Component to be Contacts and Cases.needs:concept approvaltriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/115Proposal - create fields array standard &amp; generic field template/s for it &amp; f...2019-03-25T09:44:19ZeileenProposal - 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 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',
]);
}
```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',
]);
}
```Concept approvedimprovementtriagedtype:proposalhttps://lab.civicrm.org/dev/core/-/issues/820Send cancel request checkbox is tightly coupled to the ability to cancel recu...2019-03-26T19:55:21ZeileenSend cancel request checkbox is tightly coupled to the ability to cancel recurring contributions- but probably shouldn't beThe checkbox is shown because of
```
if ($this->_paymentProcessorObj->supports('cancelRecurring')) {
$params['send_cancel_request'] = 1;
}
```
However for many, perhaps most recurring subscriptions the checkbox is inappropriate as we are just changing the value in the contribution_recur table. We should be able to toggle those separately....
@mattwire add a new supportsNotifyGatewayOfRecurringChanges ?The checkbox is shown because of
```
if ($this->_paymentProcessorObj->supports('cancelRecurring')) {
$params['send_cancel_request'] = 1;
}
```
However for many, perhaps most recurring subscriptions the checkbox is inappropriate as we are just changing the value in the contribution_recur table. We should be able to toggle those separately....
@mattwire add a new supportsNotifyGatewayOfRecurringChanges ?needs:concept approvaltriagedtype:proposal