jspenc3 wrote
Nope, on my Windows 2003 server if I don't make an Exchange account the actual email field is blank. Now "behind the scenes" there is an account name/login that looks like an email address (username@domain) but that isn't actually stored as an email in AD. I understand the reasoning behind requireing an email for DNN and the AD provider "making one up" to meet this requirement, but that isn't a very good way to handle the situation in my book. I mean, why would I want the provider just "guessing" or making up an invalid email to fill a required field. If it's an invalid email it won't work anyway so why waste time "making it up"?
I know most companies probably won't use AD/DNN with users without a company email, but sounds to me like the process behind this integration is broken. Here's how I suggest the AD provider work for this situation:
- Any user without both a DNN and AD email field would be required to enter one into DNN on login (stored only in the DNN database).
At this point I don't think it can be done. The email field is not different for DNN vs AD. It's the same field. On auto login it blows past any of the checks and automatically logs the user in. I've looked at trying to redirect the user if there are fields that are required but from what I remember (it was about a year ago) there was no way to trip the required triggers that manually logging in does. I guess I need to rephrase what I posted above. A user can login and use DNN without an email and it's work fine for the user. Where things blow up is on the administation side (for example when you try to view user accounts).
On every future login, if the AD email field is blank the AD provider will leave the manually entered DNN email alone. There's no way to tell if an email address has been manually filled or not but I could check if the field has anything in it and if so, not overwrite it. Please post this in the DNN Public section of
Gemini so that it's on my list of things to do.
On every future login, if the AD email field has been filled in it should prompt the user which email address to keep (and sync or ignore the sync accordingly).That would be a major pain in the you-know-what. If I could capture it on automatic login and I had a different email address than my company email on our portal (as an example) I would be getting asked which email account I wanted dozens of times during the day.
In my situation we actually want our employees required to enter a home email in addition to the "company"/primary one. If that were a normal requirement I'd probably add an additional bullet point to extend the AD provider to juggle between the home & corporate email for the DNN primary email field depending on if an AD email is there...
For now I guess I'll stick with my plan to write a stored procedure (or something) for now as I don't have time (or knowledge) to modify the provider at this point...
I'm not arguing against your use case and I'm willing to do what I can but it has to be something that's going to work for the majority of users. If it doesn't then that's where the joy of open-source comes in (the ability to tweak the code to work specifically for you).