Je propose l'ajout d'une commande de type ContextMenu User pour la commande de Stats qui permettrais d'avoir les statistiques d'un utilisateur précis en faisant simplement un clic droit sur l'utilisateur en question. Le message qui en résultera serais éphémère pour que cette commande puisse être utilisée dans n'importe quel salon sans problème.

La version 16.14 de node n'est plus dispo sur le docker hub, donc ce serait pas mal de migrer sur la version 16.15. (À l'heure actuelle le script dev:build fail à cause de ça)

Edit: my bad le soucis venais de moi, desolé pour le désagrément

Pourquoi ne pas mettre une permission par default au rôle parrain uniquement ?

Pourquoi ne pas relancer les stickys message quand il y'a une blague d'ajouté cela permettrais d'avoir toujours le bon nombre de blagues d'indiqué ?
Ce n'est pas grand chose mais sa serais toujours un plus je pense 🤷‍♂️

Personnellement, je trouve ça assez relou de partager les ID des blagues doublons pour que Draft les supprime. C'est long, pas hyper pratique, et ça doit sûrement prendre sur son temps.

Donc je me dis, en ajout de la refonte du système de suggestions, pourquoi pas ajouter un /report ? Avec un nouveau salon et tout et tout, ça fonctionnerait pareil que les blagues / corrections mais ça ne rapporterait que 5 points, et le salon serait réservé au parrains (ça ne sert à rien aux membres de connaître les doublons).

Les membres auront juste à faire un /report <ID1> <ID2> pour qu'un EMBED contenant les deux blagues soit envoyé dans un salon #doublons. Vous en pensez quoi ?

Je propose de désencombré ces salons en supprimant les messages au moment ou celle ci sont migré ou non migré sa ferais beaucoup moins de message dans le salon est de toute façon il y'a le salon logs qui les regroupe tous ..
Cela permettrais au membre de pas remonter 300 blagues migré ou pas pour ajouté un emoji a une blague et permettrais d'avoir des salons beaucoup plus propres 😄

Idée de @achille-bsc
Changer le système de messages collants ( actuellement un timeout) pour un évènement messageCreate
Cela permettra une optimisation du système ainsi qu'une meilleur fluidité pour le message collant
PR #352

Je propose que pour la commandes /stats les points sont ceux des blagues approuvées et non pas les blagues en général.

Il faudrait passer tous les messages des actions pour valider une suggestion/correction en ephemeral

Actuellement, tous les messages de validation pour dire que la correction a été validé ou qu'une blague a été ajoutée à l'API ne sont pas ephemeral et il faut passer derrière pour les supprimer manuellement

Hello 👋 !
Je pensais que ce serait peut-être plus cohérent de mettre le message de confirmation lors de la proposition d'une correction en éphémère, comme pour le message de suggestion. Ou alors passer celui de suggestion en message non-éphémère... 🤷 comme vous préférez 🙃

Ajouter le lien de correction quand la blague est en cours de correction pour voir la proposition faite.

Nous pourrions réfléchir à un système pour auto-publier les blagues sur GitHub chaque dimanche (par exemple) s'il y en a de nouvelles, ça permettrait de les synchroniser automatiquement.

Quelques amélioration:

• Le titre passe en nom de l'auteur + Icon du bot
• Un nouveau titre qui changera de typo dynamiquement
• Fix du footer qui s'afficher pas si il y avais seulement une page
• Si il y a plus de deux page l'icone du bot s'affiche dans le footer

Pour le nouveau système de statistiques, il est prévu de donner plus ou moins de points en fonction de l'appréciation de la blague. Chaque action donne un certain nombre de points.

Système de points

* Points pour l'approbation d'une blague pour un parrain.
** Les votes via réactions ne seront pas comptabilisés pour les parrains.

Points bonus :

Ajouter la possibilité de pouvoir ignorer certains types de blagues en tant que parrain pour éviter notamment d'être mentionné pour l'approbation des corrections/suggestions des blagues dont le type est ignoré.
On peut également faire en sorte que lorsque l'on appuie sur le bouton "Mes propositions", les blagues ignorés soient affichée, mais qu'elles soient barrées.

La configuration de cela se ferrait via une commande Slash, par exemple /ignore avec comme paramètre les types de blagues actuellement disponible sur Blagues API et qui serait réservée aux parrains leur permettant de désactiver ou réactiver un type de blague à n'importe quel moment.

Je propose de séparer la commande en deux commands :

• 1 = leaderbord => Affiche les toutes les statistiques
• 2 = stats => Affiche les stats de l'utilisateur/d'un utilisateur

Ajouter un bouton sous le message de reminder pour que celui qui clique puisse voir en message éphémère la liste des Suggestions et Corrections sur lesquelles il peut interagir (Approuver, Désapprouver)

• Passez la commande en sous commandes ( random, type | aléatoire, type)
• Renvoyer joke au message en fonction du nom de la sous commande

J'ai vu quelques soucis de grammaire ici et là, je les report ici.

Quand on envoie une suggestion, "La blague à été envoyée". Il n'y a pas d'accent sur le "a".
Sur l'EMBED des #suggestions et #corrections, "Elles sont toutes issues de ce salon proposées par la communauté.". Je trouve ça assez facile à mal interpréter. Il faudrait ajouter une virgule juste après "salon".
Dans la description du #suggestions, "Pensez a respecter le format, sans quoi elles ne seront pas acceptées". Il faut, cette fois, un accent sur le "à".
Pour chipoter, vu que "API" est écrit en majuscules partout, surtout dans le nom du bot, peut-être changer la description des deux précédents salons : "pour les retrouver dans l'api", "que vous trouvez dans l'api" : "dans l'API"

Lorsqu'une blague a une correction en cours et qu'elle n'a pas été ajoutée ou refusée, on ne peut pas l'approuver sans approuver la correction ou la désapprouver sans désapprouver la correction. Mais et si la correction ne nous convient pas ? On la désapprouve. Et si la blague est bien, on ne peut pas l'approuver. C'est dommage, il faudrait faire en sorte que si l'on veuille donner son avis sur une suggestion, notre avis sur la correction ne compte pas.

Je propose la refonte de la commande stats pour compléter l'issues #198 :

• Celle ci serais sous forme de page.
• Un maximum de 25 utilisateurs par page.
• Changer de pages via des boutons ( <= | - | => )

Je vous propose que lorsqu'une blague a une correction, au lieu d'être bloqué par la correction qu'on puisse tout de même l'approuver & prévienne qu'une correction est en cours.

Petit truc, totalement logique mais pas très pratique, on ne peut pas approuver une blague après y avoir fait une correction, vu qu'il faut approuver cette correction mais qu'on ne peut pas approuver les siennes. Exemple pour être plus clair : La blague c'est "bananne", je la corrige en "Banane", et après je ne peux pas l'approuver.

Tout à l'heure, j'ai fait un ptit /stats comme ça et... Le /stats sans choisir d'options user renvoie les stats de l'auteur de la commande et plus les statistiques globales.

C'est voulu ou pas ? C'était drôlement pratique pour se repérer... C'est en lien avec le nouveau système de suggestions ?

Yo ! Suite à l'approbation d'une blague dont je n'avais pas approuvé la correction, cet EMBED s'est envoyé :

Du coup, je me disais : "Et si on rajoutait un lien hypertexte à la fin, à cette suggestion, comme ça par exemple : cette suggestion ?"

Et aussi corriger la faute "ai été corrigée" en "ait été corrigée", tant qu'à faire

Ajouter un composant vide avec les embeds pour les fonction interactionInfo et interactionProbleme pour eviter de laisser les boutons comme ci dessous

• Pk ne pas les retirer se serais plus propres sans et éviterais d'avoir des emojis en trop sur les message ?
• Cela laisserais au membre de réagir seulement a des corrections non migrée ou suggestion non ajouté a l'API.
  

En fin de journée (avec un Cron), le bot enverrait un message dans un salon avec une liste des actions que chaque Parain pourrait effectuer, on pourrait imaginer le format suivant:

<Mentions des parrains concernés dans le message>

[Suggestion](lien) <émojis des parrains>
[Correction](lien) <émojis des parrains>

Afin d'éviter les mentions abusives pour une seule action, on pourrait imaginer qu'on mentionnerait que les parrains qui ont plus de 2 ou 3 options.

Blague proposée: Bleu
Blague acceptée: Vert
Blague refusée: Rouge
Blague en cours de correction: Jaune

Correction proposée: Bleu
Correction acceptée: Vert
Correction refusée: Rouge
Correction remplacée: Jaune

Jusqu'ici, après approbation / désapprobation, c'est impossible de retirer son avis. Ca pourrait être plus simple par exemple si on misclicke et qu'on désapprobe une de ses propres blagues / corrections et qu'on ne peut donc pas mettre une approbation à la place

Il faudrait retirer les boutons afin de faire comprendre qu'ils ne sont plus utilisables.
Bonus :

• Ajouter des boutons sur le nouveau message
• Ajouter la partie qu'on modifie en ``` code ``` pour pouvoir copier/coller facilement (dans un embed ?).

Je propose une amélioration de la commande (stats user) pour les issues #198 et #356 .Voici trois models :
Model 1:

Model 2:

Model 3:

Serait-il possible d'avoir des endpoints :

• soit pour obtenir toutes les blagues d'un coup
• soit obtenir le nombre total de blague
• soit avoir des filtres par types, pour obtenir toutes les blagues d'un type (merci Zuruh)

Je propose un truc pour compléter l'issue #198, ça serait que l'activité dans le serveur soit prise en compte dans les statistiques. Ce serait pas beaucoup, mais par exemple à chaque mois d'inactivité (pour faire large) des points soient retirés des statistiques, ou ajoutés en bonus.

Par exemple, si le membre est actif, des points (jusqu'à, allez... 50) peuvent s'ajouter aux statistiques sous la forme de "Activité sur le serveur"

Ah aussi, peut-être essayer de comptabiliser l'activité Github aussi, dans la même catégorie (elle deviendrait donc "Activité sur le projet") ou sur une autre qui serait "Activité sur le Github".

Vu qu'assez récemment (je crois) les modals sont sortis, et que je trouve que ça aiderait très bien pour le système de corrections, je propose de les y ajouter.

Ce que je veux dire par là, c'est qu'actuellement, il faut des intents pour les messages, et à propos de messages, contrairement aux suggestions, quand quelqu'un veut faire une correction, des messages inutiles sont envoyés dans le #commandes. En plus, j'ai vu très peu de bots utiliser cette feature, et c'est dommage, mais en même temps ça ferait passer Blagues API comme un bot encore mieux que ce qu'il ne l'est déjà 😁.

Avec ça, plus aucun souci à propos des messages ! Les récents problèmes où la couleur et l'avatar customisés de l'EMBED disparaissaient ne seraient plus qu'un mauvais souvenir. Enfin j'espère.

Sur l'embed des /stats, dans tous les cas, il y a un field "Statistiques globales". Ce qui voudrait dire qu'il aurait un autre field, mais il n'est disponible que pour les parrains. Je trouverais donc plus logique de juste mettre une description à l'EMBED plutôt qu'un field si le membre à afficher les statistiques n'est pas parrain.

• Ajout automatique du rôle blagueur lors d'une blague approuvée
• Ajout automatique du rôle correcteur lors d'une correction approuvée

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• fix(deps): update dependency @sentry/node to v8
• fix(deps): update prisma dependencies to v5 (major) (@prisma/client, prisma)
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update all non-major dependencies (@fastify/cors, @octokit/rest, @sapphire/async-queue, @sentry/integrations, @sentry/node, @sentry/tracing, @types/common-tags, @types/diff, @types/jsonwebtoken, @types/lodash, @types/node, @types/node-schedule, @types/require-all, @types/sharp, @types/source-map-support, @types/string-similarity, actions/cache, actions/setup-node, dayjs, diff, discord-api-types, discord.js, fastify, fastify-plugin, jsonwebtoken, node, sharp, tsc-watch)
• chore(deps): update actions/cache action to v4
• chore(deps): update dependency @types/node to v20
• chore(deps): update dependency typescript to v5
• chore(deps): update devtools dependencies (major) (@commitlint/cli, @commitlint/config-conventional, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, eslint-config-prettier, eslint-plugin-prettier, husky, lint-staged, prettier)
• chore(deps): update postgres docker tag to v16
• fix(deps): update dependency @fastify/cors to v9
• fix(deps): update dependency @octokit/rest to v20
• fix(deps): update dependency got to v14
• chore(deps): lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• fix(deps): update dependency dotenv to v16

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Dans la volontée de faire évoluer ce projet, je penses qu'il serait intéressant de faire une réécriture complète de Blagues-API avec des technologies plus maintenues, plus stable et plus poussées.

Une branche dev permettra notamment cette évolution en douceur tout en gardant la version master pour la version actuelle.
L'idéal serait de n'avoir aucunes breaking-changes pour cette réécriture de sorte que les paquets et développeurs se servant de la version actuelle soient impactés.

A l'heure actuelle je penses notamment à plusieurs changements que la réécriture permettrait:

• Javascript => Typescript
• Express => Fastify (une branche avait été créé mais finalement laissé de coté)
• Sequelize => Prisma
• Ejs => NuxtJs
• Une séparation entre le bot Discord et l'API elle même.

Ejs étant un simple moteur de templating, le passage à NuxtJs pourrait être fait avec fastify-nuxtjs ou depuis la création d'un double proxy avec /api qui pointerait vers Fastify et / qui pointerait vers NuxtJs.

Une roadmap sera établie, n'hésitez pas à apporter votre aide ou vos idées par biais de d'issues ou de pull-requests !

Sur la commande /leaderboard je pense que ce serait une bonne idée de mettre en gras la ligne qui correspond à l'utilisateur ayant fais la commande. Cela permettrais de faciliter la lecture de notre propre classement car la plupart du temps, on met un peut de temps à se trouver pour savoir combien on est dans le classement.

La validation finale d'une correction retire la couleur et l'auteur de l'embed de la blague qui est suggérée

L'API n'accepte pas des requêtes Cross Origin. Serait-il possible d'ajouter https://github.com/fastify/fastify-cors ? Sur un ancien commit (quand l'API était sur express: 0a6af8d) vous l'aviez déjà ajouté mais depuis la refonte ce n'est plus le cas. Merci.

Le système de détection de blagues dupliquées se base actuellement sur les blagues déjà ajoutées, nous pourrions l'étendre aux blagues suggérées pour éviter les doublons.

Quand on récupères une blague avec le bot et qu'on aimerais y ajouter une correction, on a aucun moyen de trouver l'id de la blague en question pour faire la suggestion. Un simple fix serait juste d'ajouter en bas de l'embed de la blague son id

Utilisation d'un field pour l'affichage de la blague qui y ressemble et ajout des parrains en fin de field