Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-06-11T14:57:45Zhttps://lab.civicrm.org/dev/core/-/issues/3634When using a smart group as a mailing list, users who unsubscribe from the sm...2022-06-11T14:57:45Ztom.mWhen using a smart group as a mailing list, users who unsubscribe from the smart group are still included in the mailing.It looks like in CRM/MailingBAO/Mailing.php, is not taking into account those who have been removed from the smart group. Civi version 5.3.
```
if (count($includeSmartGroupIDs)) {
$query = CRM_Utils_SQL_Select::from($contact)
...It looks like in CRM/MailingBAO/Mailing.php, is not taking into account those who have been removed from the smart group. Civi version 5.3.
```
if (count($includeSmartGroupIDs)) {
$query = CRM_Utils_SQL_Select::from($contact)
->select("$contact.id as contact_id, $entityTable.id as $entityColumn")
->join($entityTable, " INNER JOIN $entityTable ON $entityTable.contact_id = $contact.id ")
->join('gc', " INNER JOIN civicrm_group_contact_cache gc ON $contact.id = gc.contact_id ")
->join('mg', " INNER JOIN civicrm_mailing_group mg ON gc.group_id = mg.entity_id AND mg.search_id IS NULL ")
->join('temp', " LEFT JOIN $excludeTempTablename temp ON $contact.id = temp.contact_id ")
->where('gc.group_id IN (#groups)')
->merge($criteria)
->replaceInto($includedTempTablename, array('contact_id', $entityColumn))
->param('#groups', $includeSmartGroupIDs)
->param('#mailingID', $mailingID)
->execute();
}
```https://lab.civicrm.org/dev/core/-/issues/3633Error notification when scheduling civimail for current day may be incorrect2024-02-21T05:03:32ZrobinhoodError notification when scheduling civimail for current day may be incorrectThis is a minor issue. When setting up a civimail at a scheduled date and time, any time on the current day triggers "The scheduled date and time is in the past" error popup, even if the scheduled time is in the future. The error does n...This is a minor issue. When setting up a civimail at a scheduled date and time, any time on the current day triggers "The scheduled date and time is in the past" error popup, even if the scheduled time is in the future. The error does not prevent the civimail from being scheduled for the current day, but it is confusing to the user.
Edit: Using Civicrm 5.3.2 on Wordpress 4.9.8https://lab.civicrm.org/dev/core/-/issues/3632Mass SMS not sent to contacts whose mobile phone is not their Primary phone2022-06-12T21:25:03ZkenMass SMS not sent to contacts whose mobile phone is not their Primary phoneI have just upgraded to CiviCRM 5.3.2 and have found that Mass SMS are not being delivered to contacts where the mobile phone is not the Primary phone.
The change was made in this commit https://github.com/civicrm/civicrm-core/commit/6f...I have just upgraded to CiviCRM 5.3.2 and have found that Mass SMS are not being delivered to contacts where the mobile phone is not the Primary phone.
The change was made in this commit https://github.com/civicrm/civicrm-core/commit/6f3a35e0986bc21ffbf730c7d3f20f2894c1bb58#diff-8c026e80a2f25f46826dd9568bc301b0 in this PR https://github.com/civicrm/civicrm-core/pull/11558 as a result of this refactoring https://issues.civicrm.org/jira/browse/CRM-21316.
It seems from the unit test case that the code handles the case where a contact has multiple Mobile phones and chooses the Primary phone over the non-Primary phone.
But the code fails if the Primary phone is not the Mobile one.
What is needed is something similar to the Mass Email case. For emails, CRM_Mailing_BAO_Mailing::getLocationFilterAndOrderBy() generates a WHERE clause and an ORDER BY clause that ensures the right emails are selected and preferred.https://lab.civicrm.org/dev/core/-/issues/3631Unexpected behavior from api.MailingEventSubscribe.create2024-02-21T05:03:31ZginkgofjgUnexpected behavior from api.MailingEventSubscribe.createIn creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
* confirm that this is not an unexpected us...In creating a custom e-newsletter sign-up form for a client, I encountered the following unexpected behaviors. I'm happy to submit one or more corrective pull requests but would first like to:
* confirm that this is not an unexpected use of this API,
* confirm that these behaviors are unexpected,
* get two cents from others on the approach, and
* get acceptance criteria for the PR(s) -- i.e., what tests do I need to write/pass?
The unexpecteds:
1. This is cosmetic, but the API metadata are wrong. The API Explorer describes the params as though they were for unsubscription.
2. Suppose contact X is already a member of a mailing group Y. If their IDs are passed to this API, the contact's status in the group is "downgraded" to "Pending" and the user must reconfirm membership by clicking the link emailed to them.
3. The contact's DO NOT MAIL and NO BULK EMAILS Communication Preferences are not updated. These changes should not be effected by the initial API call, but after the user clicks the confirmation link emailed to her.
The approaches:
1. This should be a trivial update to the API's `_spec()` function.
2. The API delegates to `CRM_Mailing_Event_BAO_Subscribe::subscribe()`. I would fix the problem in the delegate by checking for group membership and bailing out early if the record already exists with the appropriate status.
3. Confirmation is handled by `CRM_Mailing_Page_Confirm` which delegates to `CRM_Mailing_Event_BAO_Confirm::confirm()`. I would unset the communication preferences in question in the delegate.ginkgofjgginkgofjghttps://lab.civicrm.org/dev/core/-/issues/3630Fix accessible mailings when users don't have view all contacts permission2024-02-19T05:03:29ZMichael McAndrewFix accessible mailings when users don't have view all contacts permissionCRM_Mailing_BAO_Mailing::mailingACLIDs is responsible for limiting the mailings that are visible to users when they do not have either view or edit all contacts (at the BAO layer at least)
It works by returning a list of Ids of mailings...CRM_Mailing_BAO_Mailing::mailingACLIDs is responsible for limiting the mailings that are visible to users when they do not have either view or edit all contacts (at the BAO layer at least)
It works by returning a list of Ids of mailings that should be visible.
One of the queries that is used to construct this list looks like this:
```sql
SELECT DISTINCT(m.id) AS id
FROM civicrm_mailing m
LEFT JOIN civicrm_mailing_group g ON g.mailing_id = m.id
WHERE ((g.entity_table LIKE 'civicrm_group%'
AND g.entity_id IN (3))
OR (g.entity_table IS NULL
AND g.entity_id IS NULL
AND m.domain_id = 1))
```
The logic behind the `OR (g.entity_table IS NULL AND g.entity_id IS NULL AND m.domain_id = 1) where clause looks wrong to me.
My assumption is that it is there because if you created a mailing (added lots of content, etc.) but didn't then assign it a group, it would suddenly disappear from view when you went back to look for it because it didn't contain a group that you have access to.
The problem with this condition is that the user also gets to see mailings by other contacts who have similarly not defined any groups yet.
Provided the above assumption is correct, a better condition would be `OR m.created_id = $user_id` (where user id is the contact ID of the current logged in user.
@JonGold, I wonder what you think about this given that your issue https://issues.civicrm.org/jira/browse/CRM-16981 was similar in nature. @seamuslee - I'm guessing you might have some thoughts on this as well.
Also related is https://issues.civicrm.org/jira/browse/CRM-18181 (though I have not yet got my head around how :)
Aaalso related, in my experimentation, the Mailing api does not respect these permissions, so people get to see all mailings in the recipients field in the Angular powered new CiviMail UI. Are you experiencing that @JonGold?
I've running the above suggestion with a client at the moment. If we get some consensus on how it should work, I would be happy to Shepard this into core.https://lab.civicrm.org/dev/core/-/issues/3629Extraneous space in From address causes on-hold set on all recipients2022-06-11T14:57:32ZBobSExtraneous space in From address causes on-hold set on all recipientsIf a CiviMail email is sent with a From address having the form<br>
`"Name" <me@example.com>` (note two spaces before '<')<br>
then:
1. No emails are sent
2. **All recipients are marked On-Hold!**
Occurs on CiviCRM 4.7.26.
*Edit*: Al...If a CiviMail email is sent with a From address having the form<br>
`"Name" <me@example.com>` (note two spaces before '<')<br>
then:
1. No emails are sent
2. **All recipients are marked On-Hold!**
Occurs on CiviCRM 4.7.26.
*Edit*: Also occurs on 5.2.1
Could not reproduce on demo site as sending email is not enabled there.
The following three CMS log entries are created for each recipient:
1:<pre>Ignoring exception thrown by nullHandler: , Validation failed for: "(INVALID)" <(INVALID)></pre>
2:<pre>$backTrace = #0 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Core/Error.php(959): CRM_Core_Error::backtrace("backTrace", TRUE) #1 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/packages/PEAR.php(921): CRM_Core_Error::nullHandler(Object(PEAR_Error)) #2 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/packages/PEAR.php(577): PEAR_Error->__construct("Validation failed for: \"(INVALID)\" <(INVALID)>", NULL, 16, (Array:2), NULL) #3 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/packages/PEAR.php(236): PEAR::_raiseError(NULL, "Validation failed for: \"(INVALID)\" <(INVALID)>") #4 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/packages/Mail/RFC822.php(209): PEAR::__callStatic("raiseError", (Array:1)) #5 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/packages/Mail.php(191): Mail_RFC822->parseAddressList((Array:2), "localhost", FALSE) #6 /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/packages/Mail/mail.php(151): Mail->prepareHeaders((Array:10)) #7 ...</pre>
3:<pre>
Notice: Only variables should be passed by reference in CRM_Mailing_BAO_MailingJob->deliverGroup() (line 721 of /var/www/clients/client1/web3/web/drupal/sites/all/modules/civicrm/CRM/Mailing/BAO/MailingJob.php).
</pre>5.5.0https://lab.civicrm.org/dev/core/-/issues/3628Add pre/post hook for CRM_Mailing_BAO_MailingJob2022-06-15T11:19:25ZMonish DebAdd pre/post hook for CRM_Mailing_BAO_MailingJobThis ticket is about adding pre, post hook to MailingJob and it involve:
1. Call the pre/post hook inside `CRM_Mailing_BAO_MailingJob::create()`
2. Add `CRM_Mailing_BAO_MailingJob::deleteMailingJob` to delete Mailing Jobs and add pre/pos...This ticket is about adding pre, post hook to MailingJob and it involve:
1. Call the pre/post hook inside `CRM_Mailing_BAO_MailingJob::create()`
2. Add `CRM_Mailing_BAO_MailingJob::deleteMailingJob` to delete Mailing Jobs and add pre/post delete hook
3. Replace all the DAO call with corresponding create and delete fn in the codebase.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3627Only add closing quote to href token output when necessary2022-06-11T14:57:26ZMichael McAndrewOnly add closing quote to href token output when necessary[Lines 1345 to 1350 of CRM/Mailing/BAO/Mailing.php](https://github.com/civicrm/civicrm-core/blob/master/CRM/Mailing/BAO/Mailing.php#L1345-L1350) add a trailing quote to tokens of 'type' `embedded_url` as according to the code:
```
...[Lines 1345 to 1350 of CRM/Mailing/BAO/Mailing.php](https://github.com/civicrm/civicrm-core/blob/master/CRM/Mailing/BAO/Mailing.php#L1345-L1350) add a trailing quote to tokens of 'type' `embedded_url` as according to the code:
```
// add trailing quote since we've gobbled it up in a previous regex
// function getPatterns, line 431
```
In my testing, sometimes the trailing quote is not gobbled, e.g. in this example `<p><a href="https://example.org/communication-preferences?cid1={contact.contact_id}&{contact.checksum}">Click here to select your communication preferences</a></p>`.
As a fix, I am proposing to only add a closing quote if the url does not already have one.https://lab.civicrm.org/dev/core/-/issues/3626"New Mailing" prematurely schedules blasts and old mailings can be resent2022-06-11T14:57:24Ztotten"New Mailing" prematurely schedules blasts and old mailings can be resent## Steps to reproduce
* Open a MySQL console where you can monitor the content of `civicrm_mailing_job`.
* Make a `Mailing => New Mailing`
* Fill in name/subject/recipients/body on the first page.
* Go to the second page
* __Observe__:...## Steps to reproduce
* Open a MySQL console where you can monitor the content of `civicrm_mailing_job`.
* Make a `Mailing => New Mailing`
* Fill in name/subject/recipients/body on the first page.
* Go to the second page
* __Observe__: In the MySQL console, observe that there are no jobs scheduled for this mailing.
* Set a delivery time. *But don't hit `Submit`*. (You're just thinking about delivery... but not actually sending yet.)
* Open an HTML or plain-text preview.
* __Observe__: In the MySQL console, observe that there is now a scheduled job for this mailing.
To resend an old mailing:
* Any mailing will be queued for redelivery if a user with permission to use CiviMail visits URL `civicrm/a/#/mailing/<MAILING_ID>` (we've seen several users end up on this URL, apparently via browser history)
## Mitigating factors
The only way I've found to trigger the premature mailing (so far) has been to explicitly set the delivery date. It's quite bad to be sending prematurely, but I think it's taken a while to recognize because the delivery date is *the last thing* in the entire process -- *most of the time*, one doesn't set the delivery date until everything else has been settled. This probably means the real-world impact hasn't been as bad one might fear.
## Context
This appears to be a regression in 4.7.31. Related PRs:
* https://issues.civicrm.org/jira/browse/CRM-21260
* https://issues.civicrm.org/jira/browse/CRM-21316
* https://issues.civicrm.org/jira/browse/CRM-21749
* https://github.com/civicrm/civicrm-core/pull/11142/
* https://github.com/civicrm/civicrm-core/pull/11653/
## Solution
* Because the fix is in javascript, resolving this bug requires flushing CiviCRM caches (`cv flush` command) after upgrading to CiviCRM 5.0.05.0.0https://lab.civicrm.org/dev/core/-/issues/3625Recipient groups in a scheduled mail return no recipients.2022-06-11T14:57:22ZspalmstromRecipient groups in a scheduled mail return no recipients.Creating or reusing a scheduled mail in CiviMail v4.7.31 under Joomla returns no recipients when groups are added to the recipient list. The demo sites are several versions behind and run under Drupal, so can't be used to verify. At thi...Creating or reusing a scheduled mail in CiviMail v4.7.31 under Joomla returns no recipients when groups are added to the recipient list. The demo sites are several versions behind and run under Drupal, so can't be used to verify. At this point I'm unsure of where the search takes place, so have a problem debugging it.https://lab.civicrm.org/dev/core/-/issues/3624Additional Bounce Patterns according to SMTP status codes2022-06-11T14:57:20ZpbatroffAdditional Bounce Patterns according to SMTP status codesCurrently SMTP status codes are mostly ignored when processing and classifying mails for bounces. I wrote a [stackexchange](https://civicrm.stackexchange.com/questions/23091/bounce-pattern-smtp-error-codes) question to see if someone had...Currently SMTP status codes are mostly ignored when processing and classifying mails for bounces. I wrote a [stackexchange](https://civicrm.stackexchange.com/questions/23091/bounce-pattern-smtp-error-codes) question to see if someone had already implemented this.
Since I got no feedback, I did it myself and had promising test results with the additional pattern:
From a sample bounce pool of approx. 4500 Mails, ~1500 were classified as syntax bounce (read: unknown) with the default bounce pattern. With the new pattern that shrank down to 400. (With some custom German away messages not yet parsed, so results should be even better, around ~200 syntax bounces)
My question would be if a pull request on civicrm-core is preferred, or if I should build an extension managing additional bounce pattern? I realize that with only 10 classifications available in CiviCRM-Bounce Type Vs. 30-50 SMTP Error codes the mapping could be open for some discussion, but I think this is a good start.
See [here](https://www.usps.org/info/smtp_codes.html) for simple smtp codes and [here](https://www.usps.org/info/smtp_status.html) for enhanced status codes as reference according to the [RFC-5248](https://tools.ietf.org/html/rfc5248#page-5)https://lab.civicrm.org/dev/core/-/issues/3623After upgrade to 5.48.0 Error: Mailing cannot be sent. There are missing or i...2022-06-11T14:57:18ZoschopferAfter upgrade to 5.48.0 Error: Mailing cannot be sent. There are missing or invalid fields (subject,name,from_name,from_email,body).After upgrading from CiviCRM 5.47.2 to 5.48.0, any attempted mailing creates an error after clicking "Submit Mailing" with "Mailing cannot be sent. There are missing or invalid fields (subject,name,from_name,from_email,body)." Those fiel...After upgrading from CiviCRM 5.47.2 to 5.48.0, any attempted mailing creates an error after clicking "Submit Mailing" with "Mailing cannot be sent. There are missing or invalid fields (subject,name,from_name,from_email,body)." Those fields are clearly filled in in the mailing, and when submitting a test mailing, it goes through, and the test mailing is sent and delivered.
I'm on Drupal 7. Using CiviMail with Mosaico.https://lab.civicrm.org/dev/core/-/issues/3622[regression] CiviMail crashing on send instead of throwing exception when usi...2022-06-11T14:57:15ZJonGold[regression] CiviMail crashing on send instead of throwing exception when using Job.executeIn 5.27.0+, [PR #17277](https://github.com/civicrm/civicrm-core/pull/17277) is causing CiviMail to crash in the most common configuration on any SMTP error.
For example, if a contact has an invalid email address, then it could produce a...In 5.27.0+, [PR #17277](https://github.com/civicrm/civicrm-core/pull/17277) is causing CiviMail to crash in the most common configuration on any SMTP error.
For example, if a contact has an invalid email address, then it could produce an SMTP error - and cause a failure which prevents other messages from going out.
### Replication
* Create a contact with an email address that will generate an SMTP error. Screenshot below; you know best how to cause this problem in your own env :)
![Selection_998](/uploads/9670a781edd7e8838d9b4ae725f14212/Selection_998.png)
* Send a transactional email to this user. You should get an error like the one in the screenshot.
* View the Civi logs. You should have two new entries; `Ignoring exception thrown by nullHandler` and a backtrace.
* Now, create a CiviMail to a group containing this contact.
* If you send the mailing via `Job.execute`, you get the error but NOT the backtrace; any other recipients in the mailing will not get the mailing, it exits silently (there will be an error in the Scheduled Job log for `send_mailing`). The email is not placed on hold; CiviMail is now broken and won't send any new mailings, nor finish the existing mailing.
* Now, send the same mailing via `Job.send_mailing`. The bad email address is handled correctly (placed on hold, mailing continues, backtrace appears in log).
### Technical notes
* When you run `Job.execute`, `CRM_Core_JobManager` specifies a [custom fatal error handler](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/JobManager.php#L44).
* `CRM_Core_Error::nullHandler` calls `CRM_Core_Error::debug_log_message`.
* [PR #17277](https://github.com/civicrm/civicrm-core/pull/17277) adds a call to the custom fatal error handler in `CRM_Core_Error::debug_log_message`.
* Since `CRM_Core_JobManager::CRM_Core_JobManager_scheduledJobFatalErrorHandler` throws an exception, this causes the job to exit silently.
#### Correct backtrace
```
Jul 31 12:05:40 [error] Ignoring exception thrown by nullHandler: 10005, Failed to add recipient: onddddd@zabuntu.lan [SMTP: Invalid response code received from SMTP server while sending email. This is often caused by a misconfiguration in Outbound Email settings. Please verify the settings at Administer CiviCRM >> Global Settings >> Outbound Email (SMTP). (code: 550, response: 5.1.1 <onddddd@zabuntu.lan>: Recipient address rejected: User unknown in local recipient table)]
Jul 31 12:05:40 [debug] $backTrace = #0 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Error.php(963): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::nullHandler(Object(PEAR_Error))
#2 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(577): PEAR_Error->__construct("Failed to add recipient: onddddd@zabuntu.lan [SMTP: Invalid response code rec...", 10005, 16, (Array:2), NULL)
#3 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(236): PEAR::_raiseError(NULL, "Failed to add recipient: onddddd@zabuntu.lan [SMTP: Invalid response code rec...", 10005)
#4 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/mail/Mail/smtp.php(325): PEAR::__callStatic("raiseError", (Array:2))
#5 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/vendor/pear/mail/Mail/smtp.php(258): Mail_smtp->send_or_fail((Array:1), (Array:10), NULL)
#6 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Utils/Mail/FilteredPearMailer.php(68): Mail_smtp->send((Array:1), (Array:10), NULL)
#7 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Utils/Mail.php(303): CRM_Utils_Mail_FilteredPearMailer->send((Array:1), (Array:10), NULL)
#8 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Activity/BAO/Activity.php(1538): CRM_Utils_Mail::send((Array:10))
#9 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Activity/BAO/Activity.php(1236): CRM_Activity_BAO_Activity::sendMessage("\"a a\" <adminnnnn@zabuntu.lan>", "202", "205", "test2", "", "", "onddddd@zabuntu.lan", 630, (Array:0), "", "")
#10 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contact/Form/Task/EmailTrait.php(431): CRM_Activity_BAO_Activity::sendEmail((Array:1), "test2", "", "", "onddddd@zabuntu.lan", "202", "\"a a\" <adminnnnn@zabuntu.lan>", (Array:0), "", "", (Array:1), "", (Array:0), NULL, NULL)
#11 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contact/Form/Task/EmailTrait.php(351): CRM_Contact_Form_Task_Email->submit((Array:19))
#12 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Form.php(505): CRM_Contact_Form_Task_Email->postProcess()
#13 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Upload.php(152): CRM_Core_Form->mainProcess()
#14 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Upload.php(119): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contact_Form_Task_Email), "upload")
#15 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contact_Form_Task_Email), "upload")
#16 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Form_Task_Email), "upload")
#17 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Controller.php(347): HTML_QuickForm_Page->handle("upload")
#18 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#19 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(285): CRM_Utils_Wrapper->run("CRM_Contact_Form_Task_Email", "Activities", (Array:1))
#20 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:14))
#21 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:4))
#22 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/drupal/civicrm.module(456): CRM_Core_Invoke::invoke((Array:4))
#23 /home/jon/local/civicrm-buildkit/build/dmaster/web/includes/menu.inc(527): civicrm_invoke("activity", "email", "add")
#24 /home/jon/local/civicrm-buildkit/build/dmaster/web/index.php(21): menu_execute_active_handler()
#25 {main}
```5.27.4https://lab.civicrm.org/dev/core/-/issues/3621Work in Mosaico is easily lost2022-06-11T14:57:07ZphilmorbruWork in Mosaico is easily lostThere is a point of potentially horrible user experience when working with Mosaico mailings where a user's work can be lost with an inadvertent click of the mouse. There is no warning or recourse or ability to recover the work.
Within t...There is a point of potentially horrible user experience when working with Mosaico mailings where a user's work can be lost with an inadvertent click of the mouse. There is no warning or recourse or ability to recover the work.
Within the Mosaico editor, when a user wants to switch between blocks, content, or style, those selections are immediately below the Civi Menu (this may apply only to Joomla). A user can easily move the mouse pointer one pixel too high into the menu, shift the pointer back down to the Mosaico interface quickly and click, but the brief hovering over the menu has triggered a submenu which covers the Mosaico interface and is the element that receives the click. This happens too quickly for the user to withhold their intended click. Consequently, the menu choice is loaded in the browser, losing any unsaved work in Mosaico.
One possible fix is to hide the navbar when within the Mosaico editor, as there is no reason to need it in that context.https://lab.civicrm.org/dev/core/-/issues/3620"View in Browser" does not feed mailing statistics2024-02-19T05:03:28Ztotten"View in Browser" does not feed mailing statisticsI just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more lin...I just want to log the existence of the issue generally... suppose you send a newsletter and it has a "View in Browser" link.
Suppose the recipient uses that link. The view the mailing and then drill-down, clicking through some more links.
What happens to the stats?
* The web-based view does not count as an "Open". The MUA may or may not report back the "Open" on the original message.
* You will not have any "Click Through" events logged.
This is because the "View in browser" variant of the newsletter is not instrumented with tracking codes (while the MUA variant of the newsletter does have tracking codes).https://lab.civicrm.org/dev/core/-/issues/3619Error: Call to undefined method CRM_Utils_Mail_FilteredPearMailer::disconnect...2022-06-11T14:57:05ZorigamiusaError: Call to undefined method CRM_Utils_Mail_FilteredPearMailer::disconnect() in CRM_Mailing_BAO_MailingJob->deliverGroup()If the CiviCRM cron job encounters an undeliverable email address while running a mailing, it now fails with:
Error: Call to undefined method CRM_Utils_Mail_FilteredPearMailer::disconnect() in CRM_Mailing_BAO_MailingJob->deliverGroup() ...If the CiviCRM cron job encounters an undeliverable email address while running a mailing, it now fails with:
Error: Call to undefined method CRM_Utils_Mail_FilteredPearMailer::disconnect() in CRM_Mailing_BAO_MailingJob->deliverGroup() (line 668 of /.../sites/all/modules/civicrm/CRM/Mailing/BAO/MailingJob.php).
This didn't happen in the past (currently using CiviCRM 5.24.3 in Drupal 7).https://lab.civicrm.org/dev/core/-/issues/3618Smart group that are using a smart group in "Target Contact(s) in group" can ...2022-06-11T14:57:03ZsamuelsovSmart group that are using a smart group in "Target Contact(s) in group" can give false resultsQuite hard to reproduce but here is the way that should do :
* create a smart group `first group`
* create another smart `second group` group in advanced search with a relationship in the `first group` like so :
![Screenshot_2020-01-16...Quite hard to reproduce but here is the way that should do :
* create a smart group `first group`
* create another smart `second group` group in advanced search with a relationship in the `first group` like so :
![Screenshot_2020-01-16_Advanced_Search_CRM_de_la_Coop_SymbioTIC](/uploads/8d90206030bfc1f7e735c27b746070aa/Screenshot_2020-01-16_Advanced_Search_CRM_de_la_Coop_SymbioTIC.png)
* wait for the table civicrm_group_contact_cache to be emptied of information about `first group` (after 5 minutes if you do something like deleting a contact)
* go the `Manage group` and click on `second group` -> `Contacts` link to get the list of contacts for the group
It will not give you the proper result - probably 0 contacts because the `first_group` cache is not refreshed in that context.https://lab.civicrm.org/dev/core/-/issues/3617Contribution tokens with option values display values, not label2022-06-11T14:57:01ZJonGoldContribution tokens with option values display values, not labelTo replicate on dmaster:
* Edit any contribution to add a value for the custom field *How long have you been a donor?*.
* With **Find Contributions**, search for that contribution and create either an email or thank-you letter.
* Use a t...To replicate on dmaster:
* Edit any contribution to add a value for the custom field *How long have you been a donor?*.
* With **Find Contributions**, search for that contribution and create either an email or thank-you letter.
* Use a token to display the value of *How long have you been a donor?*.
* Print/send.
### Expected result
The token should render the label of the selected option, e.g. "Less than 1 year", "1-3 years".
### Observed result
The token renders the value, e.g., "1", "2".
Contact tokens behave in the expected way.
Note: This is not, AFAICT, a regression. While I can't find other user reports on this, I also don't see any indication in the code that this ever was accounted for.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3616Should tracking pixel be placed at start of email for when Gmail clips messages?2024-02-18T05:03:26ZlarsssandergreenShould tracking pixel be placed at start of email for when Gmail clips messages?With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open trac...With Mosaico templates, it isn't that difficult to reach Gmail's limit of 96-102kB with an email newsletter, after which your email message is clipped and not displayed in full. This is unfortunate in itself, but it also breaks open tracking as the tracking pixel is only embedded at the very end of the message and thus isn't fetched unless the reader clicks "View entire message".
Would it be worthwhile to consider putting the tracking pixel at the start of the message to avoid this issue? Obviously, less than ideal for those who don't display images, but I'm not sure how these two might balance out or if there is a clever way to have the best of both worlds.
I'd be happy to provide a patch, but not sure what the best way forward is here.
(Was a former Flexmailer issue, reposted here as I think this is still important.)https://lab.civicrm.org/dev/core/-/issues/3615<link> URLs are tracked and shouldn't be2022-06-13T09:15:05Zlarsssandergreen<link> URLs are tracked and shouldn't beIf you use <link href=URL> in a mailing template, for example to load a webfont, that URL is converted to a tracked URL. Presumably it shouldn't be as this makes a mess of the clickthrough statistics (every one of these links will be cou...If you use <link href=URL> in a mailing template, for example to load a webfont, that URL is converted to a tracked URL. Presumably it shouldn't be as this makes a mess of the clickthrough statistics (every one of these links will be counted as clicked as long as the user's mail client fetches the resource). In other words, a link being fetched in a not a click and shouldn't be counted as one.
Do we need to track any URLs that aren't inside an <a> tag? It might be easier to limit to <a... rather than trying to exclude <link.... The only valid way to write an <a> is with the tag right after the <, so I think we could just look for <a instead of <.
I can provide a patch if this approach is supported.