La prima volta che ho notato una seconda notifica per la stessa risposta senza che venissero aggiunti link, citazioni o menzioni nella modifica è stato dopo la modifica su Topics from some categories do not appear on /latest - #36 by JammyDodger. Questo caso è leggermente diverso dai miei passaggi per la riproduzione di seguito, ma penso che il problema di fondo sia lo stesso.
Il secondo post in cui è successo è stato su Messages section for sidebar - #13 by nathank. Era simile: la modifica non ha aggiunto nulla che avrebbe dovuto generare una notifica - le citazioni erano già presenti prima - eppure sono stato nuovamente notificato.
Ecco i passaggi per riprodurre che ho trovato e che hanno funzionato [1]
Hai bisogno di 3 utenti: OP, notifiedUser, spammer
OP crea un argomento
notifiedUser risponde
OP risponde al post di notified user notifiedUser viene notificato della risposta (previsto)
spammer risponde al post di notifiedUser. La risposta contiene un link a un altro post di notifiedUser e una citazione del post a cui si risponde. (opzionale: puoi anche @menzionare notifiedUser) notifiedUser viene notificato della risposta (previsto) [Nel caso in cui tu abbia aggiunto una @menzione, la notifica riguarda la @menzione (previsto)]
notifiedUser legge le nuove risposte per contrassegnare le notifiche come lette e naviga altrove in modo da non perdere una notifica.
spammer modifica la risposta e corregge un errore di battitura (o aggiunge edit1) notifiedUser viene notificato di essere stato citato (inaspettato, era già stato notificato di questa risposta e la citazione era già presente, non c’è bisogno di dirglielo)
spammer modifica nuovamente la risposta per correggere un altro errore di battitura (o aggiunge edit2) notifiedUser viene notificato di essere stato linkato (inaspettato, era già stato notificato di questa risposta e il link era già presente, non c’è bisogno di dirglielo)
Il video mostra solo gli ultimi passaggi 5-7. Spammer a sinistra, notifiedUser a destra
almeno la maggior parte delle volte, a volte anche l’aggiunta di una @menzione nella modifica non attiva una nuova notifica ↩︎
Change lines 589-599 from:
# linked, quoted, mentioned, chat_quoted may be suppressed if you already have a reply notification
if [
Notification.types[:quoted],
Notification.types[:linked],
Notification.types[:mentioned],
Notification.types[:chat_quoted],
].include?(type)
if existing_notifications.find { |n| n.notification_type == Notification.types[:replied] }
return
end
end
To:
# linked, quoted, mentioned, chat_quoted may be suppressed if you already have any notification about this
post
if [
Notification.types[:quoted],
Notification.types[:linked],
Notification.types[:mentioned],
Notification.types[:chat_quoted],
].include?(type)
return if existing_notifications.any?
end
Questo funzionerà, ma sono un po’ preoccupato perché ci sono altre notifiche che potrebbero passare inosservate qui. (ad esempio le notifiche dei plugin che potremmo voler sopprimere)
@lindsey qui c’è una domanda di prodotto: quando dovremmo sopprimere una notifica?
Suppongo che la piccola correzione sia un passo avanti?
Non ne sono sicuro. Non è una notifica di risposta nel mio video? Eppure, c’è ancora una notifica sulla citazione e sul link in seguito. Quindi, estendere ciò ad altri tipi di notifica potrebbe non essere d’aiuto qui. Ma forse copre altri casi limite.
Mi chiedo se il problema nel mio caso di riproduzione sia la notifica “2 risposte”. Questo interrompe il controllo delle notifiche esistenti per quella risposta quando la risposta viene modificata?
In generale, mi aspetterei nessuna notifica aggiuntiva a causa di una modifica se tutti i trigger fossero già presenti nel post quando l’ho letto prima. La correzione di un refuso non correlato a menzioni/link/citazioni non dovrebbe generare una nuova notifica.
Penso che, nel caso in cui un trigger venga sostituito, preferirei che la notifica esistente e non letta venisse modificata (o sostituita) piuttosto che riceverne una seconda. La rimozione della @menzione nel post di un utente per evitare rumore non dovrebbe comportare una seconda notifica sulla citazione. Mi aspetterei che la notifica sulla @menzione scompaia.
Penso che l’unico caso in cui vorrei una nuova notifica sia se una modifica aggiunge un tipo di notifica più importante. Quindi, quando qualcuno ha linkato il mio post e successivamente aggiunge una modifica che mi @menziona, ha senso farmelo sapere perché non sembra più parlare di qualcosa che ho scritto, ma direttamente a me. Poiché una modifica non fa più salire l’argomento, le @menzioni potrebbero essere un modo utile per avvisare gli utenti delle modifiche.
Penso che Moin descriva l’ideale dal punto di vista dell’utente, ma penso che avremmo difficoltà a gestire bene questa parte:
Forse potremmo gestirlo per le notifiche in-app, ma non possiamo annullare l’invio di notifiche push o e-mail. (In generale sono restio ad aggiungere ulteriore complessità alle notifiche, quindi anche se alcuni potrebbero essere d’accordo sul fatto che la notifica in-app e quella e-mail/push siano diverse, preferirei che rinunciassimo a questo.)
Sono d’accordo con questo, però:
Se un post deve notificare un utente (ad esempio, l’autore del post cita l’Utente A), notificare l’utente/gli utenti interessato/i (ad esempio, l’Utente A riceve una notifica di essere stato citato).
Se una modifica a quel post non cambia chi dovrebbe essere notificato o perché (ad esempio, l’autore del post modifica un refuso), non notificare nessuno.
Se una modifica a quel post cambia chi dovrebbe essere notificato (ad esempio, l’autore del post menziona l’Utente B) o perché (ad esempio, l’autore del post menziona l’Utente A), notificare l’utente/gli utenti interessato/i (ad esempio, l’Utente B riceve una notifica di menzione, l’Utente A riceve una notifica di menzione).
Sì, chiuderò la mia PR qui e la definirò una funzionalità.
In particolare, c’è una lacuna qui:
@Moin vorrebbe… che la vecchia notifica fosse aggiornata
@lindsey vorrebbe… nuove notifiche per le nuove informazioni modificate nel post
L’allineamento completo qui richiede un tracciamento piuttosto complesso… Sto valutando l’entità della modifica, ma onestamente, per ora non fare nulla è probabilmente la cosa più semplice, perché la modifica finirà per essere molto fragile.
Estrarre quali menzioni sono nuove e quali sono vecchie è qualcosa che richiederà o un parser (non analizziamo a quel punto) o espressioni regolari fragili.
Sposto questo a funzionalità @Moin e chiudo la mia PR per ora.
Soprattutto, non voglio ricevere un’altra notifica se non è cambiato nulla nel post che causerebbe una notifica. Correggere un refuso non dovrebbe notificarmi se sono già stato avvisato solo perché 2 notifiche sullo stesso argomento sono state raggruppate prima. E non me ne sono mai accorto per anni finché non è successo a dicembre.
Ho chiesto a ChatGPT di scrivere un riassunto di ciò che mi ha detto su questo problema, quando ho cercato di trovare i passaggi per la riproduzione basandomi sul codice
Riassunto: Perché le notifiche duplicate sono normalmente prevenute e perché fallisce quiIA
Problema principale
La prevenzione dei duplicati si basa sulla ricerca di una notifica di risposta ancora collegata al post modificato, ma le notifiche di risposta sono raggruppate, eliminate o riassociate a un post diverso.
Di conseguenza, la soppressione al momento della modifica non può rilevare in modo affidabile che l’utente è già stato avvisato della risposta.
Le notifiche duplicate sono prevenute in PostAlerter tramite:
Tracciamento degli utenti già avvisati durante la creazione del post
notified = []
Soppressione dei trigger secondari se esiste una notifica di risposta
if [:quoted, :linked, :mentioned, :chat_quoted].include?(type)
return if existing_notifications.find { |n|
n.notification_type == Notification.types[:replied]
}
end
Questo serve per evitare di notificare un utente due volte per lo stesso post.
Raggruppamento delle notifiche di risposta
Le notifiche di risposta (:replied) sono raggruppate per argomento:
in modo che la notifica non rappresenti più il post che l’ha innescata originariamente. Di conseguenza, la logica di soppressione che si basa sulla corrispondenza di post_number non può rilevare in modo affidabile le notifiche precedenti per i post modificati.
Perché questo fallisce nel caso di riproduzione
Nel caso di riproduzione:
L’utente viene avvisato della risposta inizialmente
Quando esistono più risposte, le notifiche di risposta vengono raggruppate
La notifica raggruppata:
potrebbe non esistere più per il post modificato, o
esiste con un post_number diverso
Alla modifica:
la logica di risposta non viene eseguita (new_record == false)
il controllo di soppressione cerca solo una notifica :replied con ambito di post
non ne viene trovata nessuna → la soppressione fallisce
Il rilevamento di citazioni/link viene eseguito di nuovo e crea nuove notifiche
Dal punto di vista dell’utente:
“Sono già stato avvisato di questa risposta.”
Dal punto di vista del codice:
“Non esiste una notifica esistente per questo post.”
Quando creo un argomento menzionando il mio utente di prova in una categoria pubblica e lo sposto in una categoria privata dopo qualche minuto, anche la notifica viene rimossa dall’interfaccia, anche se hanno ricevuto un’email per la @menzione.
Quindi, le notifiche in-app che vengono eliminate, anche se è stata inviata un’email, esistono già.
Sembra ancora un bug che quando mcwumbly aggiunge un tag al suo argomento, ricevo una nuova notifica che il mio post è stato linkato. Il link era già presente quando ha pubblicato l’argomento e sono stato avvisato della citazione. Nulla è cambiato a parte il tag. Allora perché ci si aspetta che una modifica attivi una seconda notifica?
Oltre ai passaggi nel primo post, succede anche con questi passaggi:
notifiedUser crea un argomento
lo spammer risponde come argomento linkato. Il post contiene un link per impostazione predefinita, quindi devi solo aggiungere la @menzione e la citazione.
→ notifiedUser viene avvisato della @menzione (previsto) e legge l’argomento
lo spammer aggiunge un tag all’argomento
→ notifiedUser viene avvisato di essere stato citato nel post (inaspettato, era già stato avvisato e nulla è cambiato)
lo spammer modifica il titolo dell’argomento
→ notifiedUser viene avvisato di essere stato linkato nel post (inaspettato, è già stato avvisato prima e il post non è ancora cambiato)
