Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

[Olivier Salaün <address@concealed>]

Les solutions que je vous propose sont industrialisables en définissant des scenari par défaut et/ou en utilisant des custom_vars <http://www.sympa.org/manual/parameters-others#custom_vars>. J'oubliais la possibilité de définir des propriétaires de liste ou des modérateurs par interrogation d'une source externe, voir <http://www.sympa.org/manual/parameters-definition#owner_include>

Le 28/10/10 09:03, Jean-michel Bourdin a écrit :

address@concealed">Merci pour la rapidité de votre réponse je vais tester ces solutions.

D'après vos solutions il faut être le super-admin de sympa pour mettre en place tout cela :
  - comment procède un utilisateur qui est propriétaire de la liste mais qui n'est pas listmaster ?


Ma proposition permettrait je pense de délèguer aux propriétaires de listes la mise ne place des autoristions d'émissions pour quelques personnes.

Le 28/10/2010 08:48, Olivier Salaün a écrit :

address@concealed"> Vous avez plusieurs possibilité pour généraliser ce mode de fonctionnement :

1. regrouper les personnes de la direction au sein d'une autre liste, puis tester l'appartenance à cette liste (is_subscriber('autre_liste', [sender])) dans votre scenario
2. interroger un annuaire LDAP ou une base SQL dans une condition de scenario, voir la fonction de filtres nommés <http://www.sympa.org/manual/authorization-scenarios#named_filters>
3. écrire une custom condition de scenario, ainsi vous pourrez implémenter la logique de votre choix, voir <http://www.sympa.org/manual/authorization-scenarios#custom_perl_package_conditions>

Cordialement.

Le 27/10/10 16:05, Jean-michel Bourdin a écrit : Bonjour,

J'ai une liste modèré de prof (privateandeditorkey), avec comme modérateur une personne de la direction.
On me demande à ce qu'une personne d'un autre service puisse émettre des messages sans passer par la modération.

Pour l'instant j'ai bidouillé le scenario en y inscrivant l'utilisateur concerné avec authentification MD5 :

title.gettext Moderated, restricted to subscribers

equal([sender], 'address@concealed') smtp,smime -> request_auth
is_editor([listname],[sender])     smtp,smime,md5  -> do_it
is_subscriber([listname],[sender]) smtp,smime,md5  -> editorkey
true()                             smtp,md5,smime  -> reject(reason='send_subscriber')

Bon cela fonctionne mais ca implique que le scenario ne soit appliqué qu'à cette liste, en dupliquant celui d'origine.
N'est-il pas envisageable d'ajouter un statut d'utilisateur dans la philosophie sympa en plus des status "owner","editor", afin de pouvoir gèrer ce genre d'utilisateur "privilégié" ?
Le but étant de ne pas à avoir bidouiller les fichiers systèmes (scenari) mais plutôt agir sur l'interface Web de sympa.