Thanks for this Jon. As you know, UnidosNow relies on it heavily. - Wil
Thanks, this cleared the error in 5.69.2 for me as well.
If the GUI (https://cc.unidosnow.org/civicrm/activity?action=add) would notify assignees when an activity is created. It'd be useful for the API to do so too. The GUI respects the setting in Administer > Customize Data and Screens > Display Preferences > Notify Activity Assignees and notification rules by Activity type. It'd be useful for the API to do so too.
The Activity is created but the assignees are not notified, even in situations where creating the equivalent activity via the GUI would have issued notifications.
Notify assignees using the same rules and notification format as the GUI.
See https://civicrm.stackexchange.com/q/45078/5446 Workaround is to call CRM_Activity_BAO_Activity::sendToAssignee() separately
Not likely @JonGold. Looks like that issue relates to Windows' use of "\" in the path and some regexps failing to match. We're on CentOS 7.
Clicking the blue help bubble for a custom field yields the error message "Unable to load help file." The log records an exception, attached. Non-custom fields are working normally.
Described in the overview.
The field post help text displays in a pop-up at the top right of the page.
This error is new (regression), but I don't know when it emerged. Lars confirmed correct operation on 5.58.1 and the problem on dmaster.
Tried to push a branch without success:
[cividev 16:29:16 core]$ git push origin anon-sms
Username for 'https://lab.civicrm.org': SRQ_civicrm
Password for 'https://SRQ_civicrm@lab.civicrm.org':
remote: You are not allowed to push code to this project.
fatal: unable to access 'https://lab.civicrm.org/dev/core.git/': The requested URL returned error: 403
[cividev 16:30:16 core]$
This is such a simple change it hardly warrants granting me permission! Add the two '+' lines to CRM/Activity/BAO/Activity.php:
// Get logged in User Id
if (empty($sourceContactId)) {
$sourceContactId = CRM_Core_Session::getLoggedInContactID();
}
+ // Ensure valid $sourceContactID if got here with an anonymous user
+ if (empty($sourceContactId)) $sourceContactId = $contactIds[0];
$text = &$activityParams['sms_text_message'];
N.B. I also tried pushing to github.com/civicrm/civicrm-core with identical results. In case it matters, I do have a CLI personal access token for github.com, but just a regular password for lab.civicrm.org
As noted in Stackexchange, CiviRules fails to send an immediate SMS if the condition is triggered by the anonymous user (e.g. follow-up to a webform). The workaround is to delay the action in CiviRules. Jaap pointed out the cause, "the delayed task gets a $sourceContactId = CRM_Core_Session::getLoggedInContactID(); (sites/all/modules/civicrm/CRM/Activity/BAO/Activity.php) whereas the webform triggered one doesn't."
The workaround isn't attractive. The typical user expects to receive a confirmation SMS right away. To simulate this w. the workaround we'd have to crank our cron heartbeat from 15 minutes down to 1 minute, and even that delay is quite unfriendly.
No SMS activities are created and no SMS sent.
The following line is added to the CiviCRM log: Nov 14 09:02:19 [error] Civirules api action exception: Not enough data to create activity object. API call: Sms.send with params: provider_id="6", template_id="294", alternative_receiver_phone_number="", contact_id="3027"
SMS sent, activities created with source contact per the webform's match or creation of a contact.
CiviCRM 5.43.1, CiviRules 2.3, Drupal 7.82
This issue is to provide context for a PR I'm hoping to submit right away. The PR detects the absence of $sourceContactID after the aforementioned assignment and stubs in the ID of the first contact. This is perhaps too broad a hammer, for instance CiviRules already sends emails sourced by this anonymous user contact ID without a problem. It appears the email logic corrects for this problem somewhere upstream of Activity.php, but the SMS logic doesn't.
wil_SRQ (8afe6682) at 11 May 21:05
@dietermartens - any chance there's interaction with another rule? I ask because my work-around in production was to add an Action Activity edit after the Action Assign and email. By instructing Activity edit to assign the activity to me and send the email, it also sends it to the assignee from Assign and email. Not sure why since Add.php has logic to exclude previous assignees, but it is keeping me afloat!
Cross-referencing follow-up comments in !137 (merged).
See merge request !144 (merged). Feels strange since 'send_email' is not a Civi api parameter, but Add.php is looking for !empty($this->apiParams['send_email']) and that's what !144 (merged) gives it.
See comments here. Corrects a regression error from merge request 133 that disabled sending emails. Instructs parent::processAction() to send the email by setting $this->apiParams['send_email'] = 1.
wil_SRQ (8afe6682) at 11 May 16:04
Added notice to parent::processAction() to send the email. Corrects...
wil_SRQ (b6a9427d) at 11 May 15:12
Merge branch 'master' of lab.civicrm.org:extensions/civirules
... and 233 more commits
Haven't come up with a patch that works yet, will keep trying.
Yes. Activities are being assigned to the contact in the trigger, only the emails aren't going out. I see that parent::processAction() has the code to send the emails, but apparently execution is not reaching that line.
@jaapjansma - Action "Assign activity and email" could be obsoleted if Action "Edit triggering activity" offered the option to assign the activity to the contact in the trigger. As of 2.23 it only permits assigning to a static list of contacts. File Form/AssignToContact.php has a YesNo for use_contact_trigger but I don't see the option in any "CiviRules Edit Action parameters" form. Thoughts?
@dietermartens - thank you for your work on this Action. Since upgrading to CiviRules 2.23, however, the emails aren't going out to the assignees in the CiviCRM instance I manage. As part of pull request !133 the line with
CRM_Case_BAO_Case::sendActivityCopy(...)
in file AssignNemail.php was removed. Did you have some other mechanism in mind for the email to go out to the assignees?
Sending an email with two attachments to multiple recipients fails
Emails sent and activities created.
As you can see in the screen snippet, I duplicated it in dmaster a few minutes ago. One of my users pointed me to this in 5.36.1/Drupal 7.80.
This is low priority. Sending attachments from Civi is not a best practice and my users have heard that. Documenting it in case it intersects with other more serious problems. And I guess to satisfy my OCD.
It is the same issue and the patch fixed it in my environment. Thanks and apologies that my searches in StackOverflow and here didn't find this.