Identifier la source de l'entrée redis louche users//diff_karma

Indices :

• en prod, revient régulièrement si on la vire
• n'existe pas en dév
• contient 20 soit le karma par défaut actuellement

app/models/node.rb:    $redis.incrby("users/#{self.user_id}/diff_karma", value)
app/models/account.rb:    self.karma += $redis.get("users/#{self.user_id}/diff_karma").to_i
app/models/account.rb:    $redis.del("users/#{self.user_id}/diff_karma")
app/models/comment.rb:      $redis.incrby("users/#{self.user_id}/diff_karma", value)

Les interdictions temporaires de pouvoir écrire des commentaires ou sur la tribune ne sont pas assorties d'une perte de karma.

Il serait logique que ça soit le cas. (et que la doc soit mise à jour en conséquence sur
https://linuxfr.org/aide#aide-karma )

Dans app/models/account.rb

  def block(nb_days, user_id)
    $redis.set("block/#{self.id}", 1)
    $redis.expire("block/#{self.id}", nb_days * 86400)

• 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.

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 (…)

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

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',

(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é).

Les URL dans le contenu en première et en seconde partie, et les URL dans les liens ne devraient pas contenir /redaction/ ou /moderation/ sauf exception. Il serait pratique de signaler de tels liens avec un pictogramme attirant l'attention (ça éviterait de faire les corrections après publication sur un signalement par un visiteur qui n'aurait pas les droits pour accès à ces parties ou qui aurait eu un 404).

Certaines pages du site sont réservées aux admins, aux modérateurs, etc. Et comme eux y ont accès grâce à leur session, ils ne se rendent pas forcément compte qu'ils ont copié/collé un lien vers la modération d'une dépêche plutôt qu'un lien vers la dépêche publiée par exemple.

Une piste pourrait être d'afficher une icône particulière via app/assets/stylesheets/RonRonnement.css.scss sur les URL linuxfr.org/admin ou linuxfr.org/moderation, par exemple en combinant/superposant  et .

Pour éviter les soucis comme https://linuxfr.org/suivi/liens-epub-casses , mettre en place un test de vie/une sonde qui récupère un epub une fois par heure et nous avertit si ça échoue.

Ajouter en rédaction et modération un liseré rouge ou autre (en tout cas différent de celui indiquant l'absence de champ texte descriptif) si une image est trop large ou haute.

• cf https://linuxfr.org/news/agregateur-leed-la-1-6-est-sortie#comment-1523478 apparemment ça peut ennuyer certains navigateurs de ne pas connaître la langue utilisée et donc de ne pas savoir quelle police/jeu de caractères utiliser. Dans le cas d'un lien vers du code/binaire/tar/etc., peut-être faut-il utiliser un code langue « x-code » plutôt que « wq » (d'après http://www.w3.org/TR/html401/struct/dirlang.html#langcodes ) ;
• on peut aussi se demander si on garde les drapeaux de langue ou pas. Cf Why flags do not represent languages (flagsarenotlanguages.com) et Flag as a symbol of language – stupidity or insult? (…)