I have an Apex trigger that writes "Lead Status History" to a custom object I've made called "Lead_Status_History__c". It fires whenever the lead status changes on a lead. The problem I am having is that the trigger is firing twice on a specific Lead Status.
I believe the reason why it is firing twice on this specific lead status is because I have a workflow rule set up on the lead. When the lead status is changed to that specific status, it performs a field update on a date field on the lead, and I believe that this field update is causing my trigger to fire again.
To rehash the order of execution when it comes to triggers, I'll highlight the steps that are relevant to me:
1. The original record loads from the database or initializes for an insert operation 2. The new values load from the incoming request and overwrite the old values in the record buffer. The old values are saved in the old context variable for update triggers. 3. Before triggers run. ... 5. The record is saved to the database, but the record is not committed. 6. After triggers run. ... 8. Workflow rules execute. If field updates are specified, the record updates again, and before and after triggers for the update fire. ... 10. All data manipulation operations are committed to the database.
I believe step 8 is causing my trigger to fire again. Is there anyway to prevent triggers from doing a repeat action if step 8 causes your trigger to fire again?
Here is my apex trigger code:
Code:
trigger LeadStatusHistoryTrigger on Lead (before update)
{
// Declare a list of Lead_Status_History__c to be insertedin Salesforce
List<Lead_Status_History__c> LeadStatusHistoryObjects = new List<Lead_Status_History__c>();
// If the trigger is an update trigger insert all the new status changes
if ( Trigger.isUpdate )
{
for ( Lead l_new: Trigger.new )
{
// Check to see if the status of the old and new lead values are the same.
// If they are different then we create a new entry in the lead_status_history custom object
if ( l_new.Status != Trigger.oldMap.get( l_new.Id ).Status )
{
LeadStatusHistoryObjects.add( new Lead_Status_History__c ( Lead__c = l_new.Id, Lead_Status_New__c = l_new.Status, Lead_Status_Old__c = Trigger.oldMap.get( l_new.Id ).Status ) );
}
}
// After all the new Lead Status History items have been added, now insert them into Salesforce
try
{
insert LeadStatusHistoryObjects;
}
catch (DmlException de)
{
for ( integer i = 0; i < de.getNumDml(); i++ )
{
System.debug('LeadStatusHistoryTrigger Error Inserting Lead Status History Objects: ' + de.getDmlMessage(i));
}
}
}
}
I've just installed the Eclipse IDE with the Force.com plugin on a Mac and it's not behaving the way it did in Windows. On my Windows machine I had two Force.com projects, one for my development sandbox and one for my production org. I had selected all of the same metadata components in both projects and would use WinDiff to review all of the differences between the two organizations. Now, on my Mac, a large number of the metadata objects aren't available to add to my production project.
Does anyone have any ideas why this might be?
Thanks,
Allen
The components that I can select in the dev sandbox project that I can't select in the production project are:
I recently deployed a force.com platform app with a custom object that has a Birth_Date__c field on it. Our users are accessing the app mainly through the SalesForce Mobile client on the iPhone. A user called and said the date on one of these items kept changing to 12/13/1932 every time they saved. I had the user access the app through the web and the birthdate they picked saved OK. However, after a few minutes when their iPhone synced again the date changed to 12/13/1932. I queried the data and found that 22 of about 100 records have the birth date of 12/13/1932.
I've just installed the Eclipse IDE with the Force.com plugin on a Mac and it's not behaving the way it did in Windows. On my Windows machine I had two Force.com projects, one for my development sandbox and one for my production org. I had selected all of the same metadata components in both projects and would use WinDiff to review all of the differences between the two organizations. Now, on my Mac, a large number of the metadata objects aren't available to add to my production project.
Does anyone have any ideas why this might be?
Thanks,
Allen
The components that I can select in the dev sandbox project that I can't select in the production project are:
I recently deployed a force.com platform app with a custom object that has a Birth_Date__c field on it. Our users are accessing the app mainly through the SalesForce Mobile client on the iPhone. A user called and said the date on one of these items kept changing to 12/13/1932 every time they saved. I had the user access the app through the web and the birthdate they picked saved OK. However, after a few minutes when their iPhone synced again the date changed to 12/13/1932. I queried the data and found that 22 of about 100 records have the birth date of 12/13/1932.
I have an Apex trigger that writes "Lead Status History" to a custom object I've made called "Lead_Status_History__c". It fires whenever the lead status changes on a lead. The problem I am having is that the trigger is firing twice on a specific Lead Status.
I believe the reason why it is firing twice on this specific lead status is because I have a workflow rule set up on the lead. When the lead status is changed to that specific status, it performs a field update on a date field on the lead, and I believe that this field update is causing my trigger to fire again.
To rehash the order of execution when it comes to triggers, I'll highlight the steps that are relevant to me:
1. The original record loads from the database or initializes for an insert operation 2. The new values load from the incoming request and overwrite the old values in the record buffer. The old values are saved in the old context variable for update triggers. 3. Before triggers run. ... 5. The record is saved to the database, but the record is not committed. 6. After triggers run. ... 8. Workflow rules execute. If field updates are specified, the record updates again, and before and after triggers for the update fire. ... 10. All data manipulation operations are committed to the database.
I believe step 8 is causing my trigger to fire again. Is there anyway to prevent triggers from doing a repeat action if step 8 causes your trigger to fire again?
Here is my apex trigger code:
Code:
trigger LeadStatusHistoryTrigger on Lead (before update)
{
// Declare a list of Lead_Status_History__c to be insertedin Salesforce
List<Lead_Status_History__c> LeadStatusHistoryObjects = new List<Lead_Status_History__c>();
// If the trigger is an update trigger insert all the new status changes
if ( Trigger.isUpdate )
{
for ( Lead l_new: Trigger.new )
{
// Check to see if the status of the old and new lead values are the same.
// If they are different then we create a new entry in the lead_status_history custom object
if ( l_new.Status != Trigger.oldMap.get( l_new.Id ).Status )
{
LeadStatusHistoryObjects.add( new Lead_Status_History__c ( Lead__c = l_new.Id, Lead_Status_New__c = l_new.Status, Lead_Status_Old__c = Trigger.oldMap.get( l_new.Id ).Status ) );
}
}
// After all the new Lead Status History items have been added, now insert them into Salesforce
try
{
insert LeadStatusHistoryObjects;
}
catch (DmlException de)
{
for ( integer i = 0; i < de.getNumDml(); i++ )
{
System.debug('LeadStatusHistoryTrigger Error Inserting Lead Status History Objects: ' + de.getDmlMessage(i));
}
}
}
}
How can I get code coverage in the follow DMLException?
Code:
try {
insert oppList;
}
catch (DmlException e) {
for (Integer i = 0, leni = e.getNumDml(); i < leni; ++i) {
Opportunity o = oppList.get(e.getDmlIndex(i));
o.addError(e.getDmlMessage(i));
}
}
Do I have to explicitly create a object that will fail in the insert even though it has nothing to do with the logic I really want to test.
In another example; from the Cookbook, there is:
Code:
if ((updatedContacts.size() + Limits.getDMLRows()) > Limits.getLimitDMLRows()) {
...
...
}
Does that mean I have to create up to 100 (more or less depending on the governor limit of the environment) test objects to get past the "if' statement and test the code in the block?
It seems that best practices does not allow code coverage for those areas; unless it is expected these areas will be a small amount of code in a class and it is ok not to test them?
AccountTeamMembers is a standard child object so I can't define a trigger for it but is there some other way I can catch changes to it in my Apex code? If someone tries to add a new accountteammember and I want to do validations on their role how can I do that?
