Ich dachte, dass jede Bearbeitung eines Beitrags durch einen anderen Benutzer in der Tabelle user_actions protokolliert wird, aber mir ist gerade aufgefallen, dass dies nur sporadisch geschieht (nur bei manchen Benutzern, nur manchmal).
Ist das beabsichtigtes Verhalten oder gibt es eine weitere Bedingung, die ich nicht berücksichtige?
Es ist schwierig, eine schrittweise Anleitung zur Reproduktion dieses Problems zu geben, aber so habe ich es festgestellt:
Suche einen Beitrag mit einer Bearbeitungsmeldung:
Abfrage von user_actions für die angegebene acting_user_id (den Bearbeiter), die angegebene user_id (den Bearbeiteten) und die angegebene topic_id. In meinem Fall:
select * from user_actions ua
where ua.acting_user_id = 229
and ua.user_id = 259
and ua.target_topic_id = 1907;
Das erhalte ich:
Der Aktionstyp 2 bedeutet, dass der bearbeitete Benutzer ein LIKE vom Bearbeiter erhalten hat.
Der Aktionstyp 6 bedeutet, dass der Bearbeiter auf den bearbeiteten Benutzer geantwortet hat.
Ich kann beide Aktionen in der Benutzeroberfläche bestätigen, aber ich würde auch erwarten, einen action_type 11 zu finden, der die BEARBEITUNG (EDIT) anzeigt.
Neben der Sichtbarkeit der Bearbeitung in der UI kann ich ihre Existenz auch in der Tabelle post_revisions durch Abfrage mit der target_post_id bestätigen:
Mir ist gerade aufgefallen, dass ich entweder die Fälle, in denen eine Bearbeitungsmeldung erstellt wird, nicht vollständig verstehe, oder dass dies ein weit verbreitetes Problem ist, das ich unterschätzt habe.
Hauptannahmen
Wenn Benutzer A etwas bearbeitet, das Benutzer B geschrieben hat, passieren mehrere Dinge:
Eine neue Zeile wird in der Tabelle post_revisions hinzugefügt.
Eine neue Zeile wird in der Tabelle user_actions mit action_type = 11 hinzugefügt.
Unter /u/userB/notifications/edits kann Benutzer B sehen, dass Benutzer A eine neue Bearbeitung vorgenommen hat (dies hängt von user_actions ab).
Wenn Benutzer B auf das Stiftsymbol in seinem Beitrag klickt, kann er die tatsächliche Bearbeitung sehen, die Benutzer A vorgenommen hat (dies hängt von post_revisions ab).
Test
Wenn die oben genannten Annahmen korrekt sind, sollte diese Abfrage alle Zeilen in der Tabelle post_revisions für Beiträge anzeigen, die von Benutzer B (in diesem Fall ID 259) erstellt wurden und von einem beliebigen Benutzer (außer sich selbst oder dem Systembenutzer) bearbeitet wurden, zusammen mit den entsprechenden Zeilen in user_actions für action_type = 11.
with my_user_posts as (
select
p.id,
p.user_id
from
posts p
where
p.user_id = 259 -- eine Benutzer-ID auswählen
)
select
up.user_id as my_user_id,
ua.user_id as target_user_id,
pr.post_id,
ua.target_post_id,
pr.user_id as editor_user_id,
ua.acting_user_id,
ua.action_type,
pr.created_at as edit_created_at,
ua.created_at as action_created_at
from
post_revisions pr
inner join my_user_posts up on up.id = pr.post_id
and up.user_id != pr.user_id -- keine Selbstbearbeitungen
and pr.user_id != -1 -- keine Systembearbeitungen
left join user_actions ua on ua.target_post_id = pr.post_id
and ua.action_type = 11 -- nur BEARBEITEN-Aktionen
order by
pr.post_id,
pr.created_at;
Erwartete Ausgabe
Jede Zeile enthält sowohl post_revisions-Daten als auch user_actions-Daten.
Tatsächliche Ausgabe
Einige der post_revisions-Zeilen haben keine passenden user_actions-Daten. Daher kann der Benutzer die Revisionen sehen, indem er auf den Stift in jedem Beitrag klickt, wurde jedoch nicht über mehrere empfangene Bearbeitungen benachrichtigt.
Hinzufügen einer zusätzlichen Bearbeitung an einem alten Beitrag ohne user_action-Daten. Ergebnis: Die user_action-Daten erschienen ebenfalls nicht.
Erstellen eines gefälschten Benutzers, Kopieren des Inhalts vor der Bearbeitung eines Beitrags ohne user_action-Daten, Erstellen eines Beitrags damit und Anwenden derselben Bearbeitung, die von einem anderen Benutzer durchgeführt wurde. Ergebnis: Die user_action-Daten wurden korrekt angezeigt.
Wiederholen der oben genannten Verfahren, wenn der Benutzer aktiv oder offline ist. Ergebnis: Keine Änderung.
Wiederholen der oben genannten Verfahren unter Änderung der Bearbeitungsfrist. Ergebnis: Keine Änderung.
Schlussfolgerungen
Das Problem scheint nicht zu sein:
benutzerspezifisch. Es tritt bei praktisch jedem Benutzer auf.
verbindungspezifisch. Der Umstand, ob der Benutzer aktiv oder offline ist, ändert die Ausgabe nicht.
zeitspezifisch. Die Änderung der Bearbeitungsfrist hatte keine Auswirkung.
Das Problem scheint zu sein:
aktionsspezifisch. Ich habe keine Probleme bei der Benachrichtigung über andere Aktionen (LIKE, WAS_LIKED, RESPONSE, REPLY, MENTION oder QUOTE) festgestellt. Das einzige Problem betrifft BEARBEITEN-Aktionen.
beitragspezifisch. Es tritt nicht bei jedem Beitrag auf, sondern nur bei bestimmten (scheinbar zufälligen) Beiträgen.
Eine Möglichkeit ist, dass während der Erstellung bestimmter Beiträge etwas passiert, das verhindert, dass BEARBEITEN-user_actions gespeichert werden, aber ich habe keine Ahnung, was das sein könnte.
Es ist auch möglich, dass dies absichtlich so gestaltet ist und dass es bestimmte Bedingungen gibt, unter denen Benutzer nicht über Bearbeitungen benachrichtigt werden, aber ich habe dies nirgendwo dokumentiert gefunden.
Nächste Schritte
Wenn Sie einen Grund wissen, warum Bearbeitungsmeldungen nicht jedes Mal ausgelöst werden, wenn eine Bearbeitung erfolgt, lassen Sie es mich bitte wissen.
Wenn Sie eine eigene Discourse-Instanz haben, könnten Sie die oben genannte SQL-Abfrage auf einigen Ihrer Benutzer-IDs ausführen, um zu prüfen, ob Sie ebenfalls fehlende user_actions-Daten sehen, und mir Rückmeldung geben?
Ich möchte nur zu 100 % sicherstellen, dass dir die Bearbeitungsfristen klar sind, die auch dann gelten, wenn ein anderer Benutzer den Beitrag bearbeitet.
(Ja, wenn Benutzer A den Beitrag von Benutzer B bearbeitet, wird immer eine erzwungene Bearbeitungsrevision erstellt. Das bedeutet jedoch nicht, dass bei sechs Bearbeitungen durch Benutzer A innerhalb von 60 Sekunden sechs Revisionen und sechs Benachrichtigungen erstellt werden. Es wird nur eine Revision und eine Benachrichtigung erstellt, wie du im obigen Screenshot sehen kannst.)
Liegen diese Bearbeitungen jeweils mehr als 5 Minuten auseinander?
Danke für deinen Kommentar, Jeff. Ich kann bestätigen, dass diese Änderungen tatsächlich mehr als 5 Minuten auseinanderliegen. Aber selbst wenn sie es nicht wären: Solange eine einzelne post_revision erstellt wird, sollte es doch IMMER eine begleitende EDIT user_action geben, oder?
Als Randbemerkung: Ich habe auch versucht, die Bearbeitungsfrist auf 0 zu setzen. Dabei werden für jede Änderung zwei identische post_revisions erstellt. Ich weiß nicht, ob das beabsichtigt ist oder ob es sich um einen unrelated Bug handelt.
Könnte jemand die oben genannte Abfrage auf seiner Discourse-Seite ausführen, um zu prüfen, ob er ebenfalls post_revisions ohne entsprechende user_actions vom Typ 11 erhält?
Nach Durchsicht unseres Codes glaube ich, dass du nur den user_action-Typ 11 erhältst, wenn du einen Beitrag eines anderen bearbeitest oder eine Benachrichtigung bezüglich dieser Bearbeitung auf andere Weise auslösen.
Danke, Sam. Das habe ich erwartet, aber es ist nicht das, was ich gefunden habe (zumindest auf meiner Seite). Wie du an den Ergebnissen meiner Abfrage sehen kannst, gibt es in einigen Fällen, in denen Benutzer A einen Beitrag von Benutzer B bearbeitet (was eine Zeile in post_revisions hinzufügt), keine entsprechende Zeile in user_actions (mit action_type 11). Das ist es, was ich nicht verstehe.
Ich habe eine Abfrage geschrieben, um dies zu testen. Wenn Sie sie auf Ihrer Seite ausführen (mit anderen Benutzer-IDs), sollten Sie ebenfalls Lücken sehen.
Ich kann dir ein konkretes Beispiel auf einer von dir gehosteten Instanz geben.
Dieser Beitrag (ID 1067), erstellt von Benutzer 3 am 2019-08-03 19:22 UTC, wurde wenige Minuten nach seiner Erstellung von mir (Benutzer 2) bearbeitet.
Es wurde jedoch keine user_action vom Typ 11 erstellt (im Gegensatz zu den anderen zwei Bearbeitungen, die dieser Benutzer an diesem Tag an den Beiträgen 1001 und 1003 erhielt).
Du kannst es deutlicher sehen, wenn du diese Abfrage ausführst:
with my_user_posts as (
select
p.id,
p.user_id
from
posts p
where
p.user_id = 3 -- eine Benutzer-ID auswählen
)
select
up.user_id as my_user_id,
ua.user_id as target_user_id,
pr.post_id,
ua.target_post_id,
pr.user_id as editor_user_id,
ua.acting_user_id,
ua.action_type,
pr.created_at as edit_created_at,
ua.created_at as action_created_at
from
post_revisions pr
inner join my_user_posts up on up.id = pr.post_id
and up.user_id != pr.user_id -- keine Selbstbearbeitungen
and pr.user_id != -1 -- keine Systembearbeitungen
left join user_actions ua on ua.target_post_id = pr.post_id
and ua.action_type = 11 -- nur EDIT-Aktionen
WHERE
pr.created_at between '2019-08-03' und '2019-08-04'
order by
pr.post_id,
pr.created_at
Ich habe einige Zahlen geprüft, und je nach Datum haben zwischen 7 % und 25 % der Nicht-Selbst-Post-Revisions keine entsprechende user_action.
Und ich habe die Implementierung mit diesem Feature verbessert:
Es gab einen Randfall, bei dem wir nicht benachrichtigt wurden, wenn ein Nutzer einen Beitrag eines anderen Nutzers liked und ihn anschließend bearbeitet.
Zusätzlich habe ich eine Sicherheitsvorkehrung eingefügt, die sicherstellt, dass wir einmal täglich uneingeschränkt benachrichtigen, selbst wenn es sich um denselben Bearbeiter handelt (wiederholte Bearbeitungsnachrichten desselben Bearbeiters werden für 1 Tag unterdrückt). Dies ist derzeit nicht konfigurierbar.
