L’endpoint /activity/pending liste actuellement tous les sujets/messages en attente, mais seuls les messages peuvent être supprimés en accédant au sujet et en cliquant sur le bouton « Supprimer » sous la boîte « en attente d’approbation ». Les utilisateurs ne peuvent pas supprimer eux-mêmes leurs sujets en attente sans contacter le personnel.
Ce commit ajoute un bouton « Supprimer » similaire directement à la page /activity/pending, permettant ainsi aux utilisateurs de supprimer eux-mêmes leurs sujets en attente, en suivant une logique similaire à celle de la suppression des messages en attente auparavant.
Pourquoi le sujet supprimé reste-t-il dans la file d’attente, comme sur votre capture d’écran ? Ne devrait-il pas simplement… l’annuler ?
La logique est conservée identique à celle d’un message, c’est-à-dire que lorsqu’un message est supprimé par un utilisateur avant qu’une action ne soit entreprise par le personnel, il reste également dans la file d’attente comme ci-dessus (Le statut est “Sujet ou message supprimé” donc cela n’affectera pas l’état en attente).
De plus, je pense que cela a du sens, si un utilisateur supprime accidentellement un sujet en attente, il peut demander au personnel de le récupérer.
Cela me semblerait logique d’avoir une invite de confirmation au lieu de rendre une action destructive en un seul clic.
D’accord, j’ajouterai une fenêtre contextuelle pour que les utilisateurs puissent confirmer.
Dans quels cas similaires Discourse affiche-t-il une invite de confirmation ?
Lorsque je supprime un message ou un sujet que j’ai créé, il n’y a pas non plus d’étape de confirmation. Dans mes listes de signets, « supprimer le signet » le supprime également sans demander de confirmation.
Je comprends qu’il faille demander une confirmation lorsque des informations sont perdues de manière permanente, comme lorsque vous abandonnez un brouillon, mais je ne pense pas qu’il y en ait trop, car sinon, les éléments importants sembleraient moins importants. (La discussion ici pourrait également être intéressante dans ce contexte.)
Tant qu’un membre du personnel peut restaurer le sujet, je ne pense pas que celui-ci nécessite une confirmation.
Wow, c’est bizarre. Je viens d’essayer de supprimer un sujet et cela ne m’a pas prévenu du tout, même en tant qu’utilisateur standard. Maintenant que je l’ai fait, cela a du sens, mais peut-être que je suis tellement habitué à l’UX d’administrateur que j’ai oublié qu’il ne vous demande pas confirmation en tant qu’utilisateur, car je pensais honnêtement que c’était le cas. Cependant, cela se produit bien dans la fenêtre contextuelle de réponse, ce qui me semble être à peu près la même chose que cela.
En fin de compte, je pense que c’est une question de préférence et je préfère simplement avoir une petite vérification pour éviter les clics/appuis accidentels.
Mais dans ce cas, le contenu du message serait perdu autrement, ce qui n’est pas le cas dans les autres exemples. J’ai l’impression que Discourse a été conçu avec l’idée que l’utilisateur sait ce qu’il fait et n’affiche un avertissement que si les conséquences sont graves.
C’est exactement ça, et ce n’est pas nécessairement spécifique à Discourse, mais c’est simplement une bonne pratique UX générale : une modale/une boîte de dialogue est un élément qui crée de la friction dans le flux utilisateur, et ne devrait être utilisée que lorsqu’une action est vraiment destructive. Tout ce qui est facilement récupérable ou annulable peut se passer sans elle.
Je suis tout à fait d’accord avec cela, le problème est qu’au moins avec cette fonctionnalité, il semble qu’il ne puisse pas être annulé sans l’intervention du personnel. Si j’étais un utilisateur et que je faisais une erreur en cliquant sur le bouton « révoquer le message », je préférerais qu’une fenêtre modale m’arrête plutôt que de devoir demander au personnel (qui pourrait ne pas le voir) d’approuver le message de toute façon.
La méthode originale pour supprimer un message en attente consistait à aller sur le sujet, à faire défiler jusqu’en bas, puis à cliquer sur le bouton « Supprimer ». Ce processus est suffisamment complexe pour éviter les actions involontaires.
Mais comme la liste des messages en attente est affichée sous forme de tableau, quelqu’un pourrait accidentellement cliquer sur le bouton de suppression d’une mauvaise ligne, puis devoir contacter un membre du staff pour la récupération, ce qui pourrait prendre du temps et des efforts. Du point de vue d’un utilisateur, je pense que ce n’est pas si « facile », donc peut-être qu’une boîte de dialogue de confirmation est nécessaire ici.
P.S. Mon commit initial visait à conserver la même logique que celle de la suppression d’un message en attente auparavant, mais je pense qu’il serait nécessaire d’avertir à nouveau l’utilisateur ici.
