Developers of Sympa

[Olivier Salaun - CRU <address@concealed>]

Hi Charles,

Charles Clarke wrote:
> Hello!  First, thank you for developing such a powerful and flexible mailing 
> list manager!

Today is a good day ;-)

> Since I'm new to Sympa, please let me know if I miss something...
>
> 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 ?

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).

> 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)
        
        2/ How would he/she define variables ? Probably using template syntax 
([subscriber->var]).
        what subset of variables would be available ?

        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)


> 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 ?

> 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.

--
Olivier Salaun
Comite Reseau des Universites