Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Quelques questions en vrac - retour d'expérience utilisation de l'API SOAP Sympa

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: David Verdin <adresse@cachée>
  • To: adresse@cachée
  • Subject: Re: [sympa-fr] Quelques questions en vrac - retour d'expérience utilisation de l'API SOAP Sympa
  • Date: Wed, 30 Sep 2020 15:50:43 +0200

Rebonjour,

Question 1 :

  • Pour fermer plein de listes d'un coup, on n'a que la commande sympa.pl --close_list="*list*[*@robot*]
  • Pour supprimer définitivement les listes déjà fermées, tu peux aller sur : https://<ton.domaine.de.listes>/sympa/get_closed_lists. Là, tu sélectionnes le lists à supprimer (pour tout supprimer, cliques sur le bouton "Inverser la sélection") et cliquer sur "Effacer les listes sélectionnées". Là, tout sera supprimé : répertoire de listes, archives, spools, etc. qui concerne cette liste. C'est la solution la plus facile.

Question 2 : Voir le message de Luc. 3000 listes, c'est pas énorme pour Sympa, donc ça ne m'inquiète pas. C'est seulement la liste des listes qui ramera un peu pour s'afficher.

Question 3 : C'est une question de scénario pour l'action "send". Selon ce que tu mets dans le scénario, tu peux décider qui a le droit de parler.

Donc :

  • pour les listes "horizontales", tu gardes le scénario send de base pour, par exemple, un groupe de travail (avec la valeur "private" par exemple)
  • pour les listes "verticales", la solution la plus simple est de faire une liste de profs (ceux qui auront le droit de parler) et de créer une scénario send spécial, qui contiendrait par exemple :
    is_subscriber('nom.de.la.liste.de.profs', [sender])    smtp,dkim,md5,smime   ->   do_it
    true()                                                                         smtp,dkim,md5,smime   ->   reject
    Supposons que ce fichier de scénario s'appelle "send.que-les-profs", tu dois ensuite donner la valeur "que-les-profs" au paramètre "send" de la config de liste. Soit à la création, soit à grands coups de sed après la création, comme tu veux, mais jepense que ça vaudrait mieux que ce soit à la création.

Pour en savoir plus sur les scénarios : https://sympa-community.github.io/gpldoc/man/sympa_scenario.5.html

Bonne journée !

David

On 30/09/2020 15:08, Dornbusch Joachim wrote:

Bonjour

Comme David Verdin m'a gentiment répondu ce matin j'en profite pour abuser et poser en vrac quelques questions issues d'une à deux semaines de développement d'une application adossée à Sympa pour la rentrée "hybride".

Je précise, pour donner le contexte, que chez nous les inscriptions pédagogiques sont tardives, les gens se pointent aux séminaires sans prévenir et il y a beaucoup d'auditeurs libres; d'où la nécessité d'un système pour subordonner l'accès au présentiel à contrôle préalable et réguler ainsi la fréquentation selon la "jauge des salles", et d'où le besoin de listes pour communiquer avec les groupes d'élèves-auditeurs.trices. [PS le code est sur notre Gitlab interne mais quand j'aurai deux minutes je la pousserai sur Github]

Question 1. Au cours des tests, de la recette, nous avons créé pas mal de listes "bidon" via l'API et nous voudrions les supprimer avant l'ouverture en production.
Faute de temps nous n'avons pas pu nous adosser à un sympa de test ou de preprod et du coup ces dizaines de listes fantaisies polluent le sympa de prod.
Quand j'en supprime une manuellement depuis l'interface elle reste au statut "liste fermée".
Y a-t-il autre chose à faire que de demander aux admins de les supprimer une par une à la main ?
Peuvent-ils supprimer le répertoire de la liste sur le disque ou est-ce que ça placera l'appli en état incohérent ?

Question 2. L'utilisation de l'appli va générer jusqu'à 3000 listes de diffusion sur sympa (1000 ue x 3 modes = global, distanciel, présentiel).
Est-ce que vous pensez qu'on risque un problème de montée en charge.

Question 3. La direction voulait que les enseignant.e.s chercheurs.euses puissent créer au choix des listes "horizontales" (tout le monde peut parler à tout le monde) ou "verticales" (seul.e.s les profs parle).
Le problème est qu'on n'a pas vu comment faire des listes "verticales" via l'API à moins à moins de rendre le.la référent.e propriétaire de la liste avec des tas d'effets de bord indésirables.
Et ça n'aurait même pas permis aux autres intervenant.e.s (non référents) de s'exprimer sur les listes...
On n'a même pas trouvé comment créer des modérateurs.trices via l'API ce qui nous aurait donné un début de solution.
Du coup on n'a créé que des listes "horizontales". Était-ce fatal ?

Merci pour vos lumières et désolé pour ce "ticket non atomique".

Bonne journée

Joachim Dornbusch
Direction des Systèmes d'Information
54 boulevard Raspail, 75006 Paris


-- 
"Mieux vaut viser la perfection et la rater que viser la médiocrité et l'atteindre."
- Francis Blanche

David Verdin
Chef de Projet Collaboratif
Département PROduits NUMériques
Direction des Services Applicatifs
RENATER - Rennes

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archives gérées par MHonArc 2.6.19+.

Haut de le page