Queues, Email Notifications, Standard Controller Extensions. Oh My!

Question

Created a controller extension for the standard case controler. we set the OwnerId using custom save logic, but it doesn't seem to matter what i do, Queue Notifications are never sent out to members.

//A place to store all our custom case logic that should be executed before
//a save into the DB
@TestVisible private void saveLogic(){
    Database.DMLOptions dlo = new Database.DMLOptions();        
    dlo.EmailHeader.triggerAutoResponseEmail = true; 
    dlo.EmailHeader.triggerOtherEmail = true; 
    dlo.EmailHeader.triggerUserEmail = true; 
    Case c = (Case)caseController.getRecord();
    //set the case owner to whatver the assignee is set to
    c.OwnerId = this.AssigneeId;
    c.setOptions(dlo);
    caseController.save();
}

I am aware of the odd Queue settings in regard to the "Send email to members" checkbox and the four states it can represent with the Queue Email text field (queue case email notifications to all users). I'm just not sure what it is exactly that i'm missing here in regards to why it won't fire an email when i set the ownerId to a Queue.

Setup > Cases > Page Layout > Layout Properties > Email Notification Checkbox , no combination of checked for show on edit page or select by default seems to matter. Are there any other Queue settings I could be missing?

Edit Forgot to mention this is a production org with other email notifications we setup working properly.

Answer 1

Congratulations. You found one of the ways that StandardController (and StandardSetController) is broken (at least, for now). I've been trying to get a straight answer about why it's as broken as it is, but that's been very vexing.

Quite a few years ago, I stumbled across a particular oddity: StandardController and StandardSetController do not act like DML operations. That's right. They're fundamentally broken. As a proof of concept, I wrote this code:

for(Integer i = 0; i < 500; i++) {
    new ApexPages.StandardController(new Account(Name='Account '+i)).save();
}
System.assert(Limits.getDmlStatements() == 0);
System.assert(Limits.getDmlRows() == 0);

As you know, we're limited to just 150 DML statements (and the value was even lower than that back then). However, this code worked "correctly": it actually created five hundred named accounts, one at a time.

I was going to write a blog post on this recently, and I revisited the code, and I found something even odder: the assertion was now failing. So, it was counting as a DML statement (apparently), but it wouldn't trigger a LimitException.

for(Integer i = 0; i < 500; i++) {
    new ApexPages.StandardController(new Account(Name='Account '+i)).save();
}
System.assert(Limits.getDmlStatements() == 500);
System.assert(Limits.getDmlRows() == 150);

You'll notice two oddities here: (a) I'm allowed to have 500 of 150 DML statements, and (b) the number of DML rows is reported to be 150, because only 150 rows should have been created.

Oddly, I can now find Account 499 (the last numbered account), even though only 150 rows appeared to save. As a bonus, the remaining 350 rows show up in the debug logs as causing System.LimitExceptions for too many DML statements.

In summary, StandardController is (still) broken, and you shouldn't trust it to do anything more than the most simple tasks (like, saving user input without modification). If you want to actually use DMLOptions, use a Database method (e.g. Database.insert/Database.update).