The mailing list for listmasters using Sympa

["Jim Rowan" <address@concealed>]

> gecos_user is just used to initialize comment_subscriber, they can 
> diverge afterward.

Ok.  Can you tell me something about the design decisions behind that?
In my way of thinking, gecos describes a user, and should not even be in
the subscriber table -- it subverts the whole reason for the user table.
From what I can tell from the code, you always require an entry in the
user table for every subscriber.  If that is true, there shouldn't be
any problem in either keeping the two gecos fields consistant or in
having just one field (in the user table).  Is this accurate, or do I
misunderstand something?

> >- (Related:) I want to have an addition field in the database, 
> >"company".  It seems obvious to me that this should go in the user 
> >table, but from what I can tell wwsympa only uses additional fields 
> >from the subscriber table.  Do I have to mirror all my additional 
> >fields into the subscriber table?
> >
> You can declare additional fields for both user and 
> subscriber table and 
> these fields will be available within both templates and 
> authorization 
> scenarios. But only subscriber additional fields are editable 
> (from the 
> editsubscriber page) just because there is currently no feature to 
> browse entries of user_table in WWSympa. 

So this IS supposed to work?  As I said in my other post, it's not
working for me.  I got to the point where I can see my additional
fields, but the change wasn't stored in the database.


> But I guess we could allow 
> editing of these fields from the editsubscriber page just as 
> we do with 
> the preffered language... But we feared that some of the "global" 
> information (stored in user table) should be private and 
> therefore not 
> shown to all list owners. This required a way for the listmaster to 
> define who could see/edit each additional field and that was just too 
> much setup for such a feature...
> 
> What are your needs ?

Our environment (as it stands today) has a single layer of "authority",
so the issue you are describing does not apply here.  The list owners
can be trusted to safely manage any of the info in the user table, and
none is "private" to the point that it should not be shown to them.  I'm
looking for a way for the list managers to edit all the data associated
with a subscriber (currently including name, email, company) through a
gui.