Re: [sympa-fr] Mise à jour des abonnés (version 6.1b7)

[David Verdin <adresse@cachée>]

Le 29/09/2010 16:00, Pascal Maes a écrit :

Bonjour,


Effectivement, il y a des adresses dans la liste d'exclusion.
j'ai fait une recherche sur une des adresses qui se trouve dans la requête SQL et dans la liste d'exclusion ; elle ne se trouve pas dans la base de données rattachée à la liste faq-bdrt.
  

Oui, au temps pour moi : quand on utilise la liste d'exclusion, la personne est désabonnée. Elle ne sera ensuite pas ajoutée lors des synchronisations suivantes.

Si je l'ajoute manuellement : 

Sep 29 15:42:22 localhost wwsympa[3491]: info [robot listes.uclouvain.be] [session 23355956046840] [client 130.104.207.207] [user adresse@cachée] [list faq-bdrt] main::do_add() do_add(adresse@cachée)
Sep 29 15:42:22 localhost wwsympa[3491]: err List::get_subscriber() Unable to retrieve information from database for user adresse@cachée
Sep 29 15:42:22 localhost wwsympa[3491]: info List::insert_delete_exclusion() List::insert_delete_exclusion("adresse@cachée", "faq-bdrt", "listes.uclouvain.be", "delete")
Sep 29 15:42:22 localhost wwsympa[3491]: err List::delete_subscription_request() No pending subscription was found for users adresse@cachée


Il est bien ajouté (subscribed) dans la liste des abonnés et ne se retrouve plus dans la liste des abonnés.
  

Tu veux dire "et ne se retrouve plus dans la liste d'exclusion", c'est ça ?

Si je le supprime, il disparait de la liste des abonnés et n'est pas ajouté dans la liste des exclusions.

Si je resynchronise :

Sep 29 15:45:52 localhost wwsympa[3497]: info [robot listes.uclouvain.be] [session 23355956046840] [client 130.104.207.207] [user adresse@cachée] [list faq-bdrt] main::do_sync_include() do_sync_include(faq-bdrt)
Sep 29 15:45:52 localhost wwsympa[3497]: info List::_include_users_sql() 12 included users from SQL query
Sep 29 15:45:52 localhost wwsympa[3497]: info List::_include_users_sql() 965 included users from SQL query
Sep 29 15:45:52 localhost wwsympa[3497]: info List::_include_users_sql() 280 included users from SQL query
Sep 29 15:45:52 localhost wwsympa[3497]: info List::_include_users_sql() 11 included users from SQL query
Sep 29 15:45:52 localhost wwsympa[3497]: info List::insert_delete_exclusion() List::insert_delete_exclusion("adresse@cachée", "faq-bdrt", "listes.uclouvain.be", "delete")
Sep 29 15:45:52 localhost wwsympa[3497]: notice List::sync_include() List:sync_include(faq-bdrt): 1 users added
Sep 29 15:45:52 localhost wwsympa[3497]: notice List::sync_include() List:sync_include(faq-bdrt): 0 users updated
Sep 29 15:45:52 localhost wwsympa[3497]: info [robot listes.uclouvain.be] [session 23355956046840] [client 130.104.207.207] [user adresse@cachée] [list faq-bdrt] main::do_review() do_review(0)


il n'y a que cet utilisateur-là qui est ajouté, pas les 12 autres.
  

Normal, il est le seul à avoir été supprimé de la liste d'exclusion. Voir ci-dessous pour les détails.

Je vois bien un moyen de contourner le problème :

  - les ajouter manuellement à la liste,
  - les supprimer
  - refaire une synchronisation.
  

Il y a plus simple : supprimer les entrées correspondantes dans la table "exclusion_table".
Quelques mots sur l'exclusion pour répondre aux questions que tu as posées. Dasn les versions antérieures à la 6.1, il était impossible à un utilisateur abonné automatiquement à une liste par inclusion de s'en désabonner. C'est maintenant possible (si le désabonnement est autorisé dans la liste). Lorsque l'utilisateur se désabonne, il est supprimé de la table des abonnés et son adresse est ajoutée à une table d'exclusion. De cette manière, il ne sera pas automatiquement réabonné lors de la synchronisation suivante : Sympa se rappelle que cette personne ne veut pas être abonnée. La personne peut ensuite se réabonner normalement.
Je note un semi-bug, d'ailleurs : lorsqu'une personne se réabonne alors qu'elle était incluse, elle est notée comme abonné manuel ET comme personne incluse automatiquement. Ce choix est discutable parce qu'on pourrait vouloir ne garder que l'abonnement automatique.

Pour répondre directement à tes questions, maintenant :

Questions : 
   à quoi sert la liste d'exclusion ?
  

Voir ci-dessus. Les utilisateurs peuvent se désabonner (et être supprimés) des listes avec inclusion.

   comment se construit-elle ?
  

Manuellement. Quand les utilisateurs inclus depuis une source de données se désabonnent, leur adresse est ajoutée à la lsite d'exclusion.

   comment la supprimer (gérer) ?
  

C'est une fonctionnalité toute récente et nous n'avons pas encore ajouté d'outil de gestion dans l'interface web. Il faut donc passer par un client SQL pour supprimer les entrées. L'utilisateur, lui, peut s'abonner manuellement, il set alors supprimé de la liste d'exclusion.

Hope this helps.

David

Merci
Le 29 sept. 2010 à 10:36, David Verdin a écrit :

  

Bonjour Pascal,

Je n'arrive pas à reproduire ce comportement ici.
À tout hasard, est-ce que ces adresses ne se trouveraient pas dans les adresses exclues de cette liste (bouton "exclure", en haut à droite dans la page que tu nous a envoyées) ?
Je suis surpris de ne pas voir apparaître de ligne du type :

List::insert_delete_exclusion() List::insert_delete_exclusion("adresse@abonner", "faq-bdrt", "listes.uclouvain.be", "delete")

Cette fonction est censée être appelée à chaque fois qu'on ajoute un nouvel utilisateur. Tout se passe comme si les 12 adresses manquantes étaient déjà abonnées (on les trouve dans la base de données) on fait alors une mise à jour de leurs données d'abonnés et non un ajout.

Pour diagnostiquer le problème, est-ce que tu peux vérifier si les adresses manquantes ne seraient pas déjà présentes dans la tables subscribers_table pour cette liste ?

Pour l'affichage de la liste des membres : c'est un bug signalé par Dan Pritts : https://sourcesup.cru.fr/tracker/index.php?func=detail&aid=7094&group_id=23&atid=167
C'est sur ma "todo list".

Cordialement,

David

Le 28/09/2010 21:41, Pascal Maes a écrit :
    

Bonjour,


Je suis passé à la vesion 6.1b7.
Aucun problème si ce n'est le "custom_robot_parameter" mais c'était déjà signalé.

Par contre je suis confronté à un comportement bizarre.

Une liste de type "include2" utilise une requête SQL.
Lorsque je synchronise les abonnés, je vois ceci dans le fichier sympa.log

Sep 28 21:17:35 localhost wwsympa[3498]: info [robot listes.uclouvain.be] [session 3938766681036] [client 130.104.240.228] [user 
adresse@cachée
] [list faq-bdrt] main::do_sync_include() do_sync_include(faq-bdrt)
Sep 28 21:17:35 localhost wwsympa[3498]: info List::_include_users_sql() 13 included users from SQL query
Sep 28 21:17:35 localhost wwsympa[3498]: notice List::sync_include() List:sync_include(faq-bdrt): 0 users updated
Sep 28 21:17:35 localhost wwsympa[3498]: info [robot listes.uclouvain.be] [session 3938766681036] [client 130.104.240.228] [user 
adresse@cachée
] [list faq-bdrt] main::do_review() do_review(0)


le 13 est bien correct mais après la synchronisation, l'interface web affiche toujours 1 seul abonné (voir image jointe)


  






je ne vois pas pourquoi "la liste des membres de la liste a été générée/mise à jour" est affiché deux fois.


  

      

-- 
David Verdin
Comité réseau des universités

Due to the limitations of human brain, I fail to remember all the mails.
So if you want your bug reports or feature requests for Sympa to be processed, please post them to the Sympa tracker
    

--
David Verdin
Comité réseau des universités

Due to the limitations of human brain, I fail to remember all the mails.
So if you want your bug reports or feature requests for Sympa to be processed, please post them to the Sympa tracker