Je voulais juste ajouter un grand merci à l’équipe Discourse d’avoir inclus le paramètre bypass_bump ! C’est un outil petit mais puissant — il permet aux scripts et aux plugins de mettre à jour le contenu en coulisses sans faire remonter involontairement d’anciens sujets dans la vue « les plus récents ».
Dans notre cas, nous l’utilisons pour les scripts de synchronisation ICS, et cela garantit que seuls les changements significatifs font remonter les sujets. Un ajout réfléchi qui maintient les forums communautaires propres et l’expérience des lecteurs intacte — merci encore !
ceci n’est pas un post de louange trompeur, comme le dernier que j’ai fait🙈, car
Discourse prend en charge un drapeau bypass_bump lors de la révision d’un post ; il empêche la date de “bump” du sujet de changer, même si vous modifiez le dernier post (ou le premier et unique). Ceci est explicitement indiqué dans les options de PostRevisor (« - bypass_bump : ne pas faire remonter le sujet, même s’il s’agit du dernier post »).
Ce sujet de louange existe et indique exactement ce cas d’utilisation.
Historiquement, les gens utilisaient la solution de contournement /t/{id}/reset-bump-date car cette option n’était pas largement connue/documentée dans la documentation de l’API, mais elle est toujours disponible si nécessaire.
Note pratique : lorsque vous effectuez un PUT sur /posts/{post_id}.json avec le nouveau paramètre raw et que vous incluez bypass_bump=true, la modification ne fera pas remonter le sujet dans /latest. (La documentation officielle ne détaille pas ce paramètre, mais il est configuré côté serveur via PostRevisor.)
Je ne suis toujours pas sûr à 100 % du statut officiel de bypass_bump dans la documentation de l’API — il n’apparaît nulle part de manière évidente.
Mais lorsque j’examine les journaux du script de synchronisation Python d’Ethsim12, ils sont instructifs. Le script tente d’appeler l’API avec bypass_bump=true. Si ce paramètre était ignoré ou invalide, la seule chose qui empêcherait les bumps inutiles serait le repli qu’ils ont ajouté : un appel manuel à
/t/{topic_id}/reset-bump-date
Ainsi, la sortie du journal elle-même devient une preuve solide. Si le journal montre des sujets mis à jour sans apparaître dans /latest (et sans nécessiter le repli reset-bump-date), c’est une très bonne preuve que bypass_bump est actif et fonctionne. Si le journal se rabat toujours sur reset-bump-date, alors peut-être qu’il ne l’est pas.
En d’autres termes : les journaux de ce script contribuent grandement à confirmer si bypass_bump existe et est réellement respecté par le serveur.
Merci d’avoir partagé cette PR, moin — le contexte est vraiment utile.
Pour mon projet personnel (l’importateur ics_to_discourse.py), j’ai en fait récemment validé un changement pour arrêter les mises à jour pilotées par le calendrier de « faire du bruit » en remontant les sujets :
Ce commit ajoute une logique pour décider si une modification est « significative » (changement d’heure/lieu, etc.), et utilise bypass_bump plus une solution de repli reset-bump-date afin que les synchronisations ICS de routine ne remontent pas les sujets inutilement.
Cette PR correspond donc parfaitement à ce que je visais — c’est bien de voir que le cœur évolue dans la même direction. Une fois que le comportement « ne pas remonter lors de la modification » sera fusionné, je simplifierai et supprimerai la solution de repli supplémentaire, mais pour l’instant, le commit maintient le calme sur les installations Discourse actuelles.
Hmm, j’ai relu ce sujet et j’ai réalisé que je n’avais pas inclus une autre PR pertinente, quand je n’étais pas actif à l’université et que j’avais le temps de coder
