Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Trivial
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.2.6
-
Fix Version/s: 4.3.0
-
Component/s: Core CiviCRM
-
Labels:None
Description
In CRM/Contact/Form/Search.php, around line 618 in the preProcess() function there is:
if ($this->_ufGroupID == NULL &&
$config->defaultSearchProfileID != NULL
)
That clause matches if you have set a defaultSearchProfileID.
Later in that function, we have:
if (!empty($this->_ufGroupID))
{ $this->set('id', $this->_ufGroupID); }Therefore, if $config->defaultSearchProfileID is not null, then the form's id value is set to the id of the default search profile.
Then, in CRM/Contact/Form/Task/PDF.php, around line 69 in the preProcess function we have:
$this->_activityId = CRM_Utils_Request::retrieve('id', 'Positive', $this, FALSE);
The result, is that the PDF activity created has the activityId matching the profile id of the default search profile.
The result is one of two things:
- Either a fatal error due to a constraint violation (if there is not activity with the given id), or
- An activity is created with a mis-matched activity id (which is far worse because it creates inconsistent data). For an example see: http://drupal.demo.civicrm.org/civicrm/activity?atype=22&action=view&reset=1&id=1&cid=20&context=activity.
The activity should be a PDF Letter, but it has the subject line: "Subject for Membership Signup". that's because it was attached to the activity with ID 1 (which is the profile ID of Name and Address, which is the profile I set as the default search profile).
I'm fairly lost in the process - not sure exactly which code is wrong??
Attachments
Activity
Yup. That does the trick (that was the patch I tried when testing, I just wasn't sure if it was need in some other context). thanks for the quick response.
hold that... just got a new error... working on this now...
The fatal error I encountered seems to be related to the complex template.
I just submitted a new patch to get rid of a PHP notice. I think this is ready to go.
Note that although this fixes the problem I can't think of a valid scenario where the pdfletter::createactivities would need to have id passed to it. It seems to me that you send a letter & create an activity & that is not something that required editability
jamie:
can u please QA the patch and ensure that it does work