Le titre a déjà été utilisé (dans une catégorie sécurisée)

La vérification des titres de sujets en double ne prend pas en compte le fait que le titre original appartient à un sujet dans une catégorie privée, et elle devrait probablement le faire.

4 « J'aime »

Le fait qu’un sujet ait des permissions (via la catégorie) ou non ne le rend pas éligible à ne pas être un titre de sujet en double.

S’il s’agit d’un message privé, c’est une autre affaire.

Je dirais qu’il devrait. Quelle est la logique derrière cette règle ?

En fait, il s’agit d’une duplication de slug ou de titre. Cela a été conçu ainsi dès sa création en 2013.

C’est la logique, mais ce n’est pas vraiment un raisonnement solide à mon avis… Que cherchons-nous à corriger ou à éviter avec cette règle ?

Pourquoi est-ce soudainement un problème alors que cela dure depuis 2013 ? :thinking:

Je souhaiterais voir 3 à 4 signalements de problèmes de la part des clients avant de procéder. Je n’agis pas sur la base d’un seul exemple.

Parce que cela n’a aucun sens pour un utilisateur qui ne peut pas voir les autres doublons. Ils sont obligés d’inventer un titre simplement pour éviter une règle.

C’est compréhensible que nous n’agissions pas pour le moment, mais cela doit tout de même être enregistré (au cas où deux autres arrivent).

5 « J'aime »

Eh bien, je dirais que c’est en quelque sorte correct, de la même manière que si votre mot de passe est un doublon, vous ne devriez vraiment pas pouvoir l’utiliser, même si d’autres personnes ont ce même mot de passe.

La confusion potentielle entre

http://discourse.example.com/t/upgrading-discourse/8922
http://discourse.example.com/t/upgrading-discourse/7451

.. est considérable.

L’un a des implications en matière de sécurité et l’autre est tout simplement déroutant…

Mais tout va bien. Laissons cela ici pour la postérité, aucune action n’est requise pour le moment.

2 « J'aime »

Le seul endroit où la duplication des slugs est vraiment importante, c’est pour le référencement. Si l’un se trouve dans une catégorie sécurisée et que nous parlons toujours du sujet moins sécurisé créé en second, alors cela ne devrait certainement pas être un facteur, n’est-ce pas ?

Bonjour, ici Posterity. Nous créons plusieurs catégories privées, chacune contenant les mêmes sujets, mais nous sommes confrontés à ce problème. Existe-t-il une solution pour le contourner ?

Activez le support des titres en double dans les paramètres du site si nécessaire.

4 « J'aime »

Veuillez envisager d’afficher l’ID du sujet en conflit dans le message d’erreur.

Lorsqu’une mise à jour de sujet échoue lors de la vérification d’unicité du titre (has_already_been_used), l’erreur ne donne aucune indication sur le sujet qui cause le conflit. Cela est particulièrement problématique car la vérification s’exécute contre Topic.listable_topics, ce qui signifie que le sujet en conflit peut être non répertorié. Il n’existe pas de lien direct entre l’erreur et sa cause ; le personnel doit savoir rechercher avec status:unlisted et deviner les variations de catégorie ou de formulation.

Pour les utilisateurs du personnel/admin, inclure l’ID de ce sujet (ou l’URL d’administration) dans la réponse d’erreur transformerait une enquête en plusieurs étapes en une correction en un clic, par exemple :

{“errors”: [“Le titre a déjà été utilisé”], “conflicting_topic_id”: 12345}

C’est un équilibre assez délicat, donc je ne suis même pas sûr que ce changement soit « correct »

L’idée est que nous bloquerons uniquement si vous pouvez voir l’autre sujet. Si c’est le cas, nous fournirons même un lien vers le sujet afin que vous puissiez l’afficher en un seul clic.

1 « J'aime »

Le lien est l’élément principal dont les utilisateurs ont réellement besoin, donc cela me semble être une victoire absolue ! Sans parler du fait qu’utiliser un seul enum semble être un meilleur choix que deux booléens pour une logique aussi étroitement liée. Merci de partager cela.

1 « J'aime »