Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-03-20T06:27:09Zhttps://lab.civicrm.org/dev/core/-/issues/3110FormBuilder - add legend / collapsible option for fieldset2022-03-20T06:27:09ZsamuelsovFormBuilder - add legend / collapsible option for fieldsetContainer can be defined as fieldset but miss the options to add a legend (or not obvious) and collapsible.
![ksnip_20220310-090249](/uploads/ed056210d548e1e2bf64ba0bc8126c3a/ksnip_20220310-090249.png)
I think what we have in "Contact ...Container can be defined as fieldset but miss the options to add a legend (or not obvious) and collapsible.
![ksnip_20220310-090249](/uploads/ed056210d548e1e2bf64ba0bc8126c3a/ksnip_20220310-090249.png)
I think what we have in "Contact Summary Layout" would be perfect :
- Open - show title
- Open - hide title
- collapsible collapsed
- collapsible expandedcolemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3109Raise number of email addresses available to inline edit2023-12-01T05:03:20ZAndrew WestRaise number of email addresses available to inline editIn light of #[3106](https://lab.civicrm.org/dev/core/-/issues/3106) ([PR](https://github.com/civicrm/civicrm-core/pull/22908)), is it worth upping the number of email addresses available to inline edit? We're hitting the limit of 6 somet...In light of #[3106](https://lab.civicrm.org/dev/core/-/issues/3106) ([PR](https://github.com/civicrm/civicrm-core/pull/22908)), is it worth upping the number of email addresses available to inline edit? We're hitting the limit of 6 sometimes and having to add directly into civicrm_email. I'd be tempted to make it 25 so it matches websites, but 10 at least?
Our use-case is that we have volunteers who have multiple roles in the organisation. Per GDPR each role needs its own email address. Doesn't take long to get to 6.https://lab.civicrm.org/dev/core/-/issues/3108Timezone feature doesn't respect daylight saving time2022-03-10T17:14:41ZguitarmanTimezone feature doesn't respect daylight saving timeOverview
----------------------------------------
The timezone feature in CiviCRM 5.47 doesn't respect the daylight saving time.
https://civicrm.stackexchange.com/questions/41426/wrong-time-after-5-47-update
Reproduction steps
--------...Overview
----------------------------------------
The timezone feature in CiviCRM 5.47 doesn't respect the daylight saving time.
https://civicrm.stackexchange.com/questions/41426/wrong-time-after-5-47-update
Reproduction steps
----------------------------------------
1. Set the CMS/CRM timezone to i.e. Europe/Zurich
2. Create a new event before march 27th
3. Create event after march 27th
4. Event start-/end-times differ, the daylight saving time is not respected in the convertTimeZone strings in backend/lists nor in the frontend display.
5. After october 30th, end of the daylight saving time, start-/end-times are "correct" again.
Expected behaviour
----------------------------------------
Daylight saving time has to be taken into account.
Comments
----------------------------------------
Thanks a lot for having a look into this.https://lab.civicrm.org/dev/drupal/-/issues/176Epic: Drupal 10 readiness2023-08-19T00:44:33ZDaveDEpic: Drupal 10 readinessLab snippet with a full set of instructions on how to scrape and claw a drupal 10+civi install into existence:
https://lab.civicrm.org/-/snippets/84
- [ ] Requires php 8.1 https://lab.civicrm.org/dev/core/-/issues/3181
- [x] Requires s...Lab snippet with a full set of instructions on how to scrape and claw a drupal 10+civi install into existence:
https://lab.civicrm.org/-/snippets/84
- [ ] Requires php 8.1 https://lab.civicrm.org/dev/core/-/issues/3181
- [x] Requires symfony 6 (this currently prevents even downloading the civi files even if you try really hard) https://lab.civicrm.org/dev/core/-/issues/2316 / PR https://github.com/civicrm/civicrm-core/pull/24132
- [x] Hooks defined by getSubscribedEvents don't work: https://lab.civicrm.org/dev/core/-/issues/3802
- [x] Composer-compile-lib [restricts to symfony 5](https://github.com/civicrm/composer-compile-lib/blob/a03d219bc4bad5aa878e198719b83178a910984b/composer.json#L26) / PR https://github.com/civicrm/composer-compile-lib/pull/5
- [x] Miscellaneous other composer.json updates - see the lab snippet above.
- [x] Why does cache/integration-tests need to be in a prod install? Can it be in require-dev instead? PR: https://github.com/civicrm/civicrm-core/pull/25054
- [x] https://github.com/civicrm/civicrm-core/pull/25499 covers these:
- [x] symfony/config
- [x] symfony/dependency-injection
- [x] symfony/event-dispatcher
- [x] symfony/filesystem
- [x] symfony/process
- [x] symfony/var-dumper
- [x] symfony/service-contracts
- [x] symfony/finder
- [x] psr/container
- [x] cv uses some deprecated symfony [in bootstrap](https://github.com/civicrm/cv/issues/117) / PR: https://github.com/civicrm/cv/pull/120
- [x] Followup fix because the attempt to keep supporting drupal 8 doesn't work with drupal 10: https://github.com/civicrm/cv/pull/126
- [x] core loadBoostrap(), needed e.g. for `cv`. https://github.com/civicrm/civicrm-core/pull/24133
- [x] similarly CRM_Utils_System_Drupal8 - https://github.com/civicrm/civicrm-core/pull/23302
- [x] financialacls core extension: https://lab.civicrm.org/dev/core/-/issues/3184
- [x] Requires guzzle 7 (I think this is easy) https://lab.civicrm.org/dev/drupal/-/issues/171 / PR: https://github.com/civicrm/civicrm-core/pull/22918
- [x] Requires psr/log 2.0. PR: https://github.com/civicrm/civicrm-core/pull/23409
- [x] Deprecation prevents civicrm-setup from running (already PR'd): https://github.com/civicrm/civicrm-core/pull/21809 / https://lab.civicrm.org/dev/drupal/-/issues/167
- [x] civicrm-drupal-8 won't enable because it doesn't [declare it is compatible](https://github.com/civicrm/civicrm-drupal-8/blob/b55fb5027c453ce86f76f357a3087e19a3bb4d41/civicrm.info.yml#L5)
- PR: https://github.com/civicrm/civicrm-drupal-8/pull/73
- [x] civicrm-drupal-8 civicrmtheme submodule won't enable because it doesn't [declare it is compatible](https://github.com/civicrm/civicrm-drupal-8/blob/b55fb5027c453ce86f76f357a3087e19a3bb4d41/modules/civicrmtheme/civicrmtheme.info.yml#L5)
- PR: https://github.com/civicrm/civicrm-drupal-8/pull/73
- [ ] For running unit tests:
- [ ] phpunit9 support: https://github.com/civicrm/civicrm-core/compare/master...demeritcowboy:civicrm-core:phpunit9?expand=1 along with `composer require yoast/phpunit-polyfills`
- [x] deprecated theme for mink tests: https://github.com/civicrm/civicrm-drupal-8/pull/76
- [ ] Possibly move this file to a community-maintained drupal module? It needs to be in a drupal module. Not much uses it currently - civicrm_entity and 2 extensions.
Timewise it would be cool to have something at least installable for Drupalcon (Apr 25).
cc: @KarinG @jackrabbithanna5.60.0https://lab.civicrm.org/dev/core/-/issues/3107Upgrading from pre-5.47 to 5.48+ isn't re-runnable in certain situations2022-06-29T02:33:30ZDaveDUpgrading from pre-5.47 to 5.48+ isn't re-runnable in certain situations
Since sketching out the below, I think I can see there is a quick solution, but now that I've written the description already I'll still post the whole thing. Short version: This line should have a check that `is_autorun` exists in the ...
Since sketching out the below, I think I can see there is a quick solution, but now that I've written the description already I'll still post the whole thing. Short version: This line should have a check that `is_autorun` exists in the table before running the query: https://github.com/civicrm/civicrm-core/blob/88e3bfdfc52aa1e117160b6592597510af446d1a/CRM/Upgrade/Incremental/php/FiveFortyEight.php#L60
Problem
-------
Typical sysadmin: "Goin' to upgrade now. Let me make a backup... ok, done. Upgrade, and ... oh that failed. Ok let me reload my sql file and apply this patch and try again... Oh that failed - something about queues. Repeat. Fail again. Hmm."
For a dev doing testing this might not come up, because they might "start from scratch" when repeating (or use trickery like devs do).
The difference is the reload db, and in particular when upgrading pre-5.47 to 5.48+. And given the history to-date, that reload-and-try-again cycle is likely to come up more with 5.47 than usual.
In 5.47, the `civicrm_queue` table is created, but [ONLY if it doesn't exist](https://github.com/civicrm/civicrm-core/blob/88e3bfdfc52aa1e117160b6592597510af446d1a/CRM/Upgrade/Incremental/sql/5.47.alpha1.mysql.tpl#L3). I.e. as opposed to `DROP TABLE IF EXISTS civicrm_queue`, followed by the creation. Since this table might have long-term data, you don't want to drop it if an upgrade is being re-run some time in the future.
(Aside: That create table statement probably shouldn't enforce utf8mb4 yet, but that's separate.)
So now let's think about the sequence for the sysadmin:
* Before first attempt, civicrm_queue didn't exist.
* After first attempt, it now exists.
* Reload db. Note something important: The backup sql file does NOT have anything about civicrm_queue. There is no DROP TABLE statement for it. So after reloading the sql file, civicrm_queue DOES exist, which is different from before the first run.
* If you're the type of sysadmin who drops the whole db before reloading the sql file, you won't run into this. I don't know what percentage that covers.
So now, there's [an upgrade step](https://github.com/civicrm/civicrm-core/blob/88e3bfdfc52aa1e117160b6592597510af446d1a/CRM/Upgrade/Incremental/php/FiveFortyEight.php#L60) in 5.48 that assumes that the field `is_autorun` is going to exist. But it doesn't because civicrm_queue at this point is the already upgraded table.
SECONDARY ISSUE
---------------
There's another issue here too for similar reasons, but I haven't confirmed the specific problem, but at the moment I think there is one.
Something new in 5.47 is that civi will auto-install search kit and afform. These both create database tables. So you have a similar situation where after reloading the db, you have an already upgraded table present when it shouldn't be, so you get a similar problem when something tries to act on it in a way that isn't re-runnable.https://lab.civicrm.org/dev/core/-/issues/3106Raise number of websites available to inline edit2022-03-09T16:06:41ZJonGoldRaise number of websites available to inline editThe max number of websites available to inline edit is 5. Since "Websites" is also used to track folks' social media, it's pretty easy to exceed 5. I think we should change it to 25.The max number of websites available to inline edit is 5. Since "Websites" is also used to track folks' social media, it's pretty easy to exceed 5. I think we should change it to 25.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3105Event Registration Confirmation from waitlist crashes payment processors that...2022-06-09T01:23:08ZFrancis (Agileware)Event Registration Confirmation from waitlist crashes payment processors that expect to be able to pull contact information from the doPayment parameters (Stripe via PropertyBag)Overview
----------------------------------------
When a participant returns to the site after moving from the waitlist to a pending status, the contactID parameter is not passed through to the payment processor.
On Stripe in particular...Overview
----------------------------------------
When a participant returns to the site after moving from the waitlist to a pending status, the contactID parameter is not passed through to the payment processor.
On Stripe in particular, this causes the form to crash, payment to not be made, the Participant record to remain in pending from waitlist state, and any additional details entered into the form to be lost.
There's the potential for this to cause problem with other payment processors where contactID is expected to be passed through also.
It seems like this information should be set by the Confirmation form before handing off to the payment processor, so filing as a core bug.
Reproduction steps
----------------------------------------
1. Enable waitlist statuses in CiviCRM
2. Create an Event with Waitlist enabled, setting the payment processor to Stripe
3. Register a "Pending From Waitlist" attendee (e.g. fill the waitlist then try to register one more)
4. Attempt to use the generated link /civicrm/event/register/confirm?reset=1&participantId={id}&cs={checksum}
5. Note that the previously filled details are loaded
6. Fill in all details and confirm the registration
Current behaviour
----------------------------------------
The Form throws up the unfriendly yellow error box with `Property 'contactID' has not been set.`
Trace also appears in CiviCRM.HASH.log:
```
$Fatal Error Details = array:3 [
"message" => "Property 'contactID' has not been set."
"code" => null
"exception" => BadMethodCallException {#12711
#message: "Property 'contactID' has not been set."
#code: 0
#file: "/.../httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Payment/PropertyBag.php"
#line: 291
trace: {
/.../httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Payment/PropertyBag.php:291 {
› }
› throw new \BadMethodCallException("Property '$prop' has not been set.");
› }
}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Payment/PropertyBag.php:625 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/ext/com.drastikbydesign.stripe/CRM/Core/Payment/Stripe.php:556 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Event/Form/Registration/Confirm.php:1264 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Event/Form/Registration/Confirm.php:533 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php:565 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php:144 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php:43 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php:203 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php:103 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php:353 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:319 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:69 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php:36 { ...}
/.../httpdocs/wp-content/plugins/civicrm/civicrm.php:1170 { ...}
/.../httpdocs/wp-content/plugins/civicrm/includes/civicrm.basepage.php:366 { ...}
/.../httpdocs/wp-includes/class-wp-hook.php:307 { ...}
/.../httpdocs/wp-includes/class-wp-hook.php:331 { ...}
/.../httpdocs/wp-includes/plugin.php:522 { ...}
/.../httpdocs/wp-includes/class-wp.php:771 { ...}
/.../httpdocs/wp-includes/functions.php:1310 { ...}
/.../httpdocs/wp-blog-header.php:16 { ...}
/.../httpdocs/index.php:17 { ...}
}
}
]
```
Expected behaviour
----------------------------------------
Event registration is confirmed, Payment is received, email is sent, and so on
Environment information
----------------------------------------
* __Browser:__ _Any browser_
* __CiviCRM:__ _5.46.2_ (Did not see any relevant changes in 5.47.0)
* __PHP:__ _7.4_
* __CMS:__ _WordPress 5.9.1_
* __Database:__ _MariaDB 10.3_
* __Web Server:__ _Apache 2.4, Nginx latest docker_
Comments
----------------------------------------
Note that everything works up until the confirmation step.
Agileware Ref: CIVICRM-19355.51.0https://lab.civicrm.org/dev/financial/-/issues/191PaymentProcessor.pay should bubble up the error returned from the processor2022-03-07T22:53:09ZJonGoldPaymentProcessor.pay should bubble up the error returned from the processor`PaymentProcessor.pay` returns the same message - `Payment Failed` - no matter the cause. This makes it impossible to tell the user why their credit card was declined.
### Steps to Replicate
* Install the dummy processor.
* Submit `Pay...`PaymentProcessor.pay` returns the same message - `Payment Failed` - no matter the cause. This makes it impossible to tell the user why their credit card was declined.
### Steps to Replicate
* Install the dummy processor.
* Submit `PaymentProcessor.pay` with an expiration date in 2021 or earlier.
* Alternatively, create a Webform, install WFC, and submit your payment that way.
### Expected Result
`Invalid expiry date`
### Actual Result
`Payment failed`
I don't know if there's a good reason for this or not. @KarinG has expressed interest to me in bubbling up the message from the payment processor.5.49.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3104RC Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpected...2022-03-13T10:28:32Zmagnolia61RC Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpectedSmartyVariables()With the current RC (5.48 beta 1) I get the following fatal error when I want to view a contact record
`Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpectedSmartyVariables() in CRM_Core_BAO_CustomGroup::buildCustom...With the current RC (5.48 beta 1) I get the following fatal error when I want to view a contact record
`Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpectedSmartyVariables() in CRM_Core_BAO_CustomGroup::buildCustomDataView() (line 1986 of /var/www/vhosts/xyz/webroot/sites/all/modules/civicrm/CRM/Core/BAO/CustomGroup.php).`
- CiviCRM: 5.48.beta1
- CMS: Drupal 7.89
- PHP: 7.4.28 (fpm-fcgi)
- Database: 10.6.5-MariaDB-1:10.6.5+maria~bullseye-log engine: InnoDB 10 row format: Dynamic
- Webserver: Apache
- OS: Linux5.48.0https://lab.civicrm.org/dev/core/-/issues/3102Surveys broken in php 82022-03-06T16:02:31ZDaveDSurveys broken in php 8`TypeError: call_user_func(): Argument #1 ($function) must be a valid callback, non-static method CRM_Campaign_Page_AJAX::surveyList() cannot be called statically in CRM_Utils_REST::process() (line 266 of .../web/sites/all/modules/civicr...`TypeError: call_user_func(): Argument #1 ($function) must be a valid callback, non-static method CRM_Campaign_Page_AJAX::surveyList() cannot be called statically in CRM_Utils_REST::process() (line 266 of .../web/sites/all/modules/civicrm/CRM/Utils/REST.php).`
Above error after creating a survey, and the survey doesn't show on the survey dashboard. The error is a bit hidden - you need to look in the network console, or drupal watchdog.5.48.0https://lab.civicrm.org/dev/core/-/issues/3101CiviCRM 5.47.0 Upgrade Failure with Extended Reports 5.112023-11-03T02:02:24ZkcristianoCiviCRM 5.47.0 Upgrade Failure with Extended Reports 5.11Logging here as extended reports is widely used.
CiviCRM 5.46 to 5.47.0
ExtendedReport v 5.11.0
WP 5.8.3
php 7.4
Upgrade via the UI or CLI fails:
```
Exception: "API error: DB Error: constraint violation on ReportTemplate.create"
#0...Logging here as extended reports is widely used.
CiviCRM 5.46 to 5.47.0
ExtendedReport v 5.11.0
WP 5.8.3
php 7.4
Upgrade via the UI or CLI fails:
```
Exception: "API error: DB Error: constraint violation on ReportTemplate.create"
#0 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php(375): CRM_Core_ManagedEntities->onApiError("ReportTemplate", "create", (Array:8), (Array:4))
#1 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php(187): CRM_Core_ManagedEntities->updateExistingEntity(Object(CRM_Core_DAO_Managed), (Array:10))
#2 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php(167): CRM_Core_ManagedEntities->reconcileEnabledModule("nz.co.fuzion.extendedreport")
#3 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/ManagedEntities.php(128): CRM_Core_ManagedEntities->reconcileEnabledModules()
#4 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(413): CRM_Core_ManagedEntities->reconcile()
#5 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Form.php(818): CRM_Core_Invoke::rebuildMenuAndCaches(FALSE, TRUE)
#6 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Queue/Task.php(73): CRM_Upgrade_Form::doCoreFinish(Object(CRM_Queue_TaskContext), "5.47.alpha1", "5.47.0", "5.47.0", "/tmp/civicrm-post-upgrade7axXs1")
#7 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Queue/Runner.php(215): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
#8 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Queue/Runner.php(169): CRM_Queue_Runner->runNext()
#9 /home/cvdemo/public_html/wp-content/plugins/civicrm/civicrm/CRM/Upgrade/Headless.php(49): CRM_Queue_Runner->runAll()
#10 /home/cvdemo/public_html/wp-content/plugins/civicrm/wp-cli/civicrm.php(1083): CRM_Upgrade_Headless->run()
#11 /home/cvdemo/public_html/wp-content/plugins/civicrm/wp-cli/civicrm.php(171): CiviCRM_Command->upgradeDB()
#12 [internal function](): CiviCRM_Command->__invoke((Array:0), (Array:0))
#13 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(100): call_user_func((Array:2), (Array:1), (Array:0))
#14 [internal function](): WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}((Array:1), (Array:0))
#15 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(491): call_user_func(Object(Closure), (Array:1), (Array:0))
#16 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(399): WP_CLI\Dispatcher\Subcommand->invoke((Array:1), (Array:0), (Array:0))
#17 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(422): WP_CLI\Runner->run_command((Array:2), (Array:0))
#18 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1194): WP_CLI\Runner->run_command_and_exit()
#19 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#20 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(77): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#21 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(27): WP_CLI\bootstrap()
#22 phar:///usr/local/bin/wp/php/boot-phar.php(11): include("phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php")
#23 /usr/local/bin/wp(4): include("phar:///usr/local/bin/wp/php/boot-phar.php")
#24 {main}
Error: API error: DB Error: constraint violation on ReportTemplate.create
Array
(
[is_error] => 1
[error_message] => API error: DB Error: constraint violation on ReportTemplate.create
)
```
You can either disable extended reports or upgrade extended reports to get the upgrade to succeed.
This seems to be a new issue as my testing to 5.47-RC did not have this issue. I had not tested upgrading in about a week. The two sites I tested this on are 'demo' sites that had not been on the RC.
We should be recommending extension updates before Core upgrade, but I was surprised I had this error.
cc @eileen Let me know if this issue belongs over at the extended report repo.https://lab.civicrm.org/dev/core/-/issues/3100Grant CiviReport menu inconsistencies2022-03-09T13:47:08ZDaveDGrant CiviReport menu inconsistencies1. On a brand new install without civigrant, there's an empty Reports - CiviGrant menu.
1. If you install civigrant or upgrade from a site that had civigrant, the CiviGrant menu is still empty, and the reports get put under Reports - Con...1. On a brand new install without civigrant, there's an empty Reports - CiviGrant menu.
1. If you install civigrant or upgrade from a site that had civigrant, the CiviGrant menu is still empty, and the reports get put under Reports - Contact Reports.
There's two things I think:
1. Some leftovers in the xml files from before. Should be an easy fix.
1. Even if that's fixed, where _should_ the extension's reports live in the menu?5.47.1https://lab.civicrm.org/dev/core/-/issues/3099New Email page won't cancel unless required fields are completed2022-03-04T15:53:03ZphilmorbruNew Email page won't cancel unless required fields are completedOverview
----------------------------------------
When the Cancel button on a New Email is clicked, the cancel action is refused if the required fields are not completed.
Reproduction steps
----------------------------------------
1. Cl...Overview
----------------------------------------
When the Cancel button on a New Email is clicked, the cancel action is refused if the required fields are not completed.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> New Email**.
1. Click "Cancel"
Current behaviour
----------------------------------------
When clicking "Cancel" the New Email page reloads with this error message:
```
Please correct the following errors in the form fields below:
To is a required field.
Subject is a required field.
```
Expected behaviour
----------------------------------------
User should be taken to the most recently viewed Civi page, or the Civi home
Environment information
----------------------------------------
* __Browser:__ Chrome 99.0.4844.51
* __CiviCRM:__ 5.39.0
* __PHP:__ 7.4.15
* __CMS:__ Joomla 3.10.6
* __Database:__ MySQL 5.7.36
* __Web Server:__ Apache 2.4.51
Comments
----------------------------------------
When a new email is created from a Contact - Action > Send an Email and a modal pops up to write the email, the Cancel button on the modal functions as expected.https://lab.civicrm.org/dev/core/-/issues/3098Deleted contacts are available as Mail recipients2023-06-09T19:39:30ZphilmorbruDeleted contacts are available as Mail recipientsOverview
----------------------------------------
When creating a New Email (not a Mailing), deleted contacts are available as Recipients. They are not available in the CC or BCC fields.
CiviCRM 39.5.0, Joomla 3.10.6
Example use-case
...Overview
----------------------------------------
When creating a New Email (not a Mailing), deleted contacts are available as Recipients. They are not available in the CC or BCC fields.
CiviCRM 39.5.0, Joomla 3.10.6
Example use-case
----------------------------------------
1. Click on **Contacts -> New Email**.
2. In the recipients field, enter a name/email that is known to be soft deleted.
Current behaviour
----------------------------------------
Soft deleted contacts are available as primary recipients.
Proposed behaviour
----------------------------------------
As with CC and BCC fields, soft deleted contacts should not be available.
Comments
----------------------------------------
- This issue is [confirmed to show up in most recent update](https://civicrm.stackexchange.com/questions/41383/deleted-contacts-are-showing-up-in-the-recipients-list-for-new-email?noredirect=1#comment48693_41383).
- Closed issue related to soft contacts showing up where they shouldn't: https://lab.civicrm.org/dev/core/-/issues/2119 (regarding deleted contacts showing up in smart groups). That was fixed in 5.30.1https://lab.civicrm.org/dev/core/-/issues/3097Running cv flush on multisite results in 'Key id not found in api results' error2022-07-16T19:47:30ZandyburnsRunning cv flush on multisite results in 'Key id not found in api results' error`cv flush` command has never been a full flush on multisite. So we have a script that loops thru each site to do a cache clear on each site instead. However, this can catch people out that run cv flush instead. What's interesting is this...`cv flush` command has never been a full flush on multisite. So we have a script that loops thru each site to do a cache clear on each site instead. However, this can catch people out that run cv flush instead. What's interesting is this did not occur on Civi 5.35.2 but does on 5.45.3.
**Key id not found in api results**
![image](/uploads/d23b354d4887ba0237004ede12025082/image.png)https://lab.civicrm.org/dev/core/-/issues/3095Formatting shows Currency for samey-locales2022-03-05T14:09:10ZeileenFormatting shows Currency for samey-localesThe switch to BrickMoney has the positive impact of adding a currency for the non-site-default locale - so for a US site NZ donations would be prefixed with NZ.
However, it turns out it is pretty common for NZ sites to leave the site la...The switch to BrickMoney has the positive impact of adding a currency for the non-site-default locale - so for a US site NZ donations would be prefixed with NZ.
However, it turns out it is pretty common for NZ sites to leave the site language as en_US as no other English variants are offered without the translation install...
![image](/uploads/7a814b43db89c9c100b4cbd7c9ccd528/image.png)
We discussed this & think that the remedy is to add a new setting
format_locale
If set this will be used for money formatting INSTEAD of thousand separator and decimal separator - ie those will be determinted from the format_locale and we will hide those settings in the UI and deprecate them. Over time we will encourage people to switch. This setting can also be used for dates5.47.0https://lab.civicrm.org/dev/core/-/issues/3094Contribution view page crashes if you don't have event permissions2022-03-08T00:10:22ZDaveDContribution view page crashes if you don't have event permissionshttps://github.com/civicrm/civicrm-core/pull/22732 adds info about participants to the page but the api call throws an exception if you don't have permissions. I think I'll just put up a PR to wrap in a try/catch and then not display the...https://github.com/civicrm/civicrm-core/pull/22732 adds info about participants to the page but the api call throws an exception if you don't have permissions. I think I'll just put up a PR to wrap in a try/catch and then not display the participant stuff if error.5.48.0https://lab.civicrm.org/dev/core/-/issues/3093Upgrade error with civigrant - order of dependencies matters2022-03-07T22:15:00ZDaveDUpgrade error with civigrant - order of dependencies matters1. Install an older version of civi. Let's say 5.39 but I don't think it matters too much.
1. Enable the CiviGrant component.
1. **Don't** install search kit.
1. Upgrade. You'll see a message about "extension error" that looks like this....1. Install an older version of civi. Let's say 5.39 but I don't think it matters too much.
1. Enable the CiviGrant component.
1. **Don't** install search kit.
1. Upgrade. You'll see a message about "extension error" that looks like this. So far not a problem, but note the order of dependencies listed. The average person will now attempt to install `Form Core` first.
![Untitled2](/uploads/84a1e72d59998ab8fc392187e72a5d29/Untitled2.png)
1. NO! You must install search kit first. Otherwise you get `API error: API (SearchDisplay, create) does not exist (join the API team and implement it!) on SearchDisplay.create`.
Note that this is slightly different from https://lab.civicrm.org/dev/core/-/issues/3036 (PR https://github.com/civicrm/civicrm-core/pull/22623) which dealt with interdependence between form builder and search kit, and the order there doesn't matter.5.47.0https://lab.civicrm.org/dev/core/-/issues/3092Batch search form/results incorrect vis-a-vis status2023-11-29T05:03:26ZlcarterBatch search form/results incorrect vis-a-vis statusThe batch search form searches based on contribution status, but has a results column displaying transaction/payment status. This is confusing and undesirable.
Even when the search is specifically limited to contributions with complete...The batch search form searches based on contribution status, but has a results column displaying transaction/payment status. This is confusing and undesirable.
Even when the search is specifically limited to contributions with completed status, some results may show pending status; this is confusing to the user. See https://www.screencast.com/t/XgNTPieRXz - the box is indicating two transaction records for the same dues payment.
Proposal:
1. Expose a search filter field for civicrm_financial_trxn.status_id as well as contribution status.
2. In Search Results, change the column title from Status to something more clear, like Financial Transaction Status or (slightly inaccurate but generally true and more understandable) Payment Status.
3. In Search Results, add a column title Contribution Status that displays the civicrm_contribution.status_id field.
Discussion:
This functionality has been around for a long time and not used much. Perhaps that because it has a confusing UX. The proposal would not break anything for existing users.
However, for many years there was a desire to get rid of Contribution Status, partly for reasons that @lcarter is raising here: a field on contribution record can't do the job of representing all of the statuses of multiple steps in multiple payments, for example, perhaps followed by refunds or cancellation or some failure attempts in the middle.https://lab.civicrm.org/dev/core/-/issues/3091Pending financial transaction records remain in civicrm_financial_trxn and ap...2022-02-28T22:47:43ZlcarterPending financial transaction records remain in civicrm_financial_trxn and appear in batch searchReproduced on dmaster.demo.civicrm.org as of 2/28/2022 and also occurring in CiviCRM 5.39.5. Steps to replicate:
* Create a membership with a pending payment.
* View the membership and record the payment.
* View the batch search result...Reproduced on dmaster.demo.civicrm.org as of 2/28/2022 and also occurring in CiviCRM 5.39.5. Steps to replicate:
* Create a membership with a pending payment.
* View the membership and record the payment.
* View the batch search results - both the completed payment record and the pending financial transaction are listed: https://www.screencast.com/t/XgNTPieRXz However, only the completed payment record shows up on the contribution record itself: https://www.screencast.com/t/MQToafE2V
Notes:
* This occurs whether or not the payment method of the original pending payment and the (later) recorded payment match - I've tested it both ways.
* Although I can't access the database for dmaster, I'm attaching a screenshot of what these records look like in civicrm_financial_trxn.
* The site in question has the option for always recording A/R transactions disabled.
Because this isn't, strictly speaking, a payment record or even an update of the transaction that would be exported to an accounting system, it does not seem to me that this should be included in the batch results. (Whether or not this entry should be left as pending is another question.)
![2022-02-18_16-51-37](/uploads/55d83146c89047469faac8909847a27b/2022-02-18_16-51-37.png)