The DNN situation I'm customizing is one that is child portal intensive.  I've extended the code for creating portals such that they can be easily rolled out.

The issue now is, more than an admin is created when the child portal is made.  A minimum of 3 users are created: Admin, Chair Person and one Registered User.  They all need an email sent.

Though I suspected this would cough up blood I did it anyhow:  Tried abstracting out the email creation code from the portal creation code I extended.  then when each user was created I sent an email.  Since I needed to abstract this code for this purpose anyhow it seemed logical to try the shotgun approach.

When it bombed I wasn't shocked.  OK, so I need to find a way to queue these emails.  My guess is leverage a newsletter send for any new users ... just kicking around ideas and thinking outside the box.

Without exposing too much of the client idea I'm helping to realize -- a regular user will create portals for clients.  When these are created, the rep themselves become a registered user, their boss the child portal admin and they can set up some other users for the site.  This is all automated.

 So for each child portal, some means of sending multiple emails straight off is what is desired.  This sort of sounds like I need an automated logon followed by a newsletter send but maybe that's over-thinking it.

Any ideas out there?

Thanks!

Wes,

Thanks for the response.  What was so complicated was how the same method, the code of it anyhow, is hard coded into the portal creation code.  I tried extracting it out of the Create Portal method and something just didn't fly. 

I'll look at the method that exists in the code and make sure it's the same signature as the one below.  I didn't write nor change what I tried to abstract out into its own method, it already existed.

As soon as I put the same code back where I found it and only tried to use it for the new admin for the new portal, it worked.  Part of the issue is the create portal method at this point is quite busy and sort of breaks the rule of any method, class, etc. should only have one reason to change. :)  This one in this area alone is so intertwined with other code that it has at least half a dozen reasons to change.

 Let me take the SendMail() signature you provided and try using it if the overload in use isn't the same one.  Perhaps that's the solution right there.

 Thanks,

Mike

Yep ... this was it and I did find it.

As mentioned, the code is very busy and a little subtle detail defined higher up in the code wasn't modified as expected by my abstracted method.

Now that this is found, getting it to work with multiple users when a new portal is created isn't going to be easy.  But the reason why it wasn't working at all has been located.

Thanks! Your insight was correct and proved valuable.