The mailing list for listmasters using Sympa

["Roger B.A. Klorese" <address@concealed>]

On 7/15/10 8:09 AM, David Verdin wrote:

address@concealed"> Hi roger,

Le 12/07/2010 19:34, Roger B.A. Klorese a écrit :

Sorry for my impatience, but determining how we are going to resolve the
requirement for per-subscriber moderation -- whether it can be implemented
with existing features or if we need to do new development -- is the only
true blocker to our moving 40+ domains off Majordomo 2 to Sympa.
  

I'd hate to delay your walk towards a better world. ;)
Sorry I didn't answer sooner.
Evrything you did is OK except... see below.

Unfortunately, the documentation for use of
db_additional_subscriber_fields doesn't fully help.

The current situation is:

1) moderated_subscriber is defined as enum('true','false') in the
subscriber_table.
2) moderated_subscriber is listed in /etc/sympa.conf in
db_additional_subscriber_fields

As a result:

1) moderated_subscriber is shown as an additional column in the subscriber
review summary
2) moderated_subscriber is shown as a text entry field (not selectable
enum) in the per-subscriber details

However:

1) As it's a text field, it's not clear to me what to enter in order to
match a test
2) With the rules below -- modified from an existing scenario -- the test
is not triggered:

title.gettext restricted to subscribers

is_editor([listname],[sender])                 smtp,smime,md5    -> do_it
is_owner([listname],[sender])                  smtp,smime,md5    -> do_it
match([subscriber->moderated_subscriber],/'true'/)    smtp,smime,md5    
-> editorkey
  

The match rule should not contain quotes. Now, it is looking for a string whose value is 'true', not true.
You could use equal(), too, which takes quotes:

equal([subscriber->moderated_subscriber],'true')    smtp,smime,md5    -> editorkey

It should then work.

Thanks for this catch -- it works perfectly now.

address@concealed">

is_subscriber([listname],[sender])             smtp,smime,md5    -> do_it
true()                           smtp,md5,smime  ->
reject(reason='send_subscriber')

Do I have the test wrong?  Is it an issue of the entered data?  Is it
possible to do a test like this one at all?

3) For extra credit, if the simple case works, can it be made more 
explicit by testing is_subscriber AND the match in a single condition?
  

No. We don't have an "AND" implemented in scenarios.

There is solution that ensures you moderate people who are subscribed to this list AND have the "moderated_subscriber" field set to "true". Here is the way to go:

Suppose you want to tell that all your lists can have a subset of subscribers that are moderated. You can do it using the Custom parameters: https://www.sympa.org/manual_6.1/customizing#custom_parameters

1- Change the general "send" scenario so that it includes the following line (preferably before any line whose result is "do_it"):

is_subscriber([custom_vars->moderated_subscribers], [sender])            smtp,smime,md5    ->    editorkey

2- for each list in which you want to use this mechanism:
    2.1. add a custom parameters called "moderated_subscribers"
    2.2. create a (hidden) list in which moderated subscribers will be stored. If the list you want to moderate is called "list-a", you can call it "list-a-mod" for example.
    2.3. give the value "list-a-mod" to the custom parameter "moderated_subscribers" in list-a config.

3- Each time you want to moderate a subscriber, just subscribe her to the "list-a-mod" list. Any of her messages will be subscribed.

The '3-' above is the manual part.
You can save your users the pain to manually add subscribers to the "list-a-mod" list by using your development: Just create a sql datasource to "list-a-mod" configuration. This sql datasource will be based on a query which will retrieve all the users of list-a for which the "moderated_subscriber" will have the value "true". this is a plain SQL query.
For more details on SQL datasources: https://www.sympa.org/manual/parameters-data-sources#include_sql_query


Because we're not a unified organization, we won't have a central list of moderated users.  And the moderation state for individual subscribers is likely to be transient -- based on an "if you break the rules you're moderated for 30 days" type of thing.  So having list-owners set a single attribute is probably the way to go. 

(Given the simplicity with which this is done the other way -- an attribute of each subscription, settable and reviewable by list-owner -- would you consider it as a standard feature if there were sufficient demand?)