So if you have this case where a bunch of users have "info@company" as their e-mail rather than individual e-mail ... is there any particular reason why you can't simply set their e-mail to "null"? They can still log in with their username in this instance, right?
After all, if "mailto:oct@openacs.org"; were to be my e-mail address in an OpenACS instance, I would be unhappy if I were to get 10 copies of every alert sent out for a forum post.
Wouldn't you?
ISTM that while getting rid of the unique constraint might be the SIMPLEST solution to your problem, it can hardly be considered the BEST solution. Your solution might make the person who has to read "info@company" unhappy if there are 100s of employees making use of it as their "token" e-mail.
The datamodel doesn't presume that every person will have a unique e-mail address. It assumes that shared e-mails form a group, a party, that (say) "info@company" belongs to the company itself, not any individual.
Perhaps this isn't practical but it does allow modelling of real world scenarios. The datamodel allows for group as well as individual e-mails, in other words. The toolkit doesn't support it well out of the box, and perhaps the datamodel might be more awkward than you'd prefer, but you are WRONG to flatly claim that the datamodel doesn't support this real-world scenario.
As far as process goes, Malte, my issue here is that there's a tendency to commit changes that avoid roadblocks that follow the path of least resistance - the simplest change to solve your personal problem - rather than raise flags and ask for discussion.
If you had approached this by first posting "hey, I've got a problem, any ideas on how to best solve it?" my reaction would be a bit different.
Likewise the addition of the additional table after code freeze. I am in no way convinced that you and/or Timo have solved the problem in the best way, but given that this core datamodel change was made at (past) the last minute without any prior discussion was not even been given the chance to think about the problem.
If it were just me it would be no problem, but given Daveb's reaction (a man whose life seems to be spelled "IRC") it seems pretty clear that changes of this sort are being made without discussion with anyone.
That's not good. The plea for public discussion before such changes are made rather than afterwards when folks read your commit message isn't meant to make it painful for you to make changes. Rather it is meant to make life less painful for us as a community by discussing fundamental issues first, while making changes later.
