Developers of Sympa

[Olivier Salaün <address@concealed>]

Hi Adam,

First of all, thank you for starting this discussion ; while working on 
picture upload features recently, we've realized that a few things 
should be changed/extended.

Let's start with a bit of history : in the first days, the user name was 
stored in gecos_user field of the user_table only. The drawback of this 
architecture : we had to perform an SQL JOIN whenever we needed to get 
informations about a user. It could be very time consuming while 
performing a REVIEW command on a big list. We've optimized things, 
introducing an equivalent DB field in the subscriber_table : 
comment_subscriber.The relationship between those two fields : 
gecos_user is the default for comment_subscriber ; but then they live 
the own life, not connected. The drawback of this situation is that 
whenever a user updates his name in the web preferences page, it's not 
applied to each list he's already member of. It just becomes the new 
default value for future subscriptions. On the other hand we have some 
list owners that use the comment_subscriber DB field to store 
informations about their list members in a standardized way that is 
related to the list context, but maybe we should define another DB field 
used by list owners only to qualify list members.

We've recently introduced the "picture upload" feature that allows a 
list member to upload his picture ; it will then be printed in the list 
review page and in the list web archive if the user is the author of the 
message (recently coded, you can have a try on demo.sympa.org). The 
limitation of this feature is that user has to upload his picture for 
each list he's member of. On the other hand, he might not wish to 
publish his picture for all mailing lists (because he feels more 
confident in some and less on others) or he might wish to publish a 
different picture (holidays pictures versus picture with a tie).

We've also realized we have another related issue to fix : when a list 
includes members from another lists, should sympa apply the member 
preferences (name, reception mode, visibility mode) from the origin list ?

We have written a quick feature request that summarize the considered 
solutions : 
http://sourcesup.cru.fr/tracker/index.php?func=detail&aid=3575&group_id=23&atid=170

You're welcome to either contribute to the discussion in the list or 
complete that feature request.

PS : sympa-users is probably not the best place to go on this 
discussion, because not everybody is interested in Sympa design. 
Therefore I suggest to go on in the sympa-dev mailing list ; anybody can 
subscribe to this list.

Adam Bernstein a écrit :
> I might have asked about this a long time ago, I'm sorry I'm not sure, 
> but can't find anything in the archives:  It has always been a 
> headache that there are these two different tables that store 
> different pieces of subscriber data, including some redundancy (eg. 
> the full name, or "gecos"), and that only the subscriber table data is 
> editable from the subscribers page.  People should only have to (and 
> only be able to) edit their name in one place and have the change show 
> up everywhere, and I'd also like to take advantage of the extended 
> database fields for data (like mailing address) that currently maps to 
> the user table, not the subscriber table -- but I want it to be 
> displayed and editable on the subscribers page.  That page currently 
> displays extra fields, but only from the subscriber table, not the 
> user table.
>
> It just seems a fundamental requirement that each person should have 
> one single profile that describes them, and it should be the same 
> everywhere. I think there was some historical reason why Sympa wasn't 
> built this way, but with all the improvements lately (eg. the picture 
> upload, awesome!), it seems ever more important to rework it 
> appropriately.  The current scheme is, if you'll pardon me, a bit insane.
>
> Any chance of such a change in the near future?  I could see it being 
> a massive job, but I wonder if there's some way of linking or syncing 
> the tables to produce the same effect without rewriting a whole lot of 
> code.