Volevo solo aggiungere un grande ringraziamento al team di Discourse per aver incluso il parametro bypass_bump! È uno strumento piccolo ma potente: consente a script e plugin di aggiornare i contenuti in background senza far riemergere involontariamente vecchi argomenti nella visualizzazione più recente.
Nel nostro caso, lo utilizziamo per gli script di sincronizzazione ICS, e garantisce che solo le modifiche significative facciano riemergere gli argomenti. Un’aggiunta ponderata che mantiene i forum della community puliti e l’esperienza del lettore indisturbata — grazie ancora!
Questo non è un post di lodi fuorviante, come il mio ultimo🙈, perché
Discourse supporta un flag bypass_bump quando si rivede un post; impedisce che la data di “bump” dell’argomento cambi anche se si modifica l’ultimo (o il primo e unico) post. Questo è esplicitamente elencato nelle opzioni di PostRevisor (“- bypass_bump: non fare il bump dell’argomento, anche se è l’ultimo post”).
Questo argomento di lodi esiste e dichiara esattamente quel caso d’uso.
Storicamente le persone hanno utilizzato la soluzione alternativa /t/{id}/reset-bump-date perché questa opzione non era ampiamente conosciuta/documentata nella documentazione API, ma è ancora disponibile se necessario.
Nota pratica: quando si esegue PUT /posts/{post_id}.json con il nuovo raw e si include bypass_bump=true, la modifica non farà apparire l’argomento in /latest. (La documentazione ufficiale non descrive questo parametro, ma è collegato lato server tramite PostRevisor.)
Non sono ancora sicuro al 100% dello stato ufficiale di bypass_bump nella documentazione dell’API: non compare da nessuna parte in modo evidente.
Ma quando guardo i log dello script di sincronizzazione Python di Ethsim12, sono istruttivi. Lo script tenta di chiamare l’API con bypass_bump=true. Se quel parametro venisse ignorato o fosse non valido, l’unica cosa che impedirebbe bump non necessari è il fallback che hanno aggiunto: una chiamata manuale a
/t/{topic_id}/reset-bump-date
Quindi l’output del log stesso diventa una forte prova. Se il log mostra argomenti che vengono aggiornati senza apparire in /latest (e senza richiedere il fallback di reset), questa è una prova abbastanza buona che bypass_bump è attivo e funzionante. Se il log ricorre sempre a reset-bump-date, allora forse non lo è.
In altre parole: i log di questo script sono molto utili per confermare se bypass_bump esiste e viene effettivamente rispettato dal server.
Grazie per aver condiviso questa PR, moin — contesto davvero utile.
Per il mio progetto personale (l’importatore ics_to_discourse.py), ho effettivamente appena eseguito il commit di una modifica per interrompere gli aggiornamenti basati sul calendario dal “rumoroso” sollevare argomenti:
Quel commit aggiunge una logica per decidere se una modifica è “significativa” (cambio di ora/luogo ecc.) e utilizza bypass_bump più un fallback reset-bump-date in modo che le normali sincronizzazioni ICS non facciano emergere argomenti inutilmente.
Quindi questa PR si allinea perfettamente con ciò che stavo cercando di ottenere — bello vedere il core muoversi nella stessa direzione. Una volta che il comportamento “non sollevare alla modifica” sarà unito, semplificherò e abbandonerò il fallback aggiuntivo, ma per ora il commit mantiene le cose tranquille sulle attuali installazioni di Discourse.
Hmm, ho riletto questo argomento e mi sono reso conto di non aver incluso un altro PR pertinente, quando non ero attivo all’università e avevo tempo per programmare
