Gitea: Site-Administratoren sollten über eine Benutzeroberfläche verfügen, um Probleme im Admin-Panel zu löschen

~Wie wir auf gitter gesagt haben, glaube ich nicht, dass es dafür eine Anforderung gibt und fast alle Git-Host-Software erlaubt es nicht, Probleme zu löschen.~

IMHO ist das kein Bug, sondern ein Feature. Es stellt sicher, dass niemand die Sichtbarkeit des Problems manipuliert.

Ich sehe das Problem nicht, wenn das Problem darin besteht, dass es jeder löschen kann, warum nicht einfach nach "Besitzer" suchen oder dem, der das Problem von Anfang an gemacht hat?

Ich meine, sagen wir, ich habe das gemacht, und dann denke ich darüber nach und weiß, dass es notwendig war oder meine Bitte dumm war oder aus einem anderen Grund, der mich dazu bringen würde, es zu entfernen, anstatt es einfach umsonst zu tun.

Das macht in meinen Augen überhaupt keinen Sinn

Themen, die sich dann als "dumm" erweisen und geschlossen werden, sind sehr hilfreich! Angenommen, jemand hat den gleichen Zweifel oder das gleiche Problem, das geschlossene Problem ist eine "Dokumentation" zu etwas, das sich dann als kein Problem herausgestellt hat, und wenn der Ersteller des Problems es hinzufügt, enthält es auch Anweisungen zur Lösung.

Nur bei rechtswidrigen Inhalten halte ich das Löschen für sinnvoll. Löschen Sie in diesem Fall einfach den Kommentar oder bearbeiten Sie das Problem, um das illegale Zeug nicht zu haben.

Ich kann verstehen, was dein Punkt ist, aber ich stimme in meinem Fall immer noch nicht zu Ich bin der einzige, der mein Repository betreibt, deshalb vermisse ich diese Funktion lösche Sachen, die nicht dort sein müssen

Wenn Sie ein Problem mit meinem Fehler erstellen, können Sie den Titel und den Text einfach in Invalid ändern und es schließen

Ich mag es immer noch nicht, aber ich sehe, dass kein anderer mir zustimmt.

In meinen Augen ist das unrein

Unsauber ja, aber konsequent 🙂

Wenn Sie beispielsweise ein ISSUE_TEMPLATE testen oder versuchen, den Projektablauf zu verstehen, wäre es sehr hilfreich, Ihre eigenen Probleme löschen zu können ...

Zumindest, wenn Sie der Eigentümer des Repositorys sind.

Diese Funktion sollte verfügbar sein, da der Eigentümer des Repositorys entscheiden kann, welcher Workflow für sein Projekt geeignet ist.

Der Besitzer könnte es auch einfach aus der DB löschen :)

Spammer hinterlassen Probleme mit Anzeigen und ich als Administrator kann sie nicht löschen 🤦‍♂️ Musste jedes Mal die DB bereinigen...

Site-Administratoren sollten die Berechtigung haben, die Probleme im Admin-Panel zu löschen, um die Wartung der Site zu erleichtern

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn in den nächsten 2 Wochen keine Aktivität mehr stattfindet. Vielen Dank für Ihre Beiträge.

Eine noch nicht angesprochene Sorge besteht darin, dass einige Inhalte aus rechtlichen Gründen möglicherweise entfernt werden müssen. Sagen wir zum Beispiel, dass Benutzer X einige wirklich wirklich illegale Dinge in einem Issue postet. Natürlich wird ihr Konto sofort gekündigt, aber jetzt hat der Site-Administrator illegale Inhalte auf ihrer Site und kann sie nicht löschen.

Beachten Sie auch, dass der Administrator nicht immer weiß, wie er ein Problem aus der Datenbank entfernt; eine Option, dies über die Benutzeroberfläche zu tun, ist ein Muss, es sei denn, die Administratoren können ihren Benutzern 100% vertrauen (was selten der Fall ist).

nicht immer weiß der Administrator, wie er ein Problem aus der Datenbank entfernen kann;

Ich möchte einen Pull-Request löschen. Sind die folgenden SQL gut genug, bevor die GUI verfügbar ist?

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

Angenommen, die Zahl am Ende der Pull-Request-URL ist 10
http://localhost :3200/org_name/repo_name/pulls/10

Nur eine kleine Meinung, aber hier ist eine Liste von Dingen, die meiner Meinung nach gelöscht statt geschlossen werden sollten:

• Probleme mit illegalen, anstößigen oder anderweitig unerwünschten Inhalten.
• Völlig unabhängiger Inhalt ohne Bezug zum Projekt.
• Werbung für andere (ähnliche) Projekte
• Starke Sprache, die der Autor nicht abschwächen will

Dinge, die einfach geschlossen werden

• Doppelte Probleme, die keine neuen Informationen hinzufügen
• Kritik ohne Begründung oder Verbesserungsvorschläge à la ur s0ftware suxx

Ich hoffe, dies unterstreicht, dass es sowohl für Administratoren als auch für Repository-Betreuer oft sinnvoll ist, Issues in bestimmten Situationen vollständig zu löschen.

Problem aus DB entfernt, wie kann man es jetzt beheben?

Als selbst gehosteter Git-Repo-Server denke ich auch, dass der Site-Administrator in der Lage sein sollte, Repository-Besitzern zu erlauben, "was sie wollen".

Als Beispiel bin ich der Besitzer meines Servers (und selbst wenn ich es nicht wäre, aber die aktivierten Optionen dazu hätte, wäre es dasselbe), und ich möchte auch als Besitzer meines Repos selbst Probleme eröffnen um anderen Leuten meine Arbeit zu zeigen, die ich im Laufe der Zeit mache, und dass ich nützliche Dinge hinzufüge, nicht nur dummen Mist (nur weil 90% der Leute, die ich kenne, nie die Commit-Historie sehen und Commits kontern, die meinen Fleiß beweisen und einfach sagen "' zum Teufel du tust den ganzen tag? blöder nutzloser code?“).

Wenn ich jedoch an meinen eigenen Themen arbeite (und das haben wahrscheinlich auch 90% von euch zumindest einmal getan), weiß ich normalerweise nicht, wo ich die Dinge unter meinem eigenen Label-Schema unterbringen soll, also neige ich dazu, ein Label hinzuzufügen, es dann zu entfernen und weisen Sie das Problem unter einem anderen Label, und so weiter so weiter , bis meine „Problem Geschichte“ so etwas wie sieht diese ...

Es wäre sehr schön, diese beschissene Unentschlossenheit löschen und eine neue Ausgabe von vorne beginnen zu können (oder zumindest die "Label-Historie" meiner Unentschlossenheit zu löschen) ...

Problem aus DB entfernt, wie kann man es jetzt beheben?

Ich habe das tatsächlich herausgefunden, nachdem ich das gleiche Problem hatte. Gehen Sie zur Tabelle repository Ihrer Datenbank. Die Anzahl der offenen Ausgaben ist der Subtrahend der 2 Spalten num_issues und num_closed_issues . Ich habe 47 num_issues in 46 geändert und die Zählung aktualisiert.

@DJFraz
Das Verringern von num_issues verursacht Fehler 500 beim Versuch, ein neues Problem zu erstellen, ich musste stattdessen num_closed_issues erhöhen.

Das Ändern von num_closed_issues war auch keine gute Idee :) Gitea aktualisiert es gemäß der Problemtabelle.
Es werden also entweder Issues entfernt und dann sichergestellt, dass num_issues + 1 nicht mit dem vorhandenen Issue-Index kollidiert, oder einfach ein Issue schließen und seinen Inhalt leeren.

:point_up: Genau deshalb ist das Löschen von Problemen nicht implementiert. Aus Performancegründen wird die Anzahl der Ausgaben ( num_issues ) in der DB zwischengespeichert, diese Nummer wird auch für die nächste Ausgabenummer verwendet ( num_issues + 1 ).

Man könnte diesen Wert in der DB duplizieren und als Fix last_issue_nr oder next_issue_nr . Oder man könnte einen hidden -Boolean zur Issue-Tabelle hinzufügen. Im letzteren Fall wird das Problem nur von der Benutzeroberfläche (und API) ausgeblendet, kann aber später bei Bedarf referenziert werden (rechtliche Gründe wurden zuvor im Thread erwähnt).

Nur meine 2 Cent

diese Nummer wird auch für die nächste Ausgabenummer verwendet ( num_issues + 1 ).

Nicht ganz. Derzeit ist es SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

Genau deshalb ist das Löschen von Problemen nicht implementiert

Nein, deshalb sollte man sich nicht manuell damit anlegen :)
Gründe sind mir egal, ich möchte die volle Kontrolle über meine Site, diese Funktion sollte implementiert werden.

Dies wird für öffentlich zugängliche gitea-Installationen benötigt, insbesondere wenn Sie von Spam angegriffen wurden.

Für mich muss die Schließfunktion zum Schließen eines Problems im Zusammenhang mit dem Projekt dienen und nicht zum Schließen eines nicht verwandten Spams, der besser gelöscht werden muss.

Wir sollten die letzten index in einer Repository-Tabelle oder etwas anderem speichern.

Wir sollten die letzten index in einer Repository-Tabelle oder etwas anderem speichern.

Das klingt definitiv auch nach einer Lösung für das Update-Index-Problem, solange xorm SELECT FOR UPDATE auf allen unseren DBs unterstützt. Ich denke, das tut es, nicht wahr?

Bezüglich der Erstellung von sequentiellen Werten, die fortlaufend sein müssen (dh keine Löcher), hatten wir in einem Projekt, das ich vor langer Zeit durchgeführt habe, eine separate Tabelle, um diese zu generieren. z.B:

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

Um die nächste Ausgabenummer zu berechnen, haben wir auf diese Weise Folgendes getan:

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)

Auf diese Weise haben wir nur eine Sperre erzeugt, um ein Problem hinzuzufügen (dh die eigentliche Repository-Zeile wurde für den Rest der Transaktion nicht gesperrt). Andere Transaktionen, die versuchen, Zeilen hinzuzufügen, werden gesperrt und warten darauf, dass das erste UPDATE aufgelöst wird, sodass Duplikate ausgeschlossen sind. Wenn die erste Transaktion zurückgesetzt wird, erhält die zweite den korrekten nächsten Wert dafür.

Dies würde auch sicherstellen, dass keine Werte wiederverwendet werden, selbst wenn wir die neueste Ausgabe löschen.

@guillep2k das klingt besser.

Die von @guillep2k vorgeschlagene lunny- Lösung scheint legitim wie ein Boss zu sein; Aber wie @DJFraz am 27. August 2019 feststellte, wie sollte der Umgang mit diesen Ihrer Meinung nach implementiert werden, da
Danke.

Die von @guillep2k vorgeschlagene lunny- Lösung scheint legitim wie ein Boss zu sein; Aber wie @DJFraz am 27. August 2019 feststellte, wie sollte der Umgang mit diesen Ihrer Meinung nach implementiert werden, da

Es ist nur eine Frage der Neuberechnung der "zwischengespeicherten" Werte, genau wie wir es tun, wenn wir ein Problem öffnen/schließen.

Das Problem in diesem Kommentar besteht darin, dass der Benutzer versucht hat, die Zeile zu löschen, ohne die entsprechenden Spalten zu aktualisieren, um die Änderung widerzuspiegeln.

Das Problem in diesem Kommentar besteht darin, dass der Benutzer versucht hat, die Zeile zu löschen, ohne die entsprechenden Spalten zu aktualisieren, um die Änderung widerzuspiegeln.

Also, techincally ... ist es möglich , löschen Dinge aus der Datenbank _manually_ und weg mit ihm , ohne etwas zu brechen?

Also, techincally ... ist es möglich , löschen Dinge aus der Datenbank _manually_ und weg mit ihm , ohne etwas zu brechen?

Es gibt das Problem der Wiederverwendung von Ausgabenummern. Wenn Sie einen schlechten Kommentar #999 löschen und es zufällig der letzte ist, erhält der nächste gute Kommentar auch die Nummer #999 , was kein Nein ist. Der neue Kommentar sollte eigentlich #1000 lauten und die Zahl #999 sollte "unbenutzt" bleiben. Aber ich arbeite an einer PR, die dieses Problem behebt und den Weg für das Löschen von Kommentaren in der Zukunft ebnet.

An die Leute, die gegen das Löschen von Problemen sind: Gut, aber dann erlauben Sie, den Bearbeitungsverlauf zu löschen.

alternativ: Wie wäre es, unerwünschte Probleme vollständig aus der Ansicht auszublenden und eine Option für Administratoren hinzuzufügen, um versteckte Probleme anzuzeigen?

Dies würde sowohl das Problem beheben, dass rechtlich gefährliche Inhalte nicht von Ihrer eigenen Website gelöscht werden können, als auch die Problemliste aufgeräumt werden

Dies würde sowohl das Problem beheben, dass rechtlich gefährliche Inhalte nicht von Ihrer eigenen Website gelöscht werden können

@DarkWiiPlayer Die Sache ist die, dass der potenziell illegale Inhalt, wie beispielsweise ein pornografisches Bild von

Ausblenden von Problemen: Gut für Leute, die keine doppelten Probleme und überladenen Inhalt mit einem Problemverlauf voller Hinzufügen und Entfernen von Labels und Personen und sich ändernden Entscheidungen haben möchten.
Nicht gut jedoch für illegale Inhalte, die auf den Festplatten des Servers gespeichert sind...

@DarkWiiPlayer Die Sache ist die, dass der potenziell illegale Inhalt, wie beispielsweise ein pornografisches Bild von

Das ist ein guter Punkt. Ich schätze, ich habe es aus der Perspektive "Wenn die Polizei es nie sieht, ist alles in Ordnung" betrachtet, aber es gibt eine Vielzahl von Gründen, warum dies dem Seitenbesitzer immer noch schaden könnte, von jemandem, der es zufällig findet, bis hin zu jemandem absichtlich solche Inhalte hochzuladen und dann die Polizei zu verständigen.

Ich denke immer noch, dass versteckte Probleme besser sind als nichts, und in Kombination mit der Bearbeitung des Problems und dem Bereinigen des Bearbeitungsverlaufs würde es immer noch funktionieren.

Im Idealfall wäre jedoch eine Option zum wirklichen "Löschen" des Problems die beste Lösung, selbst wenn dies nur das Bereinigen aller Daten und das Setzen auf "gelöscht" in der Datenbank bedeutet.

Das ist ein guter Punkt.

Danke.

Ich glaube, ich habe es aus der Perspektive betrachtet: "Wenn die Polizei es nie sieht, geht es dir gut"

Leider funktioniert das nicht, wenn man illegale Dateien auf seinem Speichermedium hat... auch wenn diese nicht über eine URL öffentlich zugänglich sind, wenn eine Meldung gemacht und eine Prüfung eingereicht wird, ist man am Arsch, egal wie viel "aber das sind von Benutzern hochgeladene Inhalte" Sie sagen können ...

Um die Liste der Gründe dafür zu ergänzen: Ich organisiere derzeit die Arbeit in einem privaten Repo mit 2 anderen Mitarbeitern, daher enthält unsere Kommunikation derzeit Details, die wir nicht öffentlich bekannt geben würden. Es besteht jedoch die Möglichkeit, dass das Repo zu einem zukünftigen Zeitpunkt veröffentlicht wird, wenn wir uns entscheiden, das Projekt offen zu veröffentlichen. An diesem Punkt wäre es großartig, eine Möglichkeit zu haben, den Themenbereich vollständig zu löschen, bevor die Sichtbarkeit des Projekts auf die Öffentlichkeit gesetzt wird und damit an die

Wäre toll, dieses Feature irgendwann zu sehen, trotzdem danke für die ganze Arbeit an gitea und mach weiter so!