Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-12-16T13:14:52Zhttps://lab.civicrm.org/dev/drupal/-/issues/170kcfinder error 5002021-12-16T13:14:52Zolivierkcfinder error 500Civicrm 5.43 and 5.44 under Drupal 8, launching kcfinder from ckeditor give an 500 error.
Php script integration/civicrm.php try to call civicrm.config.php located in web/libraries/civicrm/, and this file does not exist.
Copying this fil...Civicrm 5.43 and 5.44 under Drupal 8, launching kcfinder from ckeditor give an 500 error.
Php script integration/civicrm.php try to call civicrm.config.php located in web/libraries/civicrm/, and this file does not exist.
Copying this file from an Drupal 7 installation is not sufficent, because civicrm.settings.php is not searched in correct location.
```
--- ../../mcm65/sites/all/modules/civicrm/civicrm.config.php 2021-11-15 21:42:13.000000000 +0100
+++ libraries/civicrm/civicrm.config.php 2021-12-07 21:14:33.380121826 +0100
@@ -87,6 +87,11 @@
return $confdir;
}
+ if (file_exists($_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'sites' . DIRECTORY_SEPARATOR . 'default' .
+ DIRECTORY_SEPARATOR . 'civicrm.settings.php')) {
+ return $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'sites' . DIRECTORY_SEPARATOR . 'default';
+ }
+
if (!file_exists($confdir) && !$skipConfigError) {
echo "Could not find valid configuration dir, best guess: $confdir<br/><br/>\n";
exit();
```
Another point, .htaccess in /web directory Deny access to most php files in public directory.
We must allow access to php files under kcfinder directory :
```
# For security reasons, deny access to other PHP files on public sites.
# Note: The following URI conditions are not anchored at the start (^),
# because Drupal may be located in a subdirectory. To further improve
# security, you can replace '!/' with '!^/'.
# Allow access to PHP files in /core (like authorize.php or install.php):
RewriteCond %{REQUEST_URI} !/core/[^/]*\.php$
# Allow access to test-specific PHP files:
RewriteCond %{REQUEST_URI} !/core/modules/system/tests/https?.php
# Allow access to Statistics module's custom front controller.
# Copy and adapt this rule to directly execute PHP files in contributed or
# custom modules or to run another PHP application in the same directory.
RewriteCond %{REQUEST_URI} !/core/modules/statistics/statistics.php$
RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/[a-z_]+\.php$
RewriteCond %{REQUEST_URI} !/libraries/civicrm/packages/kcfinder/.*/[a-z_]+\.php$
# Deny access to any other PHP files that do not match the rules above.
# Specifically, disallow autoload.php from being served directly.
RewriteRule "^(.+/.*|autoload)\.php($|/)" - [F]
```https://lab.civicrm.org/dev/user-interface/-/issues/44Custom Field Groups Screen - Flip "Preview" and "Settings"2021-12-26T21:28:17ZJonGoldCustom Field Groups Screen - Flip "Preview" and "Settings"This is an "is it everyone or just me" situation - and I think we need to ask folks who are newer to CiviCRM. But personally, I don't use the "Preview" link on the Custom Field Groups, but I *do* use "Settings". It's pretty quick to fl...This is an "is it everyone or just me" situation - and I think we need to ask folks who are newer to CiviCRM. But personally, I don't use the "Preview" link on the Custom Field Groups, but I *do* use "Settings". It's pretty quick to flip them, so mainly looking for UX feedback.
@bgm Do you have the ability to grep the web server logs for Spark over a long enough time period to see which link is used more by Spark users?
More broadly - I think it's worth discussing Spark as a platform for collecting anonymized user behavior data (with consent and transparency obviously).JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/57Payments - Where do we store IDs from payment processor?2022-01-04T06:27:07Zmattwiremjw@mjwconsult.co.ukPayments - Where do we store IDs from payment processor?On contributions there are two fields that can be used to store unique values - trxn_id and invoice_id. trxn_id is the only one that we can actually because the workflows ignore invoice_id in various places. For recurring contributions...On contributions there are two fields that can be used to store unique values - trxn_id and invoice_id. trxn_id is the only one that we can actually because the workflows ignore invoice_id in various places. For recurring contributions we have trxn_id and processor_id and here we have to set both to the same value because they are used inconsistently in the code. Then there are the individual payments which can store their own trxn_id.
Looking at Stripe we have:
* `charge_id` - changes each time a payment is attempted - matches best to `civicrm_financial_trxn.trxn_id` (but currently we save on civicrm_contribution.trxn_id).
* `invoice_id` - may have multiple charge_id's for example if a payment attempt fails and is retried. So this should really be the trxn_id on the contribution (we don't currently store it).
* `subscription_id` - for a recurring contribution this represents the plan so maps directly to `civicrm_contribution_recur` and could be saved in either `civicrm_contribution_recur.trxn_id` or `civicrm_contribution_recur.processor_id`.
The problem is that the way CiviCRM works internally (and API functions such as Contribution.completetransaction don't really allow us to work in the way we'd like).
UPDATE - the resolution here has been to
1) Add a field order_reference to the civicrm_financial_trxn table. The reason for adding is to this table even though it 'represents' the contribution / order is that it's possible not all payments on one contribution are by the same processor - hence it's up to the processor to manage this field
2) Matt felt that civicrm_financial_trxn.result_code met his needs for a descriptionmattwiremjw@mjwconsult.co.ukmattwiremjw@mjwconsult.co.ukhttps://lab.civicrm.org/dev/user-interface/-/issues/3Support Menu Addition - Bug Reporting2022-01-04T20:14:54ZrebeccatregennaSupport Menu Addition - Bug ReportingAdd menu option under 'Support' titled 'Report an issue' linking to existing 'View issues and report bugs'Add menu option under 'Support' titled 'Report an issue' linking to existing 'View issues and report bugs'https://lab.civicrm.org/dev/translation/-/issues/74ts() - Allow symbolic placeholders2022-01-27T13:24:34Ztottents() - Allow symbolic placeholdersOverview
---------
When writing translatable strings, placeholders must be numeric.
This leads to some quirky strings - eg if you're outputting a title and subtitle ("Some Chapter: Some Section"), the only way to encode that is `ts('%1...Overview
---------
When writing translatable strings, placeholders must be numeric.
This leads to some quirky strings - eg if you're outputting a title and subtitle ("Some Chapter: Some Section"), the only way to encode that is `ts('%1: %2')`. This string should be translatable because the layout is language dependent (eg LTR/RTL; eg punctuation-preferences), but the exported string will become meaningless when presented in Transifex (or similar). And it may be confused with other/similar strings.
Current behavior
-----------------
The function `ts(string $str, array $params)` accepts the following `$params`:
* Functional params (`count`, `plural`, `context`, `domain`, `escape`, `skip_translation`)
* Substitution params (numeric keys; `0`, `1`, `2`, ...)
As in:
```php
echo ts('Hello, %1!', [
1 => $name,
]);
echo '<li>' . ts('%1: %2', [
1 => $title,
2 => $subtitle,
]) . '</li>';
echo ts('The directory %1 is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %1. Please check your file permissions.',
'count' => count($notWritableDirs),
1 => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts 1=Bob}Hello %1!{/ts}
<li>{ts 1="Title" 2="Subtitle"}%1: %2{/ts}</li>
```
~~Proposed behavior (draft 1; symbol-prefix)~~
-----------------
Any `$params` which begin with a symbol (`%`, `_`, `{`, `@`, etc) will be used for variable substitution.
The earlier examples remain valid. Additionally, these examples are also valid:
```php
echo ts('Hello, %name!', [
'%name' => $name,
]);
echo '<li>' . ts('%title: %subtitle', [
'%title' => $title,
'%subtitle' => $subtitle],
) . '</li>';
echo ts('The directory %dir is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %dir. Please check your file permissions.',
'count' => count($notWritableDirs),
'%dir' => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts _NAME_=Bob}Hello _NAME_!{/ts}
<li>{ts _title_="Foo" _subtitle_="Bar"}_title_: _subtitle_{/ts}</li>
```
Proposed behavior (draft 2; capitalization-based)
-----------------
Any `$params` which begin with a capital letter (`[A-Z]`) will be used for variable substitution.
```php
echo ts('Hello, %NAME!', [
'NAME' => $name,
]);
echo '<li>' . ts('%TITLE: %SUBTITLE', [
'TITLE' => $title,
'SUBTITLE' => $subtitle],
) . '</li>';
echo ts('The directory %DIR is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %DIR. Please check your file permissions.',
'count' => count($notWritableDirs),
'DIR' => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts NAME=Bob}Hello %NAME!{/ts}
<li>{ts TITLE="Foo" SUBTITLE="Bar"}%TITLE: %SUBTITLE{/ts}</li>
```
Comments
---------
Either draft (using symbol-prefix or using uppercase) should avoid conflicts with existing strings+params. (Existing params do not begin with symbols and they are not uppercase.)
A couple factors in choosing a symbol:
* Using `%` is most consistent with current `ts()` style.
* `ts()` is used in multiple programming languages. Each has different compatibility/constraints.
* Pure PHP and pure JS are fairly flexible (`%FOO`, `{{FOO}}`, `_FOO_`, etc)
* Smarty-HTML (`{ts KEY=VALUE}...{/ts}`) is pretty limited. The bottleneck is how it parses the `KEY`.
* Angular-HTML (`{{ts('...')}}`) is in the middle. It's OK for `{{ts('%FOO')}}`, `{{ts('_FOO_')}}`, but I wouldn't count on `{{ts('{{FOO}}')}}`.
* If you want one symbol that works everywhere, `_` is probably it.
* Being flexible about symbol may be good for compatibility in the most contexts.
I suppose that the uppercase approach constrains style a bit, but maybe that's a good thing - ie you get more consistency in how `ts()` looks across environments.
Questions
---------
Are there any constraints in other layers -- eg Transifex, civistrings -- which would prevent this?
As far as I know, the only constraints which require using numeric-keys are baked into `ts()` itself.https://lab.civicrm.org/dev/drupal/-/issues/173Leaking cacheability metadata2022-02-09T22:36:58ZfkohrtLeaking cacheability metadataAfter installing CiviCRM 5.45 on a fresh Drupal 9.3.2 running on Ubuntu 20.04.3 LTS, the [SAML Authentication](https://www.drupal.org/project/samlauth) module issues a warning after every successful authentication event:
> While process...After installing CiviCRM 5.45 on a fresh Drupal 9.3.2 running on Ubuntu 20.04.3 LTS, the [SAML Authentication](https://www.drupal.org/project/samlauth) module issues a warning after every successful authentication event:
> While processing SAML authentication response, code leaked cacheability metadata. This indicates a bug somewhere (but it is hard to pinpoint where): if the same code is called in other scenarios too, it may cause fatal crashes, or bloat the render cache unnecessarily. Please investigate. Metadata: i:6;:O:37:"Drupal\Core\Render\BubbleableMetadata":4:{s:16:"*cacheContexts";a:0:{}s:12:"*cacheTags";a:0:{}s:14:"*cacheMaxAge";i:-1;s:14:"*attachments";a:0:{}}
One of the maintainers of the `samlauth` module explains in a corresponding ticket:
> the samlauth module isn't leaking metadata. It's detecting that some other code in your website, which was executed during the login process, is leaking metadata and should be fixed.
>
> — roderik, “[Code leaked cacheability metadata](https://www.drupal.org/project/samlauth/issues/3232577)”, [comment #4](https://www.drupal.org/project/samlauth/issues/3232577#comment-14354950)
Before installing CiviCRM, no warnings appeared in the log, therefore I'd say the appearance of the warnings somehow correspond to the fact that CiviCRM has been installed: CiviCRM code for Drupal might leak cacheability metadata.https://lab.civicrm.org/dev/user-interface/-/issues/33Theming meta issue2022-02-27T23:34:43ZeileenTheming meta issueI've created this issue so we can have somewhere to put the link to the theming presentation that took place this week (once it's available).
I would encourage people to link to other issues or repositories discussed as part of do-ocrac...I've created this issue so we can have somewhere to put the link to the theming presentation that took place this week (once it's available).
I would encourage people to link to other issues or repositories discussed as part of do-ocracy week from here too.https://lab.civicrm.org/dev/drupal/-/issues/175Call to deprecated function CRM_Contribute_PseudoConstant::pcpStatus in drupa...2022-03-08T14:11:00ZDaveDCall to deprecated function CRM_Contribute_PseudoConstant::pcpStatus in drupal 7 views modulehttps://civicrm.stackexchange.com/questions/41350/why-am-i-getting-deprecated-function-warnings
Coming from https://github.com/civicrm/civicrm-drupal/blob/e22d89a50108a2b4da99e971d0fdcdd656edd56c/modules/views/civicrm/civicrm_handler_fi...https://civicrm.stackexchange.com/questions/41350/why-am-i-getting-deprecated-function-warnings
Coming from https://github.com/civicrm/civicrm-drupal/blob/e22d89a50108a2b4da99e971d0fdcdd656edd56c/modules/views/civicrm/civicrm_handler_filter_pseudo_constant.inc#L45
`$this->_pseudo_constant = call_user_func_array($this->definition['pseudo class'] . "::" . $this->definition['pseudo method'], $pseudo_args);`
```
1 .../sites/all/modules/civicrm/CRM/Contribute/PseudoConstant.php(352): CRM_Core_Error::deprecatedFunctionWarning("Function pcpStatus will be removed")
2 .../sites/all/modules/civicrm/drupal/modules/views/civicrm/civicrm_handler_filter_pseudo_constant.inc(45): CRM_Contribute_PseudoConstant::pcpStatus()
3 .../sites/all/modules/views/includes/handlers.inc(65): civicrm_handler_filter_pseudo_constant->construct()
4 .../sites/all/modules/views/includes/handlers.inc(87): _views_create_handler((Array:8), "handler", "filter")
5 .../sites/all/modules/views/views.module(1399): _views_prepare_handler((Array:8), (Array:18), "status", "filter")
6 .../sites/all/modules/date/date_views/includes/date_views_fields.inc(59): views_get_handler("civicrm_pcp", "status", "filter")
7 .../sites/all/modules/date/date_views/date_views.module(156): _date_views_fields("civicrm_contact")
8 .../sites/all/modules/calendar/includes/calendar.views_template.inc(37): date_views_fields("civicrm_contact")
9 .../sites/all/modules/views/views.module(1520): calendar_views_templates()
10 .../sites/all/modules/views/views_ui.module(56): views_get_all_templates()
11 .../includes/menu.inc(2831): views_ui_menu()
12 .../includes/menu.inc(2794): menu_router_build()
13 .../includes/menu.inc(468): menu_rebuild()
14 .../includes/menu.inc(1779): menu_get_item()
15 .../includes/menu.inc(1794): menu_get_custom_theme(TRUE)
16 .../includes/common.inc(5402): menu_set_custom_theme()
17 .../includes/bootstrap.inc(2602): _drupal_bootstrap_full()
18 .../index.php(20): drupal_bootstrap(7)
19 {main}
```https://lab.civicrm.org/dev/translation/-/issues/75Translatable fields within Extension table2022-04-21T20:39:46ZseamusleeTranslatable fields within Extension tableAt present the CiviCRM i18n widget code and also the i10n schema code depend on the functions in the schema structure file returning an array of fields or html widgets. The Schema Structure file does not contain any information about tab...At present the CiviCRM i18n widget code and also the i10n schema code depend on the functions in the schema structure file returning an array of fields or html widgets. The Schema Structure file does not contain any information about tables other than core tables so for example in the JMA Grant Applications extension if we wanted to make the title or the introductory text field translatable we would have to hack the schema structure file.
I would like to propose that we create 3 new Events or similar to handle altering the fields, indices and widgets functions in the schema structure file.https://lab.civicrm.org/dev/release/-/issues/18Scheduling/workflow for security updates of dependencies2022-04-29T08:58:12ZtottenScheduling/workflow for security updates of dependencies# Synopsis
The workflow for *first-party/in-house* security updates and the workflow for *third-party/upstream* security updates are qualitatively different
The question of this issue is: Do we keep one general policy/schedule for both...# Synopsis
The workflow for *first-party/in-house* security updates and the workflow for *third-party/upstream* security updates are qualitatively different
The question of this issue is: Do we keep one general policy/schedule for both kinds of security issues, or do we have a more nuanced policy that distinguishes between them?
# Background
CiviCRM's policy for scheduling/workflow on security updates has a few key elements:
* Report and discuss vulnerabilities privately
* Release updates on a designated release window (the first/third Wed of each month)
* Make an effort to pre-announce (often 1-4 weeks in advance)
Those bullets are based on the premise that we control the process for disclosure/development/etc. This is true and appropriate for the common case where the security vulnerability originates in code maintained directly by CiviCRM.
But there is another common case: *dependencies* ("libraries", "packages", "subpackages", etc) used by CiviCRM and maintained by another group. These break the bullet-points from above:
* The purpose of upstream's public advisory is *to notify people like us*. The issue is necessarily public when we get the information.
* There are several different upstreams. Their release scheduling is (on the whole) fluid - some have release-windows; some don't; some make pre-announcements; some don't; each of those policies may change over time.
* The vulnerability is public. Delaying the release (in service of a pre-announcement/spin-up period) exacerbates the risk exposure. We don't want our scheduling to add extra exposure.
The security updates of a dependency affect CiviCRM in a few ways. Anyone reading this probably has some understanding already. But just to be complete, those effects include:
* Dependency-updates require some correlated change in how we use that dependency. In the best case, that just means metadata (eg `composer.json`, `composer.lock`) - but it can also be much more involved. It varies case-by-case.
* Several artifacts need to be republished when a dependency changes (notably the tarballs/zipballs for WP/D7/BD/J - but also any images published via docker, etc).
# Proposal
Security fixes _that have been previously published by an upstream vendor_ should be assimilated through CiviCRM's public development channels (Gitlab/Github/Mattermost/etc). The process should closely match the process for patch-releases that fix recent-regressions:
* Like a regular patch-release...
* Any patches/PRs should be submitted to the RC's public queue.
* After approving the RC PR, then backport to stable/ESR. (Only backport if we believe it to be "likely" exploitable.)
* Discussion about testing, `r-run`, compatibility, etc can happen in the public PR.
* We do not need to assign a CIVI-SA-* identifier or write an "advisory" record.
* In addition, there are extra bits...
* We'll send a mailblast when the stable/ESR updates are published.
* Release notes should highlight the "Security" issue as distinct from any other "Bug fix" issues. They should link to upstream's advisory (in addition to the usual Github/Gitlab links for Civi).
* In the public media, don't discuss how to specifically exploit the vulnerability. If that requires discussion, go to private Mattermost (`security` and/or direct-message). The public PR may have general claims (eg "I have successfully exploited this on my local system"; or "Alice, Bob, and Carol discussed on security channel - and all felt it is probably exploitable.")
* Backports for stable and ESR will be done in parallel. (They may be done by different people).
All other security issues (ie *first-party vulnerabilities; unpublished third-party vulnerabilities; uninvestigated vulnerabilities*) should continue through the current (private) workflows.
We should update https://civicrm.org/security to indicate this distinction.
# Rationale
* If a black hat is motivated enough to monitor CiviCRM's issue/PR queue for heads-up about CiviCRM vulnerabilities, then they can just as easily monitor the official release feeds for `dompdf`, `ckeditor`, etc.
* Github's "dependabot" is already likely to post public PRs when there's a published vulnerability affecting a CiviCRM dependency.
* Pro-active contributors will find it natural to raise these issues publicly (because they're already public).
* This change should reduce typical turn-around-time / duration-of-exposure for this type of issue. (*Compare: 2 weeks vs 0-3 days*)
* Routing dependency-updates through the private security medium adds noise to the private tracker without adding much security benefit.
# Other thoughts
Microsoft made "Patch Tuesday" famous. But they generally own all their dependencies.
Drupal has landed on "third Wed" as their release-window. However, they appear to make an exception when a third-party library publishes outside their preferred schedule (ex: https://www.drupal.org/sa-core-2022-006).
If we relax the scheduling on dependency updates, then we don't need to keep 1st Wed on the books. CiviCRM-specific fixes could be like Drupal -- strictly third Wed.
Anecdotally, I feel upstream announcements land on a weekday (esp Tue/Wed/Thu) -- and this lines up the interest of deployers. We could lean into this (eg dependency updates only happen on weekdays).
Note: Backdrop's release-window is _any Wed_. AFAICS, WordPress, Joomla, and PHP don't have formal release-windows. Based on skimming advisories, Joomla has a strong Tue bias. WP+PHP float around. (Between them, I skimmed ~20 prior releases, and there was only one that landed on a weekend.)https://lab.civicrm.org/dev/drupal/-/issues/177Cannot resolve path using "cms.root.url"2022-04-29T09:11:35ZalmadorxCannot resolve path using "cms.root.url"Hi! I'm having the issue with
```
In Paths.php line 140:
Cannot resolve path using "cms.root.url"
```
I'm using Drupal 9 and the last version of CiviCRM
I've tried the solution from here
([regression `cv` fails on CiviCRM 5.15.0](htt...Hi! I'm having the issue with
```
In Paths.php line 140:
Cannot resolve path using "cms.root.url"
```
I'm using Drupal 9 and the last version of CiviCRM
I've tried the solution from here
([regression `cv` fails on CiviCRM 5.15.0](https://lab.civicrm.org/dev/drupal/-/issues/75))
\vendor\civicrm\civicrm-core\CRM\Utils\System\Drupal8.php:
` public function getCurrentLanguage() {
// Drupal might not be bootstrapped if being called by the REST API.
if (!class_exists('Drupal') || !\Drupal::hasContainer()) {
return NULL;`
I've replaced _return NULL;_ with _return $url;_ but that doesn't solved the issue.https://lab.civicrm.org/dev/financial/-/issues/144Figure out if core processors actually work.....2022-05-19T22:31:00ZeileenFigure out if core processors actually work.....The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by...The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by Brian Civi Version not mentioned) |
| PayflowPro| broken? (Reported as working as of 5.19 by Nicholas) (As of 5.38 Migrated to a core extension with unit tests) |
| PaymentExpress| definitely broken / removed|
| PayJunction| broken? |
| Paypal| works/tested |
| Realex| likely works, have seen gitlabs |
I think we should try to find out about the ones that might be broken with a view to either
1) bring them under CI & move to an extension (per Eway) OR
2) remove them from core
Other than pinging people like @lcdweb to see if they use any my other idea is to add a check or preUpgrade message to try to get people to let us know.
@seamusleehttps://lab.civicrm.org/dev/financial/-/issues/87Partial Refunds2022-06-14T18:38:44Zmattwiremjw@mjwconsult.co.ukPartial RefundsStripe supports partial refunds via the Stripe Dashboard. I think other processors support similar.
To record a partial refund in CiviCRM we can record a negative payment on the contribution using API `Payment.create`.
Currently nothin...Stripe supports partial refunds via the Stripe Dashboard. I think other processors support similar.
To record a partial refund in CiviCRM we can record a negative payment on the contribution using API `Payment.create`.
Currently nothing changes on the contribution:
* Total amount still shows the full amount but payments are recorded correctly so the sum of payments does not equal the contribution total amount.
* Contribution status remains Completed.
What should happen(?):
* A partial refund means that the total_amount paid, tax_amount and the fee_amount paid may be reduced.
* The contribution status is no longer "Completed" and should be `Partially refunded` (does not exist)? `Partially paid` (already exists).
* The `Financial Type` should be displayed correctly for the refund payment.
Currently, viewing a contribution, either in the summary or detail gives no indication of the actual amount paid:
![image](/uploads/39a50dd48d946207feda438321850a39/image.png)
![image](/uploads/63cc3abf7df50ac1babcbff85f2d4c86/image.png)
@JoeMurray @eileen @artfulrobot @ayduns Thoughts please?https://lab.civicrm.org/dev/financial/-/issues/202Unable to update recurring amount when using Sales Tax2022-08-03T15:19:05ZKarinGUnable to update recurring amount when using Sales TaxHitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/...Hitting Edit on the template contribution (with or without line item editor extension - June 2022 version) -> saving it [multiple times] -> does not update the amount in the recurring series -> note the mismatches of amounts:
![image](/uploads/8280ff94ddb4e66ba1368e64c1d4b72a/image.png)https://lab.civicrm.org/dev/joomla/-/issues/16[Joomla 4.0] Warnings when CiviCRM is uninstalled2022-08-12T05:14:12ZAndrew Thompson[Joomla 4.0] Warnings when CiviCRM is uninstalledTwo PHP warnings are displayed when uninstalling CiviCRM from Joomla 4.0 alpha 11:
```
Warning: require_once(CRM/Utils/String.php): failed to open stream: No such file or directory in /var/www/html/j4/administrator/components/com_civic...Two PHP warnings are displayed when uninstalling CiviCRM from Joomla 4.0 alpha 11:
```
Warning: require_once(CRM/Utils/String.php): failed to open stream: No such file or directory in /var/www/html/j4/administrator/components/com_civicrm/script.civicrm.php on line 226
```
```
Fatal error: require_once(): Failed opening required 'CRM/Utils/String.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/j4/administrator/components/com_civicrm/script.civicrm.php on line 226
```Joomla 4 Integrationhttps://lab.civicrm.org/dev/financial/-/issues/121Financial Type ACLs don't work on soft credits2022-08-17T22:07:10ZJonGoldFinancial Type ACLs don't work on soft creditsTo replicate:
* Create a soft credit on any contribution. Note the financial type.
* Enable Financial ACLs.
* Log in as a user who doesn't have permission to view the financial type noted above.
* If you're using `civicrm-buildkit`, an...To replicate:
* Create a soft credit on any contribution. Note the financial type.
* Enable Financial ACLs.
* Log in as a user who doesn't have permission to view the financial type noted above.
* If you're using `civicrm-buildkit`, any non-administrative user who can view CiviCRM (e.g. with `CiviCRM Webtest User` role) qualifies.
* View the contact with the soft credit.
### Expected Result
* The soft credit is not visible.
### Actual Result
* The soft credit is visible. Clicking `View` to view the original contribution returns a "permission denied", which is correct (but bad UX).JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2237Provide some way for an extension's database tables to automatically get incl...2022-08-24T18:56:45ZDaveDProvide some way for an extension's database tables to automatically get included when a site runs utf8mb4 conversionThere's an option in the api call / api explorer when running the utf8mb4 conversion to specify some tablename patterns, but this requires the user to know what the tables are that all their extensions create.
One idea is a hook that le...There's an option in the api call / api explorer when running the utf8mb4 conversion to specify some tablename patterns, but this requires the user to know what the tables are that all their extensions create.
One idea is a hook that lets an extension advertise the names of tables it creates. If it wants to manage the charset itself for a table then it can just not list it.
Another is a standard naming like civicrm_ext_FOO, which then core knows not to conflict for its own tables, but which starts with civicrm so gets picked up by default.
Open to other ideas. The status quo is also technically an option. And it's only important if there's some connection between text data in the extension's tables and core tables, or it stores emojis and such.https://lab.civicrm.org/dev/core/-/issues/3759Logging table schemas should be updated when extension table schemas are updated2022-08-24T19:17:07ZJonGoldLogging table schemas should be updated when extension table schemas are updatedI just ran into an issue while enabling Geocoder on a relatively fresh Civi install. `install.sql` generated a table, then `hook_civicrm_managed` tried adding all those record in `.mgd.php`, which failed because `log_civicrm_geocoder` d...I just ran into an issue while enabling Geocoder on a relatively fresh Civi install. `install.sql` generated a table, then `hook_civicrm_managed` tried adding all those record in `.mgd.php`, which failed because `log_civicrm_geocoder` didn't exist.
I know this isn't a simple lift - but given the recent conversations that `civix` might phase out the generation of `.sql` files, this seems like the opportune moment to raise the issue.https://lab.civicrm.org/dev/core/-/issues/3703Confirmation emails are not sent if it is a recurring payment2022-08-25T17:04:50ZMariaVConfirmation emails are not sent if it is a recurring payment**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well ...**Current behavior apparently:**
One-time donations: A confirmation email comes right after you fill out the donation form
Recurring donations: A confirmation email comes each time after the payment is processed
This works quite well for online payment processors like PayPal, where the first payment is made within seconds of submitting the donation form.
With "asynchronous payment processors" such as SEPA, however, this approach works quite poorly, because it can take several weeks before the next payment run happens (usually once a month).
Currently this does not work at all.
Moreover, from a fundraiser's point of view, it is a real disadvantage if these confirmations are sent with every payment: People will be reminded every time that they still haven't cancelled their recurring donations.
**In contrast, the behavior most of us would like to see would be:**
One-time and recurring donations: A confirmation email comes right after you fill out the donation form
Further confirmations for recurring donations will only come if this has been set in a configuration setting.
**My suggestion:**
There could be an additional radio button:
One option that will be choosed by default which explains that the mail is only sent for recurring donations when a payment has actually been received (and for one-time donations directly). And for this purpose, there will be another option that says that a confirmation will be sent once directly after the form has been submitted - regardless of whether it is a one-time or recurring donation.
This will ensure that this function will continue to work for everyone who actually wants to use it that way - even if there are probably not many.https://lab.civicrm.org/dev/financial/-/issues/205CiviFinancial Blue Sky Dreaming2022-08-25T21:31:40ZJoeMurrayCiviFinancial Blue Sky DreamingThere has been talk over the years by different people about a LExIM shift to a new paradigm/implementation for CiviAccount. I have been approached by someone who could rustle up a tiny starting stake for such a huge effort (I'm not conf...There has been talk over the years by different people about a LExIM shift to a new paradigm/implementation for CiviAccount. I have been approached by someone who could rustle up a tiny starting stake for such a huge effort (I'm not confident there would be an ability to get to 50% needed to launch an MIH that will likely cost in the six figures at CT billable rates). Here is a blue sky dreaming of how a CiviFinancials LExIM might succeed.
1. We find funding for integrating payments into Form Builder - this seems likely to be possible and occur, yet is still a big lift. Imagine all the financial aspects of webform_civicrm.
2. When implementing the new interface for contribution pages and event reg pages, etc., we have some 'dependency injection' that allows calls to be made either to the existing financial APIs or to a new set.
3. We work to implement the guts of CiviAccounting in a new way. Discussion is needed here, but I would be in favour of some significant breaking changes like simplifying the Financial Type/Financial Account model into much more standard accounting, preferrably with simple, sensible defaults.
1. We could design our own CiviAccounts v2 from scratch.
2. We could aim to implement an interface with an existing open source accounting system. The aim is to store all the CiviCRM financial transactions in a standard, validated way without having the development and support burden of making it ourselves. We'd only need to keep the integration going strong. Two candidates I have found that might be feasible, and there are many others, are Front Accounting and GnuCash. https://sourceforge.net/projects/frontaccounting/files/FrontAccounting%202.4/stats/timeline?dates=2019-08-01+to+2022-08-01 has the same technical stack as CiviCRM (PHP and MySQL) but seems to be trending down in installs. https://sourceforge.net/projects/gnucash/files/gnucash%20%28stable%29/stats/timeline?dates=2019-08-01+to+2022-08-01 is much more popular and losing momentum more slowly. It is built in C and C++, so it would be more complex to integrate.
3. If there is a fully open source implementation via CiviAccounts v2 or integrating an open source accounting package, then I would be okay with there being integrations with closed source accounting systems that are popular like Xero and QuickBooks Online. I suppose we could allow the existing implementation of CiviAccounts to be the open source option. While more financially realistic, it might be bad for our reputation.