anyone know if there is a way to allow only unique usernames and email addresses?

I suppose I could make a database schema change during installation on these fields in the user tables but I'd be afraid to break something.

Looking for and easier way...

Regards,
Frank

Usernames *are* unique already. I've allowed duplicate email addresses because I thought they *shouldn't* be unique. All password retrieval and whatnot is handled by the unique usernames, anyway. And believe it or not, I've had problems on forums in the past where I've made unique email addresses manditory and then had couples complain because they share an email address and don't want a new one.

I think it's neat the way it is.

Actually, this just sparked an idea in my mind for a possible feature request to the Applications Settings. "Allow Email Sharing" just in case an admin wants to weed out potential duplicating or account cloning. While writing the IP histories and Tips & Tricks for admins documentation it came to me. Otherwise there's really no way to head this kind of abuse off from repeating itself if it actually happens.

Thoughts?

By the way...IS there a utility that does mass emailings for Vanilla? Or at least allows me to pull all the emails from the user tables short of writing an sql script to do so?

At the moment, no, there is nothing available. However I'm fairly certain it could be easily done as an extension. However there won't be any "opt-out" function unless you can somehow figure a way to do that on the fly. If nobody else makes this, I suppose I could take a stab at it.

I am an evil genius looking for more evil plans to add to my agenda, what more can I say...

just as a pointer it would need to add their email address as usernames can be changed in certain instances.

@nathan:
The smartest way to pull this off without requiring any extra tables, rows or anything, could be by just hooking an entry into the LUM_Users table under either the Attributes, Discovery, or Settings row. This would eliminate any need for extra tables, rows or files.

@mini:
indeed, with the above just said, thas would write that little problem out of the equation. The only thing to do then would be figuring out a way to traverse the LUM_users table in such a way to compile a valid list each time you wish to send an email without hitting the server too hard when building a list of users to email.

@mark:
Adding up all of the above, this should be totally possible without any crazy DB rewrites.

To avoid that little DB rewrite, the user is opted out by default (no entry set), opting in the first time writes the initial entry so the extension could find users to include.

Lum_Users 'Settings'


a:9:{
s:13:"ShowBookmarks";i:0;
s:21:"JumpToLastReadComment";i:0;
s:22:"ShowDeletedDiscussions";i:1;
s:19:"ShowDeletedComments";i:1;
s:12:"UseQuickKeys";i:1;
s:9:"HidePanel";i:0;
s:21:"ShowRecentDiscussions";i:0;
s:19:"ShowBrowsingHistory";i:1;
s:22:"ShowPrivateDiscussions";i:0;
<strong>s:666:"EvilMailerInclude";i:1;</strong>
}


if setting 666 is EvilMailerInclude and set to 1, include that user. else if not found or setting 666 is EvilMailerInclude and set to 0, do not include. Possibly as simple as that, no big or small opt-in/out listings, all the data is already there, you just need to know how to use it :D

Yeah, just trying to cut out all the totally unecessary hoops for you guys to jump through and thinking ahead so you don't have to. I should really write up an extensions and quit giving people flak :)

David, that's even more evil than the original idea... I love it.

You are stalking him?

@dom: You are stalking him?

No. well I don't mean to.

SORRY LECH!

oh god, it's spreading to other threads!!

haha, noice!