Je pensais que chaque fois qu’un utilisateur modifie le message d’un autre, cette action serait enregistrée dans la table user_actions, mais je viens de réaliser que cela ne se produit que sporadiquement (uniquement pour certains utilisateurs, à certains moments).
Est-ce le comportement attendu ou y a-t-il une autre condition que je ne prends pas en compte ?
Il est difficile de fournir une procédure étape par étape pour reproduire ce problème, mais voici comment je l’ai détecté :
Trouver un message avec une notification d’édition :
Interroger la table user_actions pour le acting_user_id donné (l’éditeur), le user_id donné (l’utilisateur modifié) et le topic_id donné. Dans mon cas :
select * from user_actions ua
where ua.acting_user_id = 229
and ua.user_id = 259
and ua.target_topic_id = 1907;
Voici ce que j’obtiens :
Le type d’action 2 signifie que l’utilisateur modifié a reçu un LIKE de la part de l’éditeur.
Le type d’action 6 signifie que l’éditeur a répondu à l’utilisateur modifié.
Je peux confirmer ces deux actions dans l’interface utilisateur, mais je m’attendrais également à trouver un action_type 11 indiquant l’ÉDITION.
Outre la visibilité de l’édition dans l’interface, je peux également confirmer son existence dans la table post_revisions en interrogeant via le target_post_id :
Je viens de réaliser que soit je ne comprends pas complètement les cas où une notification d’édition est créée, soit c’est un problème beaucoup plus répandu que je ne le pensais.
Hypothèses principales
Si l’utilisateur A modifie ce que l’utilisateur B a écrit, plusieurs choses se produisent :
Une nouvelle ligne est ajoutée à la table post_revisions.
Une nouvelle ligne est ajoutée à la table user_actions avec action_type = 11.
En accédant à /u/userB/notifications/edits, l’utilisateur B pourra voir qu’une nouvelle édition a été effectuée par l’utilisateur A (cela dépend de user_actions).
En cliquant sur l’icône de crayon dans son message, l’utilisateur B pourra voir la modification réelle effectuée par l’utilisateur A (cela dépend de post_revisions).
Test
Si les hypothèses ci-dessus sont correctes, cette requête devrait afficher toutes les lignes de la table post_revisions pour les messages créés par l’utilisateur B (dans ce cas, l’identifiant 259) qui ont été modifiés par n’importe quel utilisateur (autre que lui-même ou l’utilisateur système), ainsi que les lignes correspondantes dans user_actions pour action_type = 11.
with my_user_posts as (
select
p.id,
p.user_id
from
posts p
where
p.user_id = 259 -- choisissez un identifiant d'utilisateur
)
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 -- pas d'auto-modifications
and pr.user_id != -1 -- pas de modifications système
left join user_actions ua on ua.target_post_id = pr.post_id
and ua.action_type = 11 -- uniquement les actions ÉDITION
order by
pr.post_id,
pr.created_at;
Résultat attendu
Chaque ligne contient à la fois les données de post_revisions et les données de user_actions.
Résultat réel
Certaines lignes de post_revisions ne correspondent à aucune donnée dans user_actions. Par conséquent, l’utilisateur peut voir les révisions en cliquant sur le crayon dans chaque message, mais n’a pas été informé de recevoir plusieurs modifications.
Ajouter une modification supplémentaire à un ancien message sans données user_action. Résultat : les données user_action n’apparaissent toujours pas.
Créer un faux utilisateur, copier le contenu avant modification d’un message sans données user_action, créer un nouveau message avec ce contenu et appliquer la même modification qu’avec un autre utilisateur. Résultat : les données user_action apparaissent correctement.
Répéter les procédures ci-dessus lorsque l’utilisateur est actif ou hors ligne. Résultat : aucune modification.
Répéter les procédures ci-dessus en modifiant la période de grâce pour les modifications. Résultat : aucune modification.
Conclusions
Le problème ne semble pas être :
spécifique à l’utilisateur. Il survient pratiquement pour chaque utilisateur.
spécifique à la connexion. Le fait que l’utilisateur soit actif ou hors ligne ne modifie pas le résultat.
spécifique au temps. Modifier la période de grâce pour les modifications n’a eu aucun effet.
Le problème semble être :
spécifique à l’action. Je n’ai constaté aucun problème de notification pour les autres actions (LIKE, WAS_LIKED, RESPONSE, REPLY, MENTION ou QUOTE). Le seul problème concerne les actions ÉDITION.
spécifique au message. Cela ne se produit pas pour tous les messages, seulement pour certains (apparemment de manière aléatoire).
Une possibilité est que quelque chose se produise lors de la création de certains messages et empêche l’enregistrement des actions user_actions de type ÉDITION, mais je ne sais pas ce que cela pourrait être.
Il est également possible que cela soit prévu par conception et qu’il existe des conditions spécifiques dans lesquelles les utilisateurs ne sont pas informés des modifications, mais je n’ai trouvé aucune documentation à ce sujet.
Étapes suivantes
Si vous connaissez une raison pour laquelle les notifications de modification ne sont pas déclenchées à chaque modification, veuillez me le faire savoir.
Si vous disposez de votre propre instance Discourse, pourriez-vous exécuter la requête SQL ci-dessus sur certains de vos identifiants d’utilisateur pour vérifier si vous observez également des données manquantes dans user_actions et me faire un retour ?
Je veux juste être certain à 100 % que vous avez bien compris les délais de grâce pour les modifications, qui s’appliquent même si c’est un autre utilisateur qui modifie le message.
(Oui, si l’utilisateur A modifie le message de l’utilisateur B, une révision de modification forcée est toujours créée, mais cela ne signifie pas que si l’utilisateur A modifie le message de l’utilisateur B 6 fois en 60 secondes, il y aura 6 révisions et 6 notifications générées. Il n’y aura qu’une seule révision et une seule notification, comme vous pouvez le voir sur la capture d’écran ci-dessus.)
Chacune de ces modifications est-elle espacée de plus de 5 minutes ?
Merci pour ton commentaire, Jeff. Je peux confirmer que oui, ces modifications sont espacées de plus de 5 minutes. Mais même si ce n’était pas le cas, tant qu’une seule post_revision est créée, ne devrait-il pas toujours y avoir un EDIT user_action correspondant ?
En passant, j’ai aussi essayé de définir la période de grâce pour l’édition à 0, et dans ce cas, deux post_revisions identiques sont créées pour chaque modification. Je ne sais pas si c’est intentionnel ou s’il s’agit d’un bug sans rapport.
Quelqu’un pourrait-il exécuter la requête ci-dessus sur son site Discourse pour vérifier s’il obtient également des post_revisions sans user_actions correspondantes de type 11 ?
En fouillant dans notre code, je pense que vous n’obtenez le type d’action utilisateur 11 que si vous modifiez le message de quelqu’un d’autre ou déclenchez une notification concernant cette modification d’une autre manière.
Merci, Sam. C’est ce à quoi je m’attendais, mais ce n’est pas ce que j’ai constaté (sur mon site, du moins). Comme vous pouvez le voir dans les résultats de ma requête, dans certains cas, l’utilisateur A modifie un message de l’utilisateur B (ce qui ajoute une ligne dans post_revisions), mais il n’existe aucune ligne correspondante dans user_actions (avec action_type 11). C’est ce que je ne comprends pas.
Cela se produit de manière continue et sporadique depuis que j’ai créé mon site. Comme je l’ai mentionné plus haut, je n’ai pas réussi à identifier le motif.
Si vous avez besoin d’un extrait de données ou d’autres informations, je suis ravi de vous aider.
J’ai écrit une requête pour tester cela. Si vous l’exécutez sur votre site (avec différents identifiants d’utilisateur), vous devriez également constater des lacunes.
Je peux vous donner un exemple concret dans une instance hébergée par vous.
Cet article (id 1067), créé par l’utilisateur 3 le 2019-08-03 à 19:22 UTC, a été édité par moi-même (utilisateur 2) quelques minutes après sa création.
Cependant, aucune user_action de type 11 n’a été créée (contrairement aux deux autres modifications que cet utilisateur a reçues ce jour-là sur les articles 1001 et 1003) !
Vous pouvez le voir plus clairement en exécutant cette requête :
with my_user_posts as (
select
p.id,
p.user_id
from
posts p
where
p.user_id = 3 -- choisissez un identifiant d'utilisateur
)
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 -- pas d'auto-éditions
and pr.user_id != -1 -- pas d'édits système
left join user_actions ua on ua.target_post_id = pr.post_id
and ua.action_type = 11 -- uniquement les actions de type EDIT
WHERE
pr.created_at between '2019-08-03' et '2019-08-04'
order by
pr.post_id,
pr.created_at
J’ai effectué quelques calculs et, selon la date, entre 7 % et 25 % des post_revisions non auto-éditées ne possèdent pas de user_action correspondante.
J’ai amélioré l’implémentation avec cette fonctionnalité :
Nous avions un cas limite où, lorsqu’un utilisateur aimait un message d’un autre utilisateur puis le modifiait ensuite, nous ne notifions pas la modification.
De plus, j’ai ajouté un mécanisme de sécurité garantissant que nous notifions inconditionnellement une fois par jour, même s’il s’agit du même éditeur. (Nous supprimons les notifications de modification répétées du même éditeur pendant 1 jour). Cette option n’est pas configurable pour le moment.
