[sympa-fr] Impossible de désabonner un utilisateur

[Nicolas Boullis <adresse@cachée>]

Bonjour,

Un administrateur d'une liste de diffusion vient de se plaindre du fait
qu'il n'arrivait pas à désabonner certains de ses utilisateurs.

Après avoir un peu galéré, j'ai remarqué qu'il avait
subscribed_subscriber=2 dans la table subscriber_table. En passant
manuellement sa valeur à 1, il devient possible de supprimer l'utilisateur.

En regardant un peu plus en détail les valeurs des champs
subscribed_subscriber et included_subscriber, je trouve une certaine
hétérogénéïté :

SELECT subscribed_subscriber, COUNT(*) FROM subscriber_table GROUP BY
subscribed_subscriber
+-----------------------+----------+
| subscribed_subscriber | COUNT(*) |
+-----------------------+----------+
|                  NULL |     3654 |
|                     0 |     2599 |
|                     1 |     3639 |
|                     2 |      127 |
+-----------------------+----------+

SELECT included_subscriber, COUNT(*) FROM subscriber_table GROUP BY
included_subscriber
+---------------------+----------+
| included_subscriber | COUNT(*) |
+---------------------+----------+
|                NULL |       55 |
|                   0 |     3719 |
|                   1 |     2624 |
|                   2 |     3621 |
+---------------------+----------+

Après un peu de google, et lecture de la procédure d'upgrade dans
/usr/lib/sympa/bin/List.pm, il semble que les seules « bonnes » valeurs
pour ces champs sont 0 ou 1. Il semble semble aussi qu'un double mapping
a lieu lors de l'upgrade, d'abord de '0' et '1' vers 1 et 2, puis de 1
et 2 vers 0 et 1.

Lors de notre dernière mise à jour, qui date de plusieurs mois, de la
version (Debian) 4.1.5-2 à la version (Debian toujours) 5.2.3-1.2, nous
avions rencontré quelques problèmes, que nous n'avions pas cherché à
creuser puisque tout semblait bien marcher. (Je crois me souvenir que
nous avions du renseigner le champ robot_subscriber dans la table
subscriber_table, ce qui n'avait pas posé de difficulté, puisque nous
avions un seul robot.) A posteriori, il semble finalement que ce n'était
pas une bonne idée de n'avoir pas creusé le problème...

Donc finalement, il semble que l'upgrade n'a été faite qu'à moitié, et
que seul le mapping de '0' et '1' vers 1 et 2 a été fait.

Du coup, on a dans la table des nouveaux 0, des nouveaux 1, des 1
anciens '0' et des 2 anciens '1'. On a aussi des NULL dont j'imagine
qu'ils vallent des 0.

Y a-t-il une solution pour nous tirer de ce mauvais pas ? Il est facile
de remplacer tous les 2 par des 1, mais je ne sais pas comment
distinguer des nouveaux 1 de 1 anciens '0', et j'ai peur de perdre une
partie de l'information potentiellement utile en remplaçant les 2 par
des 1...


Merci d'avance,

Nicolas Boullis
École Centrale Paris