The mailing list for listmasters using Sympa

["Scott Balmos" <address@concealed>]

I don't see a need to change the primary key, or any of the database
schema. Here's the pseudo-code for my line of thought:

1) User logs in via WWSympa, and is authenticated by one of the backends
defined in auth.conf. User's cookie is set up with a list of valid email
addresses from that backend (no need for the concept of primary/canonic
vs. alternate in my head, supposedly...)

2) All WWSympa actions are modified to look at a *list* of possible email
addresses, rather than the single email address. This mostly concerns
displaying the web page that shows what mailing lists the user is
subscribed to, regardless of which one of the email addresses they are
subscribed with. (e.g. my user account in LDAP has address@concealed &
address@concealed ... If I'm subscribed to List A with address@concealed and List B
with address@concealed, the list subscriptions page would show both lists).

3) The subscription action for a list would have to be modified to ask
which email address to subscribe with, if the user's cookie has more than
one email address.

4) The user preferences page would have to be modified in order for the
user to select which email address to change preferences for. The one that
I can think of is maybe the user's real name, as some people have
different titles or such they put in their names (like you have the "-
CRU" part). Language and connection expiration shouldn't really change, I
don't think.

*** A possible addition to the above is to define a realname_attribute
parameter for auth.conf, which pulls in a default real name to put in that
user's user_table entry. The common sense default for this, in an LDAP
scenario, is the "cn" attribute, which usually contains the person's full
real name. Likewise could be done for an SQL authentication paragraph,
which pulls the person's name from a user record field.

Otherwise, everything else in Sympa/WWSympa stays the same. user_table
entries are added at authentication time, as part of a one-time "sync"
with the email attributes in the authentication backend. subscriber_table
doesn't change in any way, nor does user_table. To the database, the
separate addresses look like separate people. No need for a canonic
address, because of this fact. Only the authentication system, and a few
parts of WWSympa, need to know what group of email addresses belong to the
same person.

An odd situation might happen when the user updates their list of email
addresses in the authentication backend, like if they add/modify/delete.
For the add case, the at-login-time processing that checks the
authentication backend's returned list of addresses vs. user_table can
just see that there are new addresses, and add new user_table records
appropriately. Modify, I don't think Sympa can handle. But that's a simple
change-of-email modification that can be done using existing means.
Delete... I'm not sure about. :) Force an unsubscription, or a change of
subscription to one of the remaining addressses? Not sure. I'm not really
concerned about the above, because my custom application will almost
completely be changing user_table and subscriber_table manually.

I can *possibly* look at the 4.1.2 release code copy I have on a test
machine, and see if I can hack up a few of the above changes over the
weekend. But I think the above decently describes what I was thinking
should/would go on internally when dealing with multiple user email
addresses.

--Scott

> If we started Sympa develoments right now, we would probably make the
> primary keys something different than the user email address.
> But we've got quite a few lines of code and i doubt we ever change this
> primary key. The best we could do, in the future, is check alternate
> email addresses everywhere it is required.
>