Wikipédia:Bulletin du filtrage/2019

Modificateurs de filtres inactifs modifier

Bonjour,

Pour information, j'ai demandé aux bureaucrates de retirer le statut de quatre modificateurs de filtre inactifs depuis plus d'un an.

Orlodrim (discuter) 27 janvier 2019 à 14:51 (CET)[répondre]

ID des filtres avec Spécial:BotPasswords modifier

Bonjour, pour mettre à jour Wikipédia:AbuseFilter/Modifications bloquées, AkeronBot (d · c · b) fait une requête API abuselog, or depuis qu'il est obligatoire d'utiliser un accès Spécial:BotPasswords, l'id du filtre n'apparaît plus pour les filtres privés, exemple :

   [id] => 2467910
   [filter_id] => 
   [filter] => Ajouts intempestifs Liza Veniza / Willy on Wheels
   [user] => 88.187.63.4
   [ns] => 0
   [title] => Ondekoza
   [action] => edit
   [result] => disallow
   [timestamp] => 2019-02-07T14:44:31Z

En conséquence il n'est plus possible de faire le lien avec le filtre, mais le nom du filtre est tout de même présent. J'avais déjà occasionnellement observé la même chose mais seulement lorsque l'interrogation de l'API se faisait sans être connecté au compte. Effectivement en testant le lien abuselog ci-dessus sans être connecté, le filter_id est toujours vide. Normalement un simple compte est suffisant, le fait d'avoir donné le statut de filtreur à AkeronBot (d · c · b) n'a rien changé, j'ai bien coché « Afficher les entrées de journal confidentielles » dans Spécial:BotPasswords, j'ai même essayé en cochant tout. Si quelqu'un a une solution ou le courage de faire un rapport de bug... –Akeron (d) 7 février 2019 à 15:51 (CET)[répondre]

Notification Akeron :
Je crois que ça correspond à ce qui a été signalé dans phab:T161816.
Pour l'instant, il est encore possible de te connecter au compte principal en utilisant l'API "interactive". Du moment que la double authentification n'est pas activée, elle n'est pas vraiment interactive et une requête comme "action=clientlogin&username=AkeronBot&password=...&logintoken=...&loginreturnurl=https://itsnotreallyused.example.com" te connectera au compte original, avec la possibilité de voir les filtres privés.
Orlodrim (discuter) 7 février 2019 à 18:17 (CET)[répondre]
Ça fonctionne, merci, j'espère que ça va rester possible ou qu'ils auront corrigé le bug avec la nouvelle méthode d'ici là. –Akeron (d) 8 février 2019 à 15:57 (CET)[répondre]
Bonjour! Le droit "abusefilter-view-private", qu'est nécessaire pour voir les IDs des filtres privés, a été ajouté à la liste de droits disponibles avec le grant "viewrestrictedlogs". Ça signifie que maintenant vous pouvez utiliser ce grant avec BotPassword sans hacks :-) (Je m'excuse, mon Français n'est pas très bon.) --Daimona Eaytoy (discuter) 11 février 2019 à 09:56 (CET)[répondre]

Filtre privé ? modifier

Bonjour à tous, je crois que ce nouveau filtre ; Spécial:Filtre antiabus/336 devrait avoir le statut de privé, à mon humble avis, cordialement. FrankyLeRoutier sous adresse IP 135.19.242.113 (discuter) 8 juillet 2019 à 21:26 (CEST)[répondre]

Ce filtre n'est pas et n'a jamais été public. Cordialement. 'toff [discut.] 9 juillet 2019 à 07:27 (CEST)[répondre]
désolé pour le dérangement. 135.19.242.113 (discuter) 9 juillet 2019 à 10:49 (CEST)[répondre]

Bug plugpanel modifier

Bonjour, pour info je viens de désactiver le filtre n° 191 (description : « Insertion de javascript avec l'éditeur visuel, probablement par une extension de navigateur ») vu que ce dernier s'est déclenché pour la dernière fois le 7 mars 2016.— Gratus (discuter) 17 juillet 2019 à 06:00 (CEST)[répondre]

État limité modifier

Bonjour, le filtre 37 (Cassage de modèle ou de table) apparait en rouge avec l'état « limité » en plus de « activé ». À quoi cela correspond-il exactement et est-ce qu'une action est nécessaire ? Cordialement,— Gratus (discuter) 30 août 2019 à 00:21 (CEST)[répondre]