En cas de suppression d'une entrée de suivi (par l'équipe de maintenance en tout cas) :

• la notification en modération dit "supprimée"
• mais en tant qu'admin et/ou modération (?) on accède encore à l'entrée, sans le bandeau rouge habituel disant "intervention de la modération" et un statut indiqué "ouvert"
• en base l'état est nodes.public=0 et tracker.status=opened

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 ?

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)

Dans la famille « Retirer les liens » je voudrais oreilly.fr.

Aide: https://github.com/akamhy/waybackpy/wiki/CLI-docs

Actuellement sur la dépeche https://linuxfr.org/news/dans-les-kiosques-cet-%C3%A9t%C3%A9-2011 parce les titres sont des liens :

Sommaire

[Linux Pratique n° 65 (mai-juin)](http://www.linux-pratique.com/index.php/2011/04/22/linux-pratique-n%C2%B065-maijuin-2011-chez-votre-marchand-de-journaux)
[Linux Mag HS N° 55] (http://www.gnulinuxmag.com/index.php/2011/07/01/gnulinux-magazine-hs-n%C2%B055-juillet-aout-2011-chez-votre-marchand-de-journaux), spécial C/C++
[MISC N° 56 ] (http://ed-diamond.com/produit.php?ref=misc56), juillet-août
[Linux Mag N° 140 ] (http://www.gnulinuxmag.com/index.php/2011/06/24/gnulinux-magazine-n%C2%B0140-juilletaout-2011-chez-votre-marchand-de-journaux), juillet-août
Notes subjectives de lecture de Pour la Science
Chronique de Tim Berners Lee
Article de Jean-Paul Delahaye

Bug détecté par Antistress en s'apercevant que le classement change brutalement lors du passage en modération de cette dépêche.

La requête est en gros :

SELECT users.name, users.cached_slug, COUNT(*) AS cnt FROM news JOIN news_versions ON news.id = news_versions.news_id JOIN users ON users.id = news_versions.user_id WHERE news_versions.created_at < news.submitted_at AND news_versions.created_at >= DATE_ADD(NOW(),

Ajouter un liseré rouge (comme pour les images sans titre) sur le "Vous pouvez éditer en cliquant sur le crayon" pour éviter que les modérateurs ne publient avec ?

Quelques soucis liés à img et la modération des images :

• HTTP 500 au niveau de l'interface de modération en cas de blocage d'une image

ArgumentError (wrong number of arguments (0 for 1)):
  app/models/image.rb:17:in `decoded_link'
  app/models/image.rb:22:in `destroy'
  app/controllers/moderation/images_controller.rb:9:in `destroy'

• ensuite si jamais ça marchait, on stocke un status=Blocked dans redis, mais il n'est pas utilisé

(en attendant le traitement manuel reste possible bien sûr)

Rejet en modération d'une dépêche anonyme :

I, [2014-10-18T23:04:43.426166 #12082]  INFO -- : Completed 500 Internal Server Error in 14ms
F, [2014-10-18T23:04:43.428202 #12082] FATAL -- : 
StateMachine::InvalidTransition (Cannot transition state via :refuse from :refused (Reason(s): Le State translation missing: 
fr.activerecord.errors.models.news.attributes.state.invalid_transition)):
  app/controllers/moderation/news_controller.rb:63:in `refuse'

Quand tu réédites une entrée, qu'il y a déjà un admin affecté et que tu es admin, par défaut il change la personne affectée. Il serait mieux de ne pas changer dans ce cas.

• préparer la page de maintenance sur zobe (elle aura de l'HTTPS comme ça) plutôt que TF
• mettre la conf nginx de zobe dans git ensuite

La tribune du site LinuxFr.org a été conçue comme un lieu d'échanges permettant d'aborder des sujets divers et variés. Elle est parfois, et malheureusement trop souvent, pervertie par des gens qui ont des comportements déplacés, impolis, incorrects voire probablement illégaux.

Le retour de la fonctionnalité de blocage d'écriture sur la tribune pour un utilisateur donné serait donc souhaitable (dommage de devoir en arriver là mais bon, LinuxFr n'a pas vocation à héberger des tels contenus...).

Une implémentation possible serait de (…)

Exemple https://linuxfr.org/users/natal/comments.atom

F, [2014-08-31T07:43:22.526065 #23134] FATAL -- : 
ActionView::Template::Error (undefined method `created_at' for nil:NilClass):
    1: atom_feed do |feed|
    2:   feed.title("LinuxFr.org : les commentaires pour #{@user.try(:name) || @node.content.title}")
    3:   feed.updated((@comments.last || @node).created_at)
    4:   feed.icon("/favicon.png")
    5: 
    6:   @comments.each do |comment|
  app/views/comments/index.atom.builder:3:in `block in _app_views_comments_index_atom_builder___436111265112466474_68531700'
  app/views/comments/index.atom.builder:1:in `_app_views_comments_index_atom_builder___436111265112466474_68531700'
  app/controllers/users_controller.rb:64:in `block (2 levels) in comments'
  app/controllers/users_controller.rb:62:in `comments'

https://linuxfr.org/aide#aide-authentification

Par rapport à un visiteur, un animateur de l'espace de rédaction (rôle editor) peut :

• envoyer n'importe quelle dépêche en rédaction vers la modération ;
• réattribuer n'importe quelle dépêche en rédaction à un autre compte ;
• modifier l'indicateur d'urgence sur une dépêche en rédaction.

Doc incomplète à revoir :

• étiqueter (tag) une dépêche en rédaction ('taggable_by')
• relancer les rédacteurs d'une dépêche ('followupable_by')
• supprimer une dépêche en rédaction ('erasable_by')

Le DNS de lists doit être corrigé pour gérer à la fois la partie courriel et la partie web.

(et ensuite remettre la lettre quotidienne dans le plan du site/l'aide)