Nettoyer redis lors d'une suppression brutale de dépêche en rédaction ou en modération.

Unexpected <news_id> in boards/chans/news/xxxx
Unexpected <link_id> in links/xxxx/*
Unexpected <news_id> in news/xxxx/*

• documenter le schéma redis (fait, reste à commiter)
• ajouter un test pour vérifier la conformité au schéma (en cours)
• nettoyer ce qui dépasse au lance-flamme sur alpha/prod (en cours)

Une fois que la modération a accepté ou rejeté une dépêche, on peut faire sauter l'urgence dessus. (Côté redis, le news/urgent ne va pas tarder à atteindre le millier d'entrées, et ça n'a pas beaucoup d'intérêt)

Si un compte est fermé par quelqu'un d'autre que l'utilisateur lui-même (dont une fermeture administrative), donc principalement le cas de spam, autant virer le lien vers le site perso au passage.

Si on soumet une dépêche avec plusieurs paragraphes en première partie et plusieurs paragraphes en seconde partie, on se retrouve en base avec des fins de ligne à la Windows CR / ^M ajoutés à la fin de chaque paragraphe (sauf le dernier de chaque partie).

Un souci dans la découpe en paragraphe ?

Je veux étiqueter fedora. Je commence à taper fedora et les suggestions sont

• fedora
• ubuntulubuntukubuntuedubuntufedoraopensusedebiansqueezewheezyope
• fedoraxgdmclaviersouris
• fedoraévènementrf
  

Seul le premier est un tag public. Les trois autres sont des tags non publics et ne devraient pas être suggérés (ou alors uniquement parmi MES tags non publics).

(le fait que c'est trois tags devraient être juste supprimés est une autre histoire…)

Passer les liens d'un commentaire en nofollow si le commentaire est noté négativement.

Objectifs :

• les spammeurs attentifs au nofollow ne viendraient pas poster (on peut rêver)
• les spammeurs non-attentifs et les pénibles pointant des sites problématiques ne bénéficieraient pas de visibilité vis-à-vis des moteurs de recherche
• les visiteurs classiques ne seraient pas concernés

Le code de confirmation des courriels envoyés par des non-abonnés à Sympa ne fonctionne plus en Debian Stretch, pour une raison que j'ignore.

L'utilisateur envoie par exemple le bon code e9f2d0ad0bf4bc21801ca94bbc38d413. Qui devient *@\\*_e9f2d0ad0bf4bc21801ca94bbc38d413 et qui est comparé à ce qui attendu soit *@*_e9f2d0ad0bf4bc21801ca94bbc38d413, et ça échoue, pour cause d'échappement excédentaire.

Le patch qui suit corrige salement en attendant de comprendre pourquoi :

diff -u /usr/share/sympa/lib/Sympa/Spool.pm.orig /usr/share/sympa/lib/Sympa/Spool.pm
--- /usr/share/sympa/lib/Sympa/Spool.pm.orig    2019-03-05 20:23:21.721706266 +0100
+++ /usr/share/sympa/lib/Sympa/Spool.pm 2019-03-05 20:24:20.074540758 +0100
@@

(signalement via https://linuxfr.org/forums/general-general/posts/les-tags-populaires-de-linuxfr-dans-le-pied-de-page )

Dans les tags populaires en bas de page, on affiche les tags non masqués certes (donc pas 'grosconnard'), mais aussi ceux des contenus masqués (exemple 'banque' qui est un tag public acceptable, mais qui traine sur les spams et est donc sur-évalué).

Certaines dépêches sortent de la modération sans tag. Il y a toujours au moins un tag pertinent pour indiquer le nom d'un projet ou d'un événement, un lieu, un langage, un domaine, etc. Pour éviter cela, et ne pas juste compter sur la vigilance des modérateurs, rendons la présence d'au moins un tag nécessaire pour publier une dépêche (c'est inutile pour la rejeter ou la renvoyer en rédaction par exemple). Même chose pour les sondages d'ailleurs.

Exemple de dépêches publiées (…)

Avec un karma de zéro, la CSS contrib/nightgrey n'affiche pas son propre commentaire en prévisualisation.

Cf discussion sur https://linuxfr.org/news/le-frido-2018-livre-libre-de-mathematique-pour-l-agregation#comment-1748977

Version brute

• http://example.invalidhttp://example.invalid (double URL) -> OK, au moins ça se voit que ça marche pas
• http://https://example.invalid ou http://ftp://example.invalid (double schéma) -> OK, au moins ça se voit
• http%20://example.invalid (espace excédentaire) -> OK, non cliquable
• http:/example.invalid (barre oblique manquante) -> OK, non cliquable
• news://example.invalid , mailto://example@example.invalid ou xmpp://example@example.invalid (deux barres obliques excédentaires) => OK, au moins ça se voit que ça marche pas
• htttp://example.invalid ou htpp://example.invalid ou htt://example.invalid ou http:example.invalid (mauvais schéma) -> OK, non cliquables
• absence de (…)

Titre du lien d'une dépêche trop long pour le stockage en BD

I, [2018-04-26T17:28:16.613132 #31058]  INFO -- : Completed 500 Internal Server Error in 248ms (ActiveRecord: 205.7ms)
F, [2018-04-26T17:28:16.616069 #31058] FATAL -- : 
ActiveRecord::StatementInvalid (Mysql2::Error: Data too long for column 'title' at row 1: INSERT INTO `links` (`title`, `url`, `lang`, `news_id`, `created_at`, `updated_at`) VALUES ('« Save Code Share » : une campagne pour protéger les forges logicielles et les communautés du libre (relais de l\'April)', 'https://www.april.org/savecodeshare-une-campagne-pour-proteger-les-forges-logicielles-et-les-communautes-du-libre', 'fr', 38560, '2018-04-26 15:28:16',

Ajouter des statistiques sur les deux comptes fictifs Collectif et Anonyme.

Actuellement, pour les dépêches collaboratifs (compte Collectif) :

+------+--------------+-----+
| year | content_type | cnt |
+------+--------------+-----+
| 2008 | News         |   1 |
| 2013 | News         |   3 |
| 2014 | News         |   8 |
| 2015 | News         |   6 |
| 2016 | News         |  41 |
| 2017 | News         |  65 |
| 2018 | News         |   9 |
+------+--------------+-----+

Beaucoup plus (…)

La page perso indique en titre « Machin a écrit 42 contenus de type dépêche ou journal ». Il est implicite que ne sont prises en compte que les dépêches dont Machin est l'auteur unique ou principal (pas les dépêches collaboratifs auxquelles il a pu participer).

Cela vient du fait que la page utilisateur affichait initialement QUE les journaux personnels (dont on est l'auteur unique), puis que l'on a ajouté les dépêches (parce que les dépêches sont le cœur du site et (…)