Le modifiche nel periodo di grazia aggirano la revisione dei media `skip_review_media_groups`

Contribuisci Bug
, , ,
1

Riepilogo

Il controllo “review media” (impostazione sito skip_review_media_groups) viene applicato solo al momento della creazione del post, in NewPostManager. Le modifiche passano attraverso PostRevisor, che non esegue mai il controllo dei media. Un utente può quindi pubblicare inizialmente del testo semplice (passando la revisione), per poi aggiungere immagini tramite una modifica — e il post non entra mai nella coda di revisione.

Peggio ancora, se la modifica avviene entro il editing_grace_period (5 minuti di default) e la differenza è inferiore a editing_grace_period_max_diff (100 caratteri di default — una singola riga markdown per un’immagine caricata è di circa 40–60 caratteri), la modifica non crea nessuna revisione e nessuna icona della matita, rendendo il bypass completamente invisibile nell’interfaccia utente.

Passaggi per riprodurre il problema

  1. Configurare skip_review_media_groups in modo che gli utenti normali (es. TL0/TL1) non siano esenti — i post con media dovrebbero richiedere approvazione.
  2. Come utente normale, creare un post contenente solo testo. Viene approvato/pubblicato normalmente (nessun media → nessuna revisione).
  3. Entro il periodo di grazia, modificare il post e inserire un’immagine caricata.

Attesa

Il post (che ora contiene media) dovrebbe essere inviato alla coda di revisione, o almeno la modifica dovrebbe essere soggetta allo stesso controllo dei media applicato alla creazione del post.

Reale

  • Il post viene pubblicato con l’immagine e non entra mai nella coda di revisione.
  • Non viene creato alcun record di revisione, non viene mostrato alcun indicatore di modifica.

Prove (istanza di produzione)

p.version                                   # => 1
PostRevision.where(post_id: p.id).count     # => 0
p.created_at                                # => 2026-07-30 07:33:28 UTC
p.updated_at                                # => 2026-07-30 07:34:00 UTC
UploadReference.where(target: p).pluck(:created_at)
                                            # => [2026-07-30 07:34:01 UTC]

Post di solo testo creato alle 07:33:28, immagine aggiunta tramite modifica circa 32 secondi dopo — nessun storico di modifiche visibile, nessuna revisione.

Codice rilevante

  • lib/new_post_manager.rb — post_needs_approval? restituisce :contains_media tramite contains_embedded_media?, ma questo viene eseguito solo per i nuovi post.
  • app/models/post_analyzer.rb#embedded_media_count — la logica di conteggio dei media.
  • PostRevisor — nessun controllo equivalente dei media sulle modifiche.

Soluzione suggerita

Eseguire il controllo contains_media anche in PostRevisor (quando la modifica introduce media e l’editore non è in skip_review_media_groups / non è dello staff), accodando un ReviewablePost per il post modificato.

2 Mi Piace
3

Grazie per la segnalazione @Editor0732 :+1: Sarà corretto da

4

Ho provato a distribuire questa PR e ho notato un’asimmetria nei meccanismi di moderazione dei media tra i nuovi post e le modifiche, e vorrei segnalare questo problema:

Nuovi post con media — ReviewableQueuedPost (revisione prima della pubblicazione)

  • Il post non viene creato affatto; il contenuto rimane nel payload in attesa di revisione fino all’approvazione
  • L’autore vede la sezione “in attesa di approvazione” (pending_posts) nella pagina dell’argomento
  • Il post diventa visibile a tutti solo dopo che un moderatore lo ha approvato (perform_approve_post → PostCreator)
  • In caso di rifiuto, il contenuto viene scartato — non è mai stato pubblico

Modifiche che aggiungono media — ReviewablePost (pubblicazione immediata, revisione successiva)

  • La modifica entra in vigore immediatamente; la nuova versione (inclusa l’immagine) è istantaneamente visibile a tutti
  • Non c’è nessuna notifica “in revisione” per l’autore — e per le modifiche nel periodo di grazia non c’è nemmeno una revisione, quindi il contenuto originale non lascia traccia nell’interfaccia utente
  • In caso di rifiuto, il post viene eliminato (perform_reject_and_delete), recuperabile tramite la revisione precedente

La preoccupazione

Con l’approccio attuale, l’immagine problematica diventa visibile al pubblico prima che un moderatore possa intervenire, potenzialmente per un lungo periodo a seconda dei tempi di revisione. Questo sembra indebolire l’intero scopo di skip_review_media_groups — la descrizione dell’impostazione dice che i post contenenti media vengono “inviati allo staff per la revisione”, il che suggerisce che non dovrebbero essere pubblici nel frattempo.

Possibile miglioramento

  1. Mettere in coda il contenuto modificato invece di applicarlo. (Penso sia meglio) Quando una modifica introduce nuovi media, mantenere il post invariato, notificare all’autore che la nuova modifica è in attesa di revisione e applicare il contenuto modificato al post solo dopo che un moderatore lo ha approvato — scartarlo in caso di rifiuto. Questo riflette il comportamento dei nuovi post il più possibile. (Dal punto di vista dell’implementazione, sarebbe necessaria una variante revisionabile la cui approvazione esegua una revise sul post esistente invece di crearne uno nuovo.)

  2. Nascondere il post quando una modifica introduce nuovi media, in modo che solo l’autore lo veda con una notifica “in attesa di approvazione”, e utilizzare l’azione esistente perform_approve_and_unhide in caso di approvazione — le azioni ReviewablePost supportano già questa funzionalità.

5

Grazie per averlo testato. Concordo, l’intero sistema di revisione non è strutturato correttamente per gestire le “revisioni/modifiche in sospeso” :thinking:

Temo che si tratti di un compito molto più complesso e che richiederà più tempo per essere pianificato e realizzato.