Re:_[sympa-fr]_fichier_subscribers,_sources_et_visibilité_des_abonnements

["Stephane Davy" <adresse@cachée>]

Et pourtant si, ce champ est bien mis à 1 pour toutes les entrées de la table
subscriber_table
j'ai essayé de rejouer la requête de selection du get_which_db, j'obtiens bien
quelque chose:

$statement = qq{SELECT list_subscriber,
                         robot_subscriber,
                         bounce_subscriber,
                         reception_subscriber,
                         topics_subscriber,
                         include_sources_subscriber,
                         subscribed_subscriber,
                         included_subscriber
                         FROM subscriber_table
                         WHERE user_subscriber = 'test\@tests'};

qui me donne:

alcovetest|lists.eurocontrol.int|||||1|0

peut être que certains de ces champs ne devraient pas être nuls?

pour reception_subscriber, cela ne change rien qu'il soit à 'mail' ou vide...


Olivier_Salaün_-_CRU <adresse@cachée> wrote: 
> Bonjour,
> 
> Le changement majeur entre la version 4.1 et la version 5.2 est 
> l'introduction du mode 'include2'. Ce mode offre les avantages combinés 
> des modes 'database' et 'include'. A cette occasion 3 nouveaux champs 
> ont été ajoutés à la base : subscribed_subscriber, included_subscriber 
> et include_sources_subscriber
> 
> Normallement lors du processus de migration sympa.pl initialise le champ 
> subscribed_subscriber à 1 lorsque c'est nécessaire. Le log correspondant 
> est "Updating subscribed field of the subscriber table...". La requête 
> correspondante est "UPDATE subscriber_table SET subscribed_subscriber=1 
> WHERE ((included_subscriber IS NULL OR included_subscriber!=1) AND 
> (subscribed_subscriber IS NULL OR subscribed_subscriber!=1))"
> 
> Dans votre cas, il semble que la requête n'a pas été exécutée ; vous 
> pouvez l'exécuter "manuellement".
> 
> Stephane Davy wrote:
> 
> >je rencontre quelque soucis sur la fonction "recherche" des abonnés, ainsi
que sur la visibilité des listes auxquelles je suis abonnés, et je pense que 
ces
2 problèmes sont liés.
> >
> >Tout d'abord, le contexte: j'ai effectué une migration de 4.1 vers 5.2 en
changeant de SGBD au passage (de MySQL vers Oracle 10g). Pour faire cette
migration, j'ai écrit un script Perl qui prend les données dans MySQL et les
réinjecte dans Oracle (en forçant au passage le robot_subscriber). Ensuite, je
modifie les paramètres de connexion de Sympa, et je lance sympa.pl en mode
debug. Je constate qu'il effectue un certain nombre de mise à jour dans la 
base
Oracle.
> >Lorsque je regarde la liste des abonnés depuis l'interface Web, celle-ci 
> >est
vide. Si je force user_data_source à database dans le fichier config de la
liste, je récupère les informations.
> >J'ai donc forcé user_data_source à database pour toute les listes, et cela
semble fonctionner. Au passage, j'ai constaté que le fichier subscriber était
vide pour toutes les listes, est -ce normal?
> >
> >Par contre, j'ai un autre soucis: les recherche ne marche pas sur les
abonnés, et lorsqu'un utilisateur se connecte, il ne voit dans la colonne "mes
listes" que les listes dont il est propriétaire, pas celle dont il est
simplement abonné.
> >
> >Ces problèmes n'apparaissent pas avec les listes dont le user_data_source 
> >est
sur file.
> >  
> >
> 
> 

-- 
Stéphane Davy
Responsable technique Alcôve
01 46 49 25 18