Gitea: Les administrateurs de site devraient avoir une interface utilisateur pour supprimer les problèmes sur le panneau d'administration

~Comme nous l'avons dit sur gitter, je ne pense pas que cela soit nécessaire et presque tous les logiciels hôtes git ne permettent pas de supprimer le problème.~

À mon humble avis, ce n'est pas un bug, c'est une fonctionnalité. Cela garantit que personne ne manipule la visibilité du problème.

Je ne vois pas le problème, si le problème est que n'importe qui peut le supprimer, pourquoi ne pas le regarder vers le "propriétaire" ou celui qui a créé le problème depuis le début ?

Je veux dire, disons que j'ai fait cela, puis j'y pense et je sais que c'était nécessaire ou que ma demande était stupide ou pour toute autre raison qui me ferait le supprimer au lieu de n'avoir lieu pour rien.

Cela n'a aucun sens à mes yeux

Les problèmes qui s'avèrent ensuite « stupides » et qui sont clos sont très utiles ! Supposons que quelqu'un ait le même doute ou problème, le problème clos est une "documentation" sur quelque chose qui s'est alors avéré ne pas être un problème, et si le créateur du problème l'ajoute, il contiendra également des instructions sur la façon de le résoudre.

Le seul cas dans lequel je trouve que la suppression des problèmes a du sens est en cas de contenu illégal. Dans ce cas, supprimez simplement le commentaire ou modifiez le problème pour ne pas avoir les éléments illégaux.

Je peux voir quel est votre point de vue, mais je ne suis toujours pas d'accord dans mon cas, je suis le seul à exécuter mon référentiel, c'est pourquoi cette fonction me manque, supprimez des éléments qui ne doivent pas nécessairement être là.

Si vous créez un problème par erreur, vous pouvez simplement changer le titre et le corps en Invalid et le fermer

Je n'aime toujours pas ça, mais je vois que personne d'autre n'est d'accord avec moi.

A mes yeux c'est impur

Impur oui, mais cohérent 🙂

Lorsque vous testez par exemple un ISSUE_TEMPLATE ou essayez de comprendre le flux du projet, il serait très utile de pouvoir supprimer vos propres problèmes ...

Au moins lorsque vous êtes le propriétaire du référentiel.

Cette fonctionnalité devrait être disponible car il appartient au propriétaire du référentiel de décider quel workflow est adapté à son projet.

Le propriétaire pourrait aussi simplement le supprimer de la base de données :)

Les spammeurs laissent des problèmes avec les publicités et en tant qu'administrateur, je ne peux pas les supprimer 🤦‍♂️ J'ai dû nettoyer la base de données à chaque fois...

Les administrateurs du site doivent avoir l'autorisation de supprimer les problèmes sur le panneau d'administration pour faciliter la maintenance du site

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu au cours des 2 prochaines semaines. Merci pour vos contributions.

Une préoccupation qui n'a pas encore été soulevée est que certains contenus peuvent nécessiter une suppression pour des raisons juridiques. Disons, par exemple, que l'utilisateur X publie des trucs vraiment très illégaux dans un numéro. Bien sûr, leur compte est résilié instantanément, mais maintenant l'administrateur du site a du contenu illégal sur son site et ne peut pas le supprimer.

Veuillez également noter que l'administrateur ne sait pas toujours comment supprimer un problème de la base de données ; une option permettant de le faire à partir de l'interface utilisateur est indispensable, à moins que les administrateurs ne puissent faire confiance à 100% à leurs utilisateurs (ce qui est rarement le cas).

l'administrateur ne sait pas toujours comment supprimer un problème de la base de données ;

Je souhaite supprimer une pull request. Avant que l'interface graphique ne soit disponible, le SQL suivant est-il suffisant ?

delete from pull_request where issue_id = 10;
delete from issue where id = 10;

En supposant que le nombre à la fin de l'URL de demande d'extraction est 10
http://localhost :3200/org_name/repo_name/pulls/10

Juste un peu d'opinion, mais voici une liste de choses qui, selon moi, devraient être supprimées au lieu de fermées :

• Problèmes contenant du contenu illégal, offensant ou autrement indésirable.
• Contenu sans aucun rapport avec le projet quoi qu'il en soit.
• Publicité pour d'autres projets (similaires)
• Langage fort que l'auteur refuse d'atténuer

Des choses qui pourraient juste être fermées, mais certains responsables et/ou administrateurs peuvent toujours vouloir supprimer pour garder un backlog plus propre :

• Problèmes en double qui n'ajoutent aucune nouvelle information
• Critiques sans fondement ni suggestions d'améliorations à la ur s0ftware suxx

J'espère que cela souligne le fait qu'il est souvent logique, à la fois pour les administrateurs et les responsables du référentiel, de supprimer complètement les problèmes dans certaines situations.

Problème supprimé de la base de données, comment résoudre ce problème maintenant ?

En tant que serveur de référentiel git auto-hébergé, je pense également que l'administrateur du site devrait pouvoir autoriser les propriétaires de référentiel à faire "ce qu'ils veulent".

Par exemple, je suis le propriétaire de mon serveur (et même si je ne l'étais pas mais que j'avais les options activées pour le faire, ce serait la même chose), et j'aimerais aussi en tant que propriétaire de mon repo, ouvrir moi-même les problèmes pour montrer aux autres le travail que je fais au fil du temps et que j'ajoute des trucs utiles, pas seulement des conneries stupides (seulement parce que 90% des gens que je connais ne regardent jamais l'historique des commits et s'engagent contre prouvant ma diligence et disent juste « ' diable vous faites toute la journée ? stupide code inutile ? ").

Cependant, lorsque je travaille sur mes propres problèmes (et 90% d'entre vous l'ont probablement fait au moins une fois), je ne sais généralement pas où mettre les choses, même sous mon propre schéma d'étiquette, j'ai donc tendance à ajouter une étiquette, puis à la supprimer et attribuer le problème sous une autre étiquette, et ainsi de suite jusqu'à ce que mon "historique des problèmes" ressemble à ceci ...

Ce serait très bien de pouvoir supprimer cette indécision de merde et de recommencer un nouveau problème (ou au moins de supprimer "l'historique des étiquettes" de mon indécision sur ce qu'il faut être)...

Problème supprimé de la base de données, comment résoudre ce problème maintenant ?

En fait, j'ai compris cela après avoir eu le même problème. Allez dans la table repository de votre base de données. Le nombre de problèmes ouverts est la sous-catégorie des 2 colonnes num_issues et num_closed_issues . J'ai changé 47 num_issues en 46 et le compte a été mis à jour.

@DJFraz
La diminution de num_issues provoque l'erreur 500 lors de la tentative de création d'un nouveau problème, j'ai dû augmenter num_closed_issues place.

Changer num_closed_issues n'était pas une bonne idée non plus :) Gitea le met à jour en fonction du tableau des problèmes.
Il s'agit donc soit de supprimer les problèmes, puis de s'assurer que num_issues + 1 n'entrera pas en conflit avec l'index de problèmes existant, soit de simplement fermer un problème et de vider son contenu.

:point_up: c'est exactement pourquoi la suppression des problèmes n'est pas implémentée. Pour des raisons de performances, le nombre de problèmes est mis en cache ( num_issues ) dans la base de données, ce nombre est également utilisé pour ce que sera le prochain numéro de problème ( num_issues + 1 ).

On pourrait dupliquer cette valeur dans la base de données et avoir last_issue_nr ou next_issue_nr comme correctif. Ou on pourrait ajouter un hidden -booléen à la table d'émission. Dans ce dernier cas, le problème n'est masqué que dans l'interface utilisateur (et l'API), mais peut être référencé ultérieurement si nécessaire (des raisons juridiques ont été mentionnées plus haut dans le fil)

Juste mes 2 cents

ce numéro est également utilisé pour ce que sera le prochain numéro d'émission ( num_issues + 1 ).

Pas assez. Actuellement, c'est SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

c'est exactement pourquoi la suppression des problèmes n'est pas implémentée

Non, c'est pourquoi vous ne devriez pas jouer avec eux manuellement :)
Je me fiche des raisons, je veux un contrôle total sur mon site, cette fonctionnalité doit être implémentée.

cela est nécessaire pour les installations de gitea disponibles en public, surtout si vous avez été ciblé par du spam.

pour moi, la fonction de fermeture doit servir à fermer un problème lié au projet et non à fermer un spam sans rapport qu'il vaut mieux supprimer.

Nous devrions stocker le dernier index sur la table du référentiel ou quelque chose d'autre.

Nous devrions stocker le dernier index sur la table du référentiel ou quelque chose d'autre.

Cela ressemble également à une solution au problème de l'index de mise à jour, tant que xorm prend en charge SELECT FOR UPDATE sur toutes nos bases de données. Je pense que oui, n'est-ce pas ?

En ce qui concerne la création de valeurs séquentielles qui doivent être consécutives (c'est-à-dire sans trous), dans un projet que j'ai fait il y a longtemps, nous avions une table séparée pour les générer. par exemple:

SQL> SELECT * from max_values;
table        | key          | last_value
-------------+--------------+-------------
repository   |          445 |          3
repository   |          446 |          1
repository   |          447 |        745
repository   |          448 |         92
repository   |          449 |         60
repository   |          450 |         46

De cette façon, pour calculer le numéro suivant, nous avons procédé comme suit :

PSQL> UPDATE max_values SET last_value = last_value + 1
      WHERE table = 'repository' and key = '448';
PSQL> SELECT last_value + 1 FROM max_values
      WHERE table = 'repository' and key = '448';

(read value)

De cette façon, nous n'avons produit qu'un seul verrou pour ajouter un problème (c'est-à-dire que la ligne réelle du référentiel n'a pas été verrouillée pour le reste de la transaction). Les autres transactions tentant d'ajouter des lignes seront verrouillées en attendant la résolution de la première MISE À JOUR, donc aucune chance de doublons. Si la première transaction est annulée, la seconde obtiendra la valeur suivante correcte pour elle.

Cela garantirait également qu'aucune valeur n'est réutilisée, même si nous supprimons le dernier numéro.

@guillep2k ça sonne mieux.

La solution @guillep2k semble légitime comme un patron ; mais comme @DJFraz l'a noté le 27 août 2019, étant donné que les compteurs de problèmes sont calculés à l'exécution mais ensuite stockés dans la base de données pour la mise en cache, comment pensez-vous que leur gestion devrait être implémentée ?
Merci.

La solution @guillep2k semble légitime comme un patron ; mais comme @DJFraz l'a noté le 27 août 2019, étant donné que les compteurs de problèmes sont calculés à l'exécution mais ensuite stockés dans la base de données pour la mise en cache, comment pensez-vous que leur gestion devrait être implémentée ?

Il s'agit simplement de recalculer les valeurs "en cache", comme nous le faisons lorsque nous ouvrons/fermons un problème.

Le problème dans ce commentaire est que l'utilisateur a tenté de supprimer la ligne sans mettre à jour les colonnes appropriées pour refléter le changement.

Le problème dans ce commentaire est que l'utilisateur a tenté de supprimer la ligne sans mettre à jour les colonnes appropriées pour refléter le changement.

Donc, techniquement... il EST possible de supprimer _manuellement_ des éléments de la base de données et de s'en sortir sans rien casser ?

Donc, techniquement... il EST possible de supprimer _manuellement_ des éléments de la base de données et de s'en sortir sans rien casser ?

Il y a le problème de la réutilisation des numéros d'émission. Si vous supprimez le mauvais commentaire #999 et qu'il s'agit du dernier, le prochain bon commentaire portera également le numéro #999 , qui est non non non. Le nouveau commentaire devrait être en fait #1000 et le nombre #999 devrait être laissé "inutilisé". Mais je travaille sur un PR qui résoudra ce problème et ouvrira la voie à la suppression des commentaires à l'avenir.

Pour les personnes qui sont contre la suppression des problèmes : très bien, mais permet ensuite de supprimer l'historique des modifications.

alternativement : que diriez-vous de masquer complètement les problèmes indésirables et d'ajouter une option permettant aux administrateurs d'afficher les problèmes cachés ?

Cela résoudrait à la fois le problème de l'impossibilité de supprimer le contenu juridiquement dangereux de votre propre site et de désencombrer la liste des problèmes.

Cela résoudrait à la fois le problème de l'impossibilité de supprimer le contenu juridiquement dangereux de votre propre site

@DarkWiiPlayer le fait est que le contenu potentiellement illégal, comme une image pornographique pédo, est toujours disponible sur le lecteur de votre serveur, et accessible par une vérification demandée sur vos services auprès d'un officier de police...

Masquage des problèmes : parfait pour les personnes qui ne veulent pas avoir de problèmes en double et des éléments encombrés avec un historique des problèmes rempli d'ajout et de suppression d'étiquettes, de personnes et de décisions changeantes.
Pas bien en revanche pour les contenus illégaux stockés sur les disques du serveur...

@DarkWiiPlayer le fait est que le contenu potentiellement illégal, comme une image pornographique pédo, est toujours disponible sur le lecteur de votre serveur, et accessible par une vérification demandée sur vos services auprès d'un officier de police...

C'est un bon point. Je suppose que je l'examinais du point de vue "Si la police ne le voit jamais, tout va bien", mais il y a diverses raisons pour lesquelles cela pourrait encore nuire au propriétaire du site, de quelqu'un qui le trouve au hasard à quelqu'un télécharger intentionnellement un tel contenu, puis informer la police.

Je pense toujours que les problèmes cachés valent mieux que rien, et en combinaison avec la modification du problème et le nettoyage de son historique d'édition, cela fonctionnerait toujours.

Idéalement cependant, une option pour vraiment "supprimer" le problème, même si cela signifie simplement nettoyer toutes les données et les définir sur "supprimé" dans la base de données, serait la meilleure solution.

C'est un bon point.

Merci.

Je suppose que je le regardais du point de vue que "Si la police ne le voit jamais, tout va bien"

Malheureusement ça ne marche pas comme ça quand tu as des fichiers illégaux sur ton support de stockage... même s'ils ne sont pas accessibles publiquement via une URL, si un signalement est fait et qu'un contrôle est déposé, tu es foutu, peu importe combien "mais c'est du contenu téléchargé par l'utilisateur" vous pouvez dire...

Pour ajouter à la liste des raisons de l'avoir : j'organise actuellement le travail dans un dépôt privé avec 2 autres collaborateurs, donc notre communication comprend actuellement des détails que nous ne divulguerions pas publiquement. Cependant, il y a de fortes chances que le repo soit rendu public à un moment ultérieur lorsque nous déciderons de publier ouvertement le projet. À ce stade, ce serait formidable d'avoir un moyen d'effacer complètement la section des problèmes avant de rendre la visibilité du projet au public et ainsi de l'ouvrir au grand jour.

Ce serait formidable de voir cette fonctionnalité à un moment donné, en tout cas merci pour tout le travail sur gitea et continuez votre excellent travail !