Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-09-08T22:41:11Zhttps://lab.civicrm.org/dev/core/-/issues/2604CiviCRM 5.37.2, Both the Fetch Bounces and Process Inbound Emails jobs will ...2023-09-08T22:41:11Zjustinfreeman (Agileware)CiviCRM 5.37.2, Both the Fetch Bounces and Process Inbound Emails jobs will fail with error: 'returnPath' is invalid (patch attached)Both the **Fetch Bounces** and **Process Inbound Emails** jobs will fail with Error message: `The value 'KO'Bananas@benders.com' that you were trying to assign to setting 'returnPath' is invalid. Allowed values are: the characters 'A-Za-...Both the **Fetch Bounces** and **Process Inbound Emails** jobs will fail with Error message: `The value 'KO'Bananas@benders.com' that you were trying to assign to setting 'returnPath' is invalid. Allowed values are: the characters 'A-Za-z0-9_.@=/+{}#~-'.`
Definition of **allowed characters** from https://en.wikipedia.org/wiki/Email_address#Local-part
zetacomponents / Mail, blocks valid email addresses due to RETURN_PATH_CHARS being too restrictive
const RETURN_PATH_CHARS = 'A-Za-z0-9_.@=/+{}#~-';
https://github.com/zetacomponents/Mail/blame/master/src/mail.php#L133
https://github.com/zetacomponents/Mail/commit/5187f764a0937f9fe04e675299558f5c1a90fd77#diff-52d017c2950c2583488542baf7d18f2bed8cb4e4d460050b43413c8dd56999b5R136
This problem was introduced with zetacomponents/mail 1.9.x which had a "security fix" that introduced email name part limits, which themselves are too limiting.
https://github.com/civicrm/civicrm-core/blame/master/composer.json#L62
Relevant commit dev/mailing#59 Update the version of zetacomponents/mail package, https://github.com/civicrm/civicrm-core/commit/ec88fefe6e0e1e09d0a1a2bdee199cbb3df382fa - which looks like CiviCRM 5.37.2
Unable to submit a PR as this path does not exist in the CiviCRM Git tree, https://github.com/civicrm/civicrm-core/tree/master/tools/scripts/composer/patches
But it should exist, see https://github.com/civicrm/civicrm-core/blob/master/composer.json#L291
**Proposed solution**
Attached is a patch with the proposed fix.
[060-CIVICRM-1601-Option-A.patch](/uploads/297a7b457a6682f5bbad9046260de5cf/060-CIVICRM-1601-Option-A.patch)
Agileware Ref: CIVICRM-16015.66.0https://lab.civicrm.org/dev/core/-/issues/3753Proposal: Allow negative rules for ACLs2023-09-08T10:52:34ZTobias Voigttobias.voigt@civiservice.deProposal: Allow negative rules for ACLs**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - ...**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - especially if you have many (groups or sets of custom fields).
**USE CASE:**
In one of our client's system, we have many groups and many sets of custom fields. What I want to achieve is:
1. define a privileged group / role that has exclusive access to **one** set of custom fields
2. allow access to all other sets of custom fields for all users
3. prevent 'normal' users from giving themselves access to the exclusive information by adding themselves to the privileged group
Because I can only define 'positive' ACL rules, here's what I have to do:
- turn off the WP permission for custom fields for the relevant roles (to be able to define my rules via CiviCRM ACLs)
- allow access to all sets of custom fields for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each set of custom fields**
- define a rule to allow access to the restricted set of custom fields to the privileged role
Depending on the number of sets of custom fields, this can be a tedious process. Not only that - if I create a new set of custom fields at a later time, I have to remember to create a new ACL rule for that as well.
Now for the third task (preventing users from adding themselves to the privileged group). To achive this I furthermore have to:
- turn off the WP permissions for viewing and editing all contacts for the relevant roles
- allow access to all groups for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each contact group**
- define a rule to allow access to the restricted contact group only for the privileged role
Again: With about 50+ groups, that's a tedious task. And again: I have to remember to create a new ACL rule each time I add a new group.
All in all I could end up with a multitude of rules (in our case 70+) that are really hard to maintain.
**PROPOSAL:**
This task could be so much easier, if it was possible to define 'negative' ACL rules. If this was possible, I could:
- turn off the relevant WP permissions
- allow access to all sets of custom fields for everyone (1 rule)
- allow access to all contact groups for everyone (1 rule)
- disallow access to the restricted set of custom fields for everyone (1 rule)
- disallow access to the restricted contact group for everyone (1 rule)
- allow access to the restricted set of custom fields for the privileged role (1 rule)
- allow access to the restricted contact group for the privileged role (1 rule)
As is implied above, **there would have to be some form of priorisation** of rules to make this work.
This way I would end up with only 6 rules and would not have to remember to create new rules whenever I create a new set of custom fields or a new contact group.5.64.0https://lab.civicrm.org/dev/core/-/issues/2700Enhance test-drive bevhaviour and associated wording2023-09-08T05:03:14ZrebeccatregennaEnhance test-drive bevhaviour and associated wordingOverview
----------------------------------------
At the moment test-drive transactions are not recorded consistently for memberships and events nor does the current intro text for test-drive mode reflects what is actually happening.
Ex...Overview
----------------------------------------
At the moment test-drive transactions are not recorded consistently for memberships and events nor does the current intro text for test-drive mode reflects what is actually happening.
Example use-case
----------------------------------------
1. Join as a member with [&action=preview](https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2&action=preview)
1. Register for an event with [&action=preview](https://dmaster.demo.civicrm.org/civicrm/event/register?reset=1&action=preview&id=1)
Current behaviour
----------------------------------------
**Memberships**
The info text on the join pages states:
> This page is currently running in test-drive mode. Transactions will be sent to your payment processor's test server. No live financial transactions will be submitted. However, a contact record will be created or updated and a test contribution record will be saved to the database. Use obvious test contact names so you can review and delete these records as needed. **Test contributions are not visible on the Contributions tab, but can be viewed by searching for 'Test Contributions' in the CiviContribute search form.** Refer to your payment processor's documentation for information on values to use for test credit card number, security code, postal code, etc.
However both the contribution and membership entries are displayed on the contact's record on the necessary tab:
![active_membership](/uploads/f190e74461e0cd6f407ebdc9bc9dde5c/active_membership.png)
![active_contributions](/uploads/bdf686fecbeb65a82445a9a50fde492f/active_contributions.png)
**Events**
The info text on the event pages states:
> Test-drive Your Event Registration Page This page is currently running in test-drive mode. If this is a paid event, transactions will be sent to your payment processor's test server. No live financial transactions will be submitted. However, a contact record will be created or updated and test event registration and contribution records will be saved to the database. Use obvious test contact names so you can review and delete these records as needed. Refer to your payment processor's documentation for information on values to use for test credit card number, security code, postal code, etc.
As mentioned above, again also visible on the Contributions tab but unfortunately not displayed as a test registrations on the Events tab.
![active_events](/uploads/869dd4b91a008358ff7d8c7e8e9e9c21/active_events.png)
Proposed behaviour
----------------------------------------
Agree consistent behaviour, i.e.:
- Show the test event registration on the contact Event tab (as it does for membership)
- Update the info text to ensure it aligns with what is actually being shown / recorded where
Comments
----------------------------------------
Tested on dmaster.demo.civicrm.org 5.41.alpha1https://lab.civicrm.org/dev/core/-/issues/2723Event participant role filter not working in Participant list report2023-09-08T05:03:14ZvitiusEvent participant role filter not working in Participant list reportParticipant list report with Event participant role filter could show more rows.
Reproduction steps
----------------------------------------
1. Create new participant role with id 11 (or 10, 21,...).
2. Register new participant to event...Participant list report with Event participant role filter could show more rows.
Reproduction steps
----------------------------------------
1. Create new participant role with id 11 (or 10, 21,...).
2. Register new participant to event with this new role
3. Show Participant list report on this event
4. Use Participant Role filter to show only Attendees (id of attendee role is 1)
5. In report will you see also participant with new role with id 11
Current behaviour
----------------------------------------
If you use Participant Role filter in Participant list report, that will be work like that: `role.id LIKE '%1%'` and not like `role.id = '1'`.
Expected behaviour
----------------------------------------
Report should show only exact role.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.37.0/5.33.2https://lab.civicrm.org/dev/core/-/issues/1863System check severities out of whack2023-09-08T02:20:40ZAndie HuntSystem check severities out of whackThe severities for system checks are [defined in PSR-3](https://www.php-fig.org/psr/psr-3/#3-psrlogloggerinterface), and the first system checks attempted to match them pretty closely.
| Level | Description (per PSR-3) | Examples (per P...The severities for system checks are [defined in PSR-3](https://www.php-fig.org/psr/psr-3/#3-psrlogloggerinterface), and the first system checks attempted to match them pretty closely.
| Level | Description (per PSR-3) | Examples (per PSR-3) | What happens in CiviCRM |
| ------ | ----- | ----- | ----- |
| emergency | System is unusable. | | You'll never see it because the system won't be functioning. |
| alert | Action must be taken immediately. | Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up. | Red pop-up when an admin logs in; item has a red header. |
| critical | Critical conditions. | Application component unavailable, unexpected exception. | Red pop-up when an admin logs in; item has a red header. |
| error | Runtime errors that do not require immediate action but should typically be logged and monitored. | | Red pop-up when an admin logs in; item has a red header. |
| warning | Exceptional occurrences that are not errors. | Use of deprecated APIs, poor use of an API, undesirable things that are not necessarily wrong. | Orange pop-up when an admin logs in; item has an orange header. |
| notice | Normal but significant events. | | Item has a blue header. |
| info | Interesting events. | User logs in, SQL logs. | Item has a green header. |
| debug | Detailed debug information. | | Never displayed. |
However, over the years a few things have happened:
1. Some system checks have severities that don't quite match the specifications here, especially skewing too high.
2. System checks are used to nudge people to update their hosting environment for the future.
3. The system checks have become dominated by things that users don't quite understand.
4. Partners and others supporting lots of organizations have become frustrated that system checks scare or confuse users.
I see there being four main ways to address this:
1. Narrowing who sees the system check messages to only those who are in a position to act on them (through permissions or otherwise).
2. Giving more warning (through upgrade messages and a longer runway of escalating severity) for things that are not currently critical but will become so.
3. Improving the presentation of system check messages and how to snooze or hush them.
4. Doing a better job of giving a system check the right severity.
There's been discussion on the first and second items elsewhere. This ticket is focused on the fourth. Fundamentally, some things will be at the level of "drop everything and fix it", but we don't want to cry wolf.
Here are the existing system checks and their severities. My hope is that by having them all in the same place it will be easier to decide which are more severe than others. The ID column is just here to ease discussion.
| ID | Class | Title | Message | Severity |
| -- | ----- | ----- | ------- | -------- |
| 1 | CRM_Utils_Check_Component_AddressParsing | Street address parsing | Street address parsing is enabled but not supported by your locale | warning |
| 2 | CRM_Utils_Check_Component_Case | CiviCase | Case type "%1" has duplicate XML files ("%2" and "%3") | warning |
| 3 | CRM_Utils_Check_Component_Case | CiviCase | Case type "%1" corresponds to XML file ("%2") The XML file should be named "%3". | warning |
| 4 | CRM_Utils_Check_Component_Case | Timestamps for Activities and Cases | The tables "<em>civicrm_activity</em>" and "<em>civicrm_case</em>" were updated to support two new fields, "<em>created_date</em>" and "<em>modified_date</em>".... | notice |
| 5 | CRM_Utils_Check_Component_Case | Relationship Type Internal Name Duplicates | Relationship type <em>%1</em> has the same internal machine name as another type.... | error |
| 6 | CRM_Utils_Check_Component_Case | Relationship Type Display Label Duplicates | Relationship type <em>%1</em> has the same display label as another type. | error |
| 7 | CRM_Utils_Check_Component_Case | Relationship Type Cross-Duplication | Relationship type <em>%1</em> has an internal machine name that is the same as the display label as another type.... | warning |
| 8 | CRM_Utils_Check_Component_Case | Relationship Type Ambiguity | Relationship type <em>%1</em> appears to be unidirectional, but has the same internal machine name for both sides.... | warning |
| 9 | CRM_Utils_Check_Component_Case | Relationship Type Ambiguity | Relationship type <em>%1</em> appears to be unidirectional internally, but has the same display label for both sides.... | warning |
| 10 | CRM_Utils_Check_Component_Case | Missing Roles | The following roles listed in your case type definitions do not match any relationship type defined in the system: <em>%1</em>.... | error |
| 11 | CRM_Utils_Check_Component_Case | Missing Case Type Definition | Unable to locate xml file for Case Type "<em>%1</em>". | error |
| 12 | CRM_Utils_Check_Component_Case | Missing Case Roles | CaseRoles seems to be missing in the xml file for Case Type "<em>%1</em>". | error |
| 13 | CRM_Utils_Check_Component_Case | Invalid Case Role | CaseRole "<em>%1</em>" in the xml file for Case Type "<em>%2</em>" doesn\'t seem to match any existing relationship type. | error |
| 14 | CRM_Utils_Check_Component_Case | Case Role using display label instead of internal machine name | Please edit the XML file for case type "<em>%2</em>" so that the case role label "<em>%1</em>" is changed to its corresponding name "<em>%3</em>".... | warning |
| 15 | CRM_Utils_Check_Component_Env | PHP Up-to-Date | This system uses PHP version %1 which meets or exceeds the recommendation of %2. | info |
| 16 | CRM_Utils_Check_Component_Env | PHP Out-of-Date | This system uses PHP version %1. This meets the minimum recommendations and you do not need to upgrade immediately, but the preferred version is %2. | notice |
| 17 | CRM_Utils_Check_Component_Env | PHP Out-of-Date | This system uses PHP version %1. This meets the minimum requirements for CiviCRM to function but is not recommended.... | warning |
| 18 | CRM_Utils_Check_Component_Env | PHP Out-of-Date | This system uses PHP version %1. To ensure the continued operation of CiviCRM, upgrade your server now.... | error |
| 19 | CRM_Utils_Check_Component_Env | Forward Compatibility: Enable "mysqli" | Future versions of CiviCRM may require the PHP extension "mysqli". To ensure that your system will be compatible, please install it in advance.... | warning |
| 20 | CRM_Utils_Check_Component_Env | Timestamp Mismatch | Timestamps reported by MySQL (eg "%2") and PHP (eg "%3" ) are mismatched. | error |
| 21 | CRM_Utils_Check_Component_Env | Debug Mode Enabled | Warning: Debug is enabled in system settings. This should not be enabled on production servers. | warning |
| 22 | CRM_Utils_Check_Component_Env | Outbound Email Disabled | Warning: Outbound email is disabled in system settings.... | warning |
| 23 | CRM_Utils_Check_Component_Env | Complete Setup | Please enter your organization's name, primary address and default FROM Email Address (for system-generated emails). | warning |
| 24 | CRM_Utils_Check_Component_Env | Configure Default Mailbox | Please configure a default mailbox for CiviMail. | warning |
| 25 | CRM_Utils_Check_Component_Env | Cron Running OK | Last cron run at %1. | info |
| 26 | CRM_Utils_Check_Component_Env | Cron Not Running | Last cron run at %1. / No cron runs have been recorded. | warning / error |
| 27 | CRM_Utils_Check_Component_Env | Resource URLs: Make them portable | Resource URLs may use absolute paths, relative paths, or variables. Absolute paths are more difficult to maintain.... | notice |
| 28 | CRM_Utils_Check_Component_Env | Directory Paths: Make them portable | Directories may use absolute paths, relative paths, or variables. Absolute paths are more difficult to maintain.... | notice |
| 29 | CRM_Utils_Check_Component_Env | Directory not writable | The %1 is not writable. Please check your file permissions. | error |
| 30 | CRM_Utils_Check_Component_Env | Directory not writable | Directory %1 is not writable. Please change your file permissions. *(this is actually an error checking the version)* | error |
| 31 | CRM_Utils_Check_Component_Env | Update Check Disabled | The check for new versions of CiviCRM has been disabled.... | notice |
| 32 | CRM_Utils_Check_Component_Env | *Version update messages* | *As provided by version check* | info / notice / warning / critical |
| 33 | CRM_Utils_Check_Component_Env | Directory not writable | Your extensions directory is not set.... | notice |
| 34 | CRM_Utils_Check_Component_Env | Extensions directory incorrect | Your extensions directory path points to %1, which is not a directory.... | error |
| 35 | CRM_Utils_Check_Component_Env | Read-Only Extensions | Your extensions directory (%1) is read-only.... | notice |
| 36 | CRM_Utils_Check_Component_Env | Extensions url missing | The extensions URL is not properly set.... | error |
| 37 | CRM_Utils_Check_Component_Env | Extensions check disabled | Not checking remote URL for extensions since ext_repo_url is set to false. | notice |
| 38 | CRM_Utils_Check_Component_Env | Extension download error | *Message thrown by extension check* | error |
| 39 | CRM_Utils_Check_Component_Env | No Extensions Available for this Version | There are currently no extensions on the CiviCRM public extension directory which are compatible with version %1.... | notice |
| 40 | CRM_Utils_Check_Component_Env | Extensions | No extensions installed. | info |
| 41 | CRM_Utils_Check_Component_Env | Extension Error | Failed to read extension (%1).... / %1 extension (%2) is installed but missing files. | error |
| 42 | CRM_Utils_Check_Component_Env | Extension Update Available | %1 (%2) version %3 is installed. Upgrade to version %5. | warning |
| 43 | CRM_Utils_Check_Component_Env | Extensions | All extensions are up-to-date | info |
| 44 | CRM_Utils_Check_Component_Env | Extension Upgrades Pending | Extension upgrades should be run as soon as possible. | error |
| 45 | CRM_Utils_Check_Component_Env | Database Version Missing | Version information found to be missing in database.... | error |
| 46 | CRM_Utils_Check_Component_Env | Database Version Invalid | Database is marked with invalid version format.... | error |
| 47 | CRM_Utils_Check_Component_Env | Database Partially Upgraded | Database check failed - the database looks to have been partially upgraded. | alert |
| 48 | CRM_Utils_Check_Component_Env | Database Upgrade Required | New codebase version detected.... | alert |
| 49 | CRM_Utils_Check_Component_Env | Database In Unexpected Version | Your database is marked with an unexpected version number.... | error |
| 50 | CRM_Utils_Check_Component_Env | MyISAM Database Engine | Your database is configured to use the MyISAM database engine.... | error |
| 51 | CRM_Utils_Check_Component_Env | No Default value for Auto Responder. | Reply Auto Responder is not set to any default value in Headers, Footers, and Automated Messages.... | warning |
| 52 | CRM_Utils_Check_Component_Env | Missing mbstring Extension | The PHP Multibyte String extension is needed for CiviCRM to correctly handle user input among other functionality.... | warning |
| 53 | CRM_Utils_Check_Component_Env | Non-Production Environment | The environment of this CiviCRM instance is set to '%1'.... | alert |
| 54 | CRM_Utils_Check_Component_Env | Incorrect Resource URL | The Resource URL is not set correctly.... | error |
| 55 | CRM_Utils_Check_Component_Env | MySQL Emoji Support (utf8mb4) | Future versions of CiviCRM may require MySQL to support utf8mb4 encoding.... | warning |
| 56 | CRM_Utils_Check_Component_Env | PHP MySQL Driver (mysqlnd) | It is recommended, though not yet required, to upgrade your PHP MySQL driver (mysqlnd) to >= 5.0.9 for utf8mb4 support. | warning |
| 57 | CRM_Utils_Check_Component_Env | PHP MySQL Driver (libmysqlclient) | It is recommended, though not yet required, to upgrade your PHP MySQL driver (libmysqlclient) to >= 5.5.3 for utf8mb4 support. | warning |
| 58 | CRM_Utils_Check_Component_Env | MySQL Out-of-Date | This system uses MySQL/MariaDB v%1. To ensure the continued operation of CiviCRM, upgrade MySQL now.... | error |
| 59 | CRM_Utils_Check_Component_Env | MySQL Out-of-Date | This system uses MySQL/MariaDB v%1. To prepare for CiviCRM v%5, please upgrade MySQL.... | warning |
| 60 | CRM_Utils_Check_Component_Env | MySQL Out-of-Date | This system uses MySQL/MariaDB v%1. You can continue to use this version of MySQL.... | notice |
| 61 | CRM_Utils_Check_Component_FinancialTypeAcls | Extension Missing | CiviCRM will in the future require the extension %1 for CiviCRM Reports to work correctly with the Financial Type ACLs. | warning |
| 62 | CRM_Utils_Check_Component_OptionGroups | Option Values with problematic Values | The Following Option Values contain value fields that do not match the Data Type of the Option Group.... | notice |
| 63 | CRM_Utils_Check_Component_PriceFields | Invalid Price Fields | the following Price Set Fields use disabled or invalid financial types and need to be fixed if they are to still be used.... | warning |
| 64 | CRM_Utils_Check_Component_Schema | Performance warning: Missing indices | The following tables have missing indices.... | warning |
| 65 | CRM_Utils_Check_Component_Schema | Missing Log Tables | You don't have logging enabled on some tables.... | warning |
| 66 | CRM_Utils_Check_Component_Schema | Smart Group check did not run | The smart group check was unable to run. | info |
| 67 | CRM_Utils_Check_Component_Schema | Disabled/Deleted fields on Smart Groups | The following smart groups include custom fields which are disabled/deleted from the database.... | warning |
| 68 | CRM_Utils_Check_Component_Schema | Deprecated monetary value display format configuration | The Monetary Value Display format is a deprecated setting, and this site has a non-standard format. | warning |
| 69 | CRM_Utils_Check_Component_Security | Security Warning | The CiviCRM debug log should not be downloadable. | warning |
| 70 | CRM_Utils_Check_Component_Security | Private Files Readable | Files in the data directory (%2) should not be downloadable.... | warning |
| 71 | CRM_Utils_Check_Component_Security | Browseable Directories | Directory %2 should not be browseable via the web.... | error |
| 72 | CRM_Utils_Check_Component_Security | Unsafe Files | File '%1' presents a security risk and should be deleted. | critical |
| 73 | CRM_Utils_Check_Component_Security | Remote Profiles Enabled | Warning: External profile support (aka "HTML Snippet" support) is enabled in system settings. | warning |
| 74 | CRM_Utils_Check_Component_Security | Security Warning | The system administrator has disabled security settings (%1). Connections to remote applications are insecure. | warning |
| 75 | CRM_Utils_Check_Component_Source | Old files | The local system includes old files which should not exist.... | warning |
| 76 | CRM_Utils_Check_Component_Timestamps | Timestamps and Timezones | This MySQL database stores certain fields with data-type "DATETIME". To improve timezone support, you <em>may</em> want to change these from "DATETIME" to "TIMESTAMP".... | notice |
See also discussion on [PR #17698](https://github.com/civicrm/civicrm-core/pull/17698).https://lab.civicrm.org/dev/core/-/issues/4538Error "There might be a data problem, contribution id could not be loaded fro...2023-09-07T22:24:30ZBjörn EndresError "There might be a data problem, contribution id could not be loaded from the line item" - Part 2We are getting the "There might be a data problem, contribution id could not be loaded from the line item" message with certain line items in our `5.64.0` installation.
It looks like the system assumes that a line item should _always_ h...We are getting the "There might be a data problem, contribution id could not be loaded from the line item" message with certain line items in our `5.64.0` installation.
It looks like the system assumes that a line item should _always_ have a contribution linked to it. That however, might not always be the case - in our setup we have two scenarios:
* Event registrations without registration fee
* Line items after a contribution was deleted
**Remark**: Despite the title, this is a different from #4441.https://lab.civicrm.org/dev/core/-/issues/2722Search kit - totals2023-09-07T05:03:27ZeileenSearch kit - totalsI had a super nice experience using search kit + afform to do a reconciliation last night. Being able to swap out the financial type & have it update without the overhead of a quick form reload was great & I was able to set up the contri...I had a super nice experience using search kit + afform to do a reconciliation last night. Being able to swap out the financial type & have it update without the overhead of a quick form reload was great & I was able to set up the contributions to edit in a popup via a link
What would have made it better would have been a grand total for the filtered results - I had to keep refreshing my civi-report to get totals
@colemanw just one for your mental list of feature requestshttps://lab.civicrm.org/dev/core/-/issues/2710Cannot disable contact type/sub-type2023-09-07T05:03:26ZMonish DebCannot disable contact type/sub-typeOverview
----------------------------------------
Cannot disable contact type or sub-type.
Reproduction steps
----------------------------------------
1. Click on **Administer -> Customize Data and Screens -> Contact Types**.
1. Disabl...Overview
----------------------------------------
Cannot disable contact type or sub-type.
Reproduction steps
----------------------------------------
1. Click on **Administer -> Customize Data and Screens -> Contact Types**.
1. Disable any contact type or sub-type
1. Doesn't affect, page refreshes but the disabled contact sub-type is still active
Current behavior
----------------------------------------
![after](/uploads/0b594c32f3a4f1b37a1afaad623db7cf/after.gif)
Environment information
----------------------------------------
* __Browser:__ Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master/5.41.alpha1_
* __PHP:__ _7.4__
* __CMS:__ _Drupal 7.30..._
* __Database:__ _MySQL 5.7.7..._
* __Web Server:__ _Apache 2.4..._
Comments
----------------------------------------
This is an issue with display, as checking the DB entries the contact types/sub-types are correctly set is_active=0 but not reflecting in admin page.5.41.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/60"Check number" isn't shown on Pay Later event registrations when edited2023-09-06T16:08:21Zlaryn"Check number" isn't shown on Pay Later event registrations when editedThis happens to me with an event registration that comes through 'webform_civicrm' as a "Pending (Pay Later)". When I try to edit the participant record to record a payment, the "Check Number" field never shows up despite "Check" being s...This happens to me with an event registration that comes through 'webform_civicrm' as a "Pending (Pay Later)". When I try to edit the participant record to record a payment, the "Check Number" field never shows up despite "Check" being selected as the payment instrument.
**I was able to reproduce on a demo server by doing the following**:
* Create a registration, marking it as "Pending (Pay Later)" and unchecking "Record Payment"
* Edit the new participant you just created, check "Record Payment" and make sure "Check" is selected as the payment instrument.
No "Check Number" field is shown.
![Screen_Shot_2018-04-11_at_3.52.02_PM](/uploads/02f92e016aa97074be80d410ca596db1/Screen_Shot_2018-04-11_at_3.52.02_PM.jpg)5.2.0eileeneileenhttps://lab.civicrm.org/dev/core/-/issues/4545Events - Self service and change options after initial registration2023-09-06T13:20:42ZtreseroEvents - Self service and change options after initial registrationThis is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Jo...This is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Joe wants to add this to his registration.
Scenario 2: Joe now realizes that he wants to add his wife.
Scenario 3: Joe's friend Jeff wants to go, and also play golf.
You get the idea.
As Events is now, there is no way to adjust your registration and it has to be done manually. That is not an option for 700 - 800 registrations run by all volunteers (i.e. we don't have any paid staff). Another issue is we can't make the payment required as it would have to be paid when there is a "new" change. Making it optional, well, you can see the problem.
My thinking would be to look up email, or something and populate the form etc. We already require them to create a wordpress account so that could also be used. It's just not there.
Also, we have 25,000+ constituents that were imported from a legacy system. They don't have any accounts, but it would be nice if there were a way to match emails (where possible, I know not all have updated/current emails), but this is a less important scenario.
I have coding skills, but as we are all volunteers, I don't have much time. There is some money to budget for a developer. All code will be added back to the public.
![image.png](/uploads/9e7d2100f9b61ee6b871d0467d58338d/image.png)
As you can see, this is an example. Of course, none is not an option. but if we added other additions, or they want to add another person, it has to be manually done.https://lab.civicrm.org/dev/joomla/-/issues/53[Joomla 4.0] Mosaico build screen clipped (maybe a Mosaico issue)2023-09-06T10:36:42Znicol[Joomla 4.0] Mosaico build screen clipped (maybe a Mosaico issue)Mosaico is loaded in an iFrame, with a fixed position that is lost behind the Joomla UI:
![image](/uploads/752b2ea5a9ccc68e0fe8daedd0e023fe/image.png)
something like
`#crm-mosaico {
left: 288px;
top: 66px;
width: calc(100vw - 288px);...Mosaico is loaded in an iFrame, with a fixed position that is lost behind the Joomla UI:
![image](/uploads/752b2ea5a9ccc68e0fe8daedd0e023fe/image.png)
something like
`#crm-mosaico {
left: 288px;
top: 66px;
width: calc(100vw - 288px);
height: calc(100vh - 66px);
}`
would work if the Joomla sidebar is extended and
`#crm-mosaico {
left: 48px;
width: calc(100vw - 48px);
}`
if it isn't, but there's no helpful Joomla classes to differentiate between these states via a parent selector. Even if that was fixed, to avoid having to force this with `!important`, may be better to address this in Mosaico's absolute positioning script..https://lab.civicrm.org/dev/core/-/issues/2694What is the correct way to cancel an Event Registration that is marked Pendin...2023-09-06T05:03:19ZclementWhat is the correct way to cancel an Event Registration that is marked Pending Pay Later?Overview
----------------------------------------
we have been registering participants online for our paid events and marking them by default to "Pending Pay Later" status. However, when some of the participants cancels their registrati...Overview
----------------------------------------
we have been registering participants online for our paid events and marking them by default to "Pending Pay Later" status. However, when some of the participants cancels their registration and we go into their Contribution record to cancel those contribution, the Payment field will register a deficit amount equal to the event fee. Since payment was still pending when the cancellation of registration was made, we were expecting the payment amount to still be at zero.
i attach a screenshot of the contribution record of such a cancelled contribution to illustrate:
[screenshot]
![WHeZv](/uploads/cc9de4f94d2e4d0dbfeb466ee2a71bc2/WHeZv.png)
The Payment details (at the bottom of the screenshot) had Amount as $0 since this was "Pending Payment Later". But when we change the Contribution Status to "Cancelled" to indicate a cancellation of this registration, the Amount changed to "-$30" which was the fee for the event. this then affects the accounting as CIVICRM will think we are $30 short due to this cancellation.
Is it the case that "Cancelled" shouldn't be used in this case? We tried others and it seems "Failed" will cancel the event registration and not register any deficit in the payment. However, I would like to get the view of the community on whether this is the right way to cancel a event registration that is marked "Pending Pay Later"?
Also, if the behaviour of recording a deficit in Payment is correct when the event registration is changed to "Cancelled", what situation should this be used for ? Is it when a refund is due?
Thanks.
This problem was posted to StackExchange
https://civicrm.stackexchange.com/questions/39677/what-is-the-correct-way-to-cancel-an-event-registration-that-is-marked-pending-p
Reproduction steps
----------------------------------------
Online register at a CIVICRM event that allow Pay Later in cash
Cancel the registration in the backend
Check the payment record
Current behaviour
----------------------------------------
we have been registering participants online for our paid events and marking them by default to "Pending Pay Later" status. However, when some of the participants cancels their registration and we go into their Contribution record to cancel those contribution, the Payment field will register a deficit amount equal to the event fee. Since payment was still pending when the cancellation of registration was made, we were expecting the payment amount to still be at zero.
Expected behaviour
----------------------------------------
Since the event is "Pending Pay Later", cancellation should not incur any deficit amount in Payment but should be 0.
Environment information
----------------------------------------
[civicrm 5.10.4 - WP 5.3.2]
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/3410Registering a participant with Pending event payment gives misleading informa...2023-09-06T00:16:18ZspalmstromRegistering a participant with Pending event payment gives misleading information.1. Register a participant for an event.
1. Record a payment as pending, not complete.
The payment is not recorded in the database, but is displayed in the receipt emailed to that participant. Surely the receipt should not show that mone...1. Register a participant for an event.
1. Record a payment as pending, not complete.
The payment is not recorded in the database, but is displayed in the receipt emailed to that participant. Surely the receipt should not show that money has been paid when it is not recorded on the system?
No record of payment here:
![image](/uploads/cd696e04f6227e4446e142e35ffa81a0/image.png)
but here is the body of the email.
Dear First_1003,
===========================================================
Event Information and Location
===========================================================
Conference 2022
13th May, 2022 12:00 AM-15th May, 2022 12:00 AM
xxxxxxx
xxxxxx
xxx, xxxe xxx xxx
xxx xxx
Event Contacts:
Phone: xxxx
Email: xxxxx
===========================================================
Registered Email
===========================================================
first_1003.last_1003@somedomain.com
===========================================================
Event Fee(s)
===========================================================
---------------------------------------------------------
Item Qty Each Total
----------------------------------------------------------
En suite double 1 £ 150.00 £ 150.00
**Total Paid: £ 20.00
Balance: £ 130.00**
Registration Date: 31st January, 2022 4:40 PM
Transaction Date: 31st January, 2022 4:41 PM
Financial Type: Conference Fee
Paid By: Online payment
==========================================================
Conference Fields
==========================================================
Dietary Requirements:
Music:
Other:
Subsidy Fund (Optional):
==========================================================
Conference Payment
==========================================================
Payment options: Deposit of £20 per person online
Notice the payment is recorded.5.66.0https://lab.civicrm.org/dev/core/-/issues/1891"applyLocale()" does not apply desired locale when "inheritLocale" is set2023-09-05T13:38:59Zhaystack"applyLocale()" does not apply desired locale when "inheritLocale" is setFollowing up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM...Following up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L173) when there is a locale requested in a URL that uses the `lcMessages` query param or when there's an existing locale set in the session.
The session locale is set from the `$ufm->language` locale [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L187) when there's a logged-in user and the locale hasn't been determined by the `lcMessages` query param or there's no locale set in the session.
I cannot find anywhere else in the CiviCRM Core code where `$ufm->language` is read or set, so this appears to be circular logic that seems redundant to me.
Can we remove it since it's never actually used for anything practical?
**Correction:** both the `$ufm->language` and `lcMessages` session variable are set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Admin/Form/Setting/Localization.php#L336-L338), but this only sets the locale for the Contact/User that saves that particular form. It doesn't alter the circularity of the logic in `applyLocale()`.5.29.0haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1890Remove `ufUniqID` from Core2023-09-05T13:38:55ZhaystackRemove `ufUniqID` from CoreI'm auditing the `synchronize()` procedure with the aim of rationalising what happens during page loads in WordPress - due to reports of multiple Contacts being created (see [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/iu...I'm auditing the `synchronize()` procedure with the aim of rationalising what happens during page loads in WordPress - due to reports of multiple Contacts being created (see [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/iurq3k4pkj8mpbxmb7kttyg5xo) for example) and have found that the `ufUniqID` session variable is only ever *set* and never *read* in CiviCRM.
It is set in Core in:
* `CRM_Core_BAO_UFMatch::synchronize()` [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/UFMatch.php#L96) and [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/UFMatch.php#L128)
And in CiviCRM WordPress by the REST API (presumably for consistency with Core) in:
* `CiviCRM_WP_REST\Civi\Mailing_Hooks\Plugin::set_civi_user_session()` [here](https://github.com/civicrm/civicrm-wordpress/blob/7fc81f0289d63dd6577d7e7046303cc6dc850f8f/wp-rest/Plugin.php#L355)
Can we remove it since it's never actually used?5.29.0https://lab.civicrm.org/dev/core/-/issues/3114CiviMail - Error on sending/viewing mail via Mosaico following core update2023-09-05T09:58:20ZsbyrneCiviMail - Error on sending/viewing mail via Mosaico following core updateWe're seeing the error: "DB Error: no such field" when trying to send email from Mosaico. This happens regardless of whether the email is a test, or going out to the intended recipients. The error appears immediately upon submitting the ...We're seeing the error: "DB Error: no such field" when trying to send email from Mosaico. This happens regardless of whether the email is a test, or going out to the intended recipients. The error appears immediately upon submitting the mailing.
We're also unable to view old mailings submitted via Mosico, with the same error appearing but as a webpage rather than a pop-up.
This started happening after we upgraded CiviCRM from 5.39.0 to 5.46.0.
"Traditional" mails are working fine (sending and viewing)
I've done a few basic things to fix the problem with no success:
- Cleaned all caches
- Tricked Civi into thinking it was running an older version of the database and upgraded again to rule out problems with the DB update
- Upgraded Civi to 5.47.0
- Updated Mosaico to 2.9, while also installing Form Core and Seatch kit. Completed additional database updates required by this.
The error that appears while sending the mailing doesn't leave anything in the error log. I do get the following when viewing old mailings though:
```
Mar 11 16:35:20 [error]
$Fatal Error Details = array:3 [
"message" => "DB Error: no such field"
"code" => null
"exception" => CiviCRM_API3_Exception {#3486
-extraParams: array:4 [
"error_code" => "no such field"
"tip" => "add debug=1 to your API call to have more info about the error"
"is_error" => 1
"error_message" => "DB Error: no such field"
]
#message: "DB Error: no such field"
#code: 0
#file: ".../sites/all/modules/civicrm/api/api.php"
#line: 134
trace: {
/.../sites/all/modules/civicrm/api/api.php:134 {
› if (is_array($result) && !empty($result['is_error'])) {
› throw new CiviCRM_API3_Exception($result['error_message'], CRM_Utils_Array::value('error_code', $result, 'undefined'), $result);
› }
}
/.../sites/all/modules/civicrm/CRM/Mailing/Page/View.php:148 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:319 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:69 { …}
/.../sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/.../sites/all/modules/civicrm/drupal/civicrm.module:471 { …}
/.../domains/secure/htdocs/includes/menu.inc:527 { …}
/.../domains/secure/htdocs/index.php:21 { …}
}
}
]
Mar 11 16:35:20 [debug] $backTrace = #0 /.../domains/secure/htdocs/sites/all/modules/civicrm/CRM/Core/Error.php(433): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /.../domains/secure/htdocs/sites/all/modules/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(CiviCRM_API3_Exception))
#2 /.../domains/secure/htdocs/sites/all/modules/civicrm/drupal/civicrm.module(471): CRM_Core_Invoke::invoke((Array:3))
#3 /.../domains/secure/htdocs/includes/menu.inc(527): civicrm_invoke("mailing", "view")
#4 /.../domains/secure/htdocs/index.php(21): menu_execute_active_handler()
#5 {main}
```
Environment:
- Debian 10 (64 bit)
- MariaDB 10.3
- PHP 7.3
- Drupal 7.88
- CiviCRM 5.47.0
- Mosaico 2.9https://lab.civicrm.org/dev/core/-/issues/2712Add schema knowledge of whether to use database logging on specific tables2023-09-05T05:03:23ZeileenAdd schema knowledge of whether to use database logging on specific tablesProposal
1) Add a new parameter 'database_logging' to the dao schema (as documented [here](https://docs.civicrm.org/dev/en/latest/framework/database/schema-definition/))
2) Update Gencode to add this to the tables DAO
3) regenerate the ...Proposal
1) Add a new parameter 'database_logging' to the dao schema (as documented [here](https://docs.civicrm.org/dev/en/latest/framework/database/schema-definition/))
2) Update Gencode to add this to the tables DAO
3) regenerate the dao
4) let it go stale
5) regenerate the dao
6) let it go stale
7) regenerate the dao
8) quick merge it
9) update the function & test to pay attention - see [this pr](https://github.com/civicrm/civicrm-core/pull/20918) for clues as to where both live
10) bonus - rip out all the exceptions in the function that exist because we don't have ^^ (eg. skipping civicrm_log)
See https://github.com/civicrm/civicrm-core/pull/20918/files#issuecomment-884095655
Note the existing parameter 'log' relates to the civicrm_log tablehttps://lab.civicrm.org/dev/core/-/issues/2697Contact acl caching - could it be even worse than we thought????2023-09-05T05:03:23ZeileenContact acl caching - could it be even worse than we thought????https://lab.civicrm.org/dev/financial/-/issues/162Simplify decision as to whether to use a pdf on emails2023-09-05T04:20:10ZeileenSimplify decision as to whether to use a pdf on emailsCurrently the code that determines whether to attach a pdf for membership emails only attaches it as a pdf if the tax amount is non-zero
This seems both confusing and pointless - the proposal here is to send as a pdf as long as
1) is_...Currently the code that determines whether to attach a pdf for membership emails only attaches it as a pdf if the tax amount is non-zero
This seems both confusing and pointless - the proposal here is to send as a pdf as long as
1) is_email_pdf is true and
2) invoicing is enabled
I feel like 1 and 2 could be separated but they are currently linked so I would suggest any proposals to change that are a follow uphttps://lab.civicrm.org/dev/core/-/issues/3778Event participant registered by contact ID2023-09-04T08:05:09Zmattwiremjw@mjwconsult.co.ukEvent participant registered by contact IDSee discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary...See discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary participant even when the user selects "Not X, or want to register a different person" (ie. URL has the parameter cid=0).
The "registered_by_id" field requires a participant ID and not a contact ID. This means that you cannot record that you registered one or more participants unless you are also a participant of that event.
Why not change registered_by_id to a contact ID? That's likely to have all sorts of unexpected impacts as the existing field is used in various wonderful ways (eg. registration emails behave a bit differently if there is a registered_by_id).
Does this fix everything?
No, not yet. That will require more work on the UI / mailing side of things to use the new field. But it's accessible as part of the Participant entity which means it can be used via the API and with searchkit.
This PR includes a little bit of UI work on the backend event participant form to allow you to set the new "registered by contact" field and this form will prefer that field.
What about setting the primary participant ID when they weren't the one registering?
Yes, this PR fixes that. It checks if the contact ID on the form is the same as the primary participant contact ID. If it's not it won't set the registered_by_id field.
Core patches:
- ~~https://github.com/civicrm/civicrm-core/pull/24167 - Add created_id field to civicrm_participant~~ merged
- ~~https://github.com/civicrm/civicrm-core/pull/24304 - Add code hook to set civicrm_participant.created_id~~ merged
- https://github.com/civicrm/civicrm-core/pull/24749 - Add 'Registered by Contact ID' to civireport
- _Need to extract patches from https://github.com/civicrm/civicrm-core/pull/23936 for Quickform UI etc._
- https://github.com/civicrm/civicrm-core/pull/24750 - Work in progress for participant forms.