Developers of Sympa

[Charles Clarke <address@concealed>]

On Fri, 13 Dec 2002, Olivier Salaun - CRU wrote:

> > While playing with Sympa, I wanted to allow the subscribers to be able to
> > edit some of their additional_user_db fields(by the listmaster changing
> > the prefs...tpl file to include their input) and was disappointed that
> > Sympa couldn't do that(and actually looked like it was written to prevent
> > it).  I've included the changes(context diff) I made to List.pm and
> > wwsympa.fcgi to allow this.
> 
> We developped this feature more for administration needs (payment, ...) than
> for extended subscribers field ; and basically we have maid them editable
> to list owners because it was easy to add this feature.
> 
> To include your patch we need to provide some kind of access restriction to
> allow read/write restriction to additional fields defined in sympa.conf.
> Here is a way to define it :
> 
> db_additional_subscriber_fields       
> billing:listmaster,dummy:owner,address:private
> 
> meaning that :
>       'billing' field can be seen/edited by listmaster only
>       'dummy' field can be seen/edited by listowners (and listmaster)
>       'address' field can be seen/edited by the subscriber (and listowner 
> and listmaster)
> 
> Another possible value after ':' would be 'public' to add the field to the 
> REVIEW page
> (for other subscribers).
> 
> Would this suite you ?
I was looking more at the user_table than the subscriber_table, but having
this ability with either works for me.

I figured the ability to view/edit was controlled by the templates which
should be controlled by the list owner or listmaster, but if you want more
control(or security in case of cracking), your method looks good.  Though
you may want to be able to specify view and edit permissions seperately.
(Through scenarios?)



> BTW, we have another feature in our development plans that would probably 
> best fit
> that kind of needs :
>       Custom list data could be defined by list owners for each list. The
>       owner would define the field names,types (including enum) and 
> visibility
>       (editable by subscriber or restricted to owner). These custom fields  
>   
>       could be required when requesting a subscription, then the owner could
>       moderate subscriptions. The data would be stored in a single dedicated
>       DB field as a comma-separted list (var1=xxx;var2=zzz).
Looks like semi-colon seperated to me.

I would also prefer them to be seperate fields, easier to search/edit.

> > I'm also interested in the customized user emails.  I'm willing to help on
> > the development, if needed.  
> 
> We need to define the behavior of this feature with you first. Here are 
> technical choices
> that need to be eluded :
>       1/ How does the sender tells Sympa that his/her message should be 
> parsed.
>       It could be based on the list's config (all messages would/wouldn't 
> be parsed),
>       or based on the address the message would be sent to (<list>-parse) 
> or the
>       owner could set a MIME header field (X-Parse: yes)
I prefer <list>-parse, since that would be easier for most people to use.

>       2/ How would he/she define variables ? Probably using template syntax 
> ([subscriber->var]).
>       what subset of variables would be available ?
Same access as defined above.  Those defined in the conf file as
additional fields.

>       3/ There are some cases where the message should not be parsed : 
> S/MIME signed or
>       crypted messages, only text/plain and text/html should be parsed (not 
> Word, GIF, PDF)
True.  Though if there is a <list>-parse address that you send your
message to and you send a message that shouldn't be parsed to it, I'm not
sure we should protect the user that much.  At least protecting them would
be a lower priority for me.

> > I'm also looking forward to more virtual robot support(e.g. allowing 
> > access to 
>  > different databases for different robots).
> 
> Can you explain why you need to use separate DB. Performances ?
Multiple domains that may want to have different additional user or
subscriber fields.  Though it may be one way to simplify having several
lists with the same name among multiple domains(virtual robots).


> > Also, I saw a message by Adam Bernstein about his cleaning up the English
> > and reducing menu clicks.  I'm interested in these so I don't duplicate
> > his work.
> 
> We are currently working on a new web interface for Sympa.
> It's a good time to send (or resend) us any graphical, technical, ergonomics
> suggestions.
I'll let him know.

> 
> -- 
> Olivier Salaun
> Comite Reseau des Universites

Thanks!

charles