Gitea: サイト管理者は、管理パネルで問題を削除するためのUIを持っている必要があります

〜gitterで述べたように、これに対する要件はないと思います。ほとんどすべてのgitホストソフトウェアは問題を削除することを許可していません。〜

私見それはバグではなく、機能です。 誰も問題の可視性を操作しないようにします。

問題はわかりません。誰でも削除できるという問題がある場合は、「所有者」または最初から問題を実際に作成した人に見てみませんか。

つまり、私がこれを作ったとしましょう。それから私はそれについて考え、それが必要だったのか、私の要求が愚かだったのか、それともただの理由でそれを削除するような他の理由があるのか​​を知っています。

それは私の目にはまったく意味がありません

それ以降の問題は「愚か」であることが証明され、クローズされることは非常に役立ちます！ 誰かが同じ疑問や問題を抱えているとすると、閉じられた問題は、問題ではないことが証明されたものに関する「文書化」であり、問​​題の作成者がそれを追加した場合、それを解決する方法の説明も含まれます。

問題を削除することが理にかなっていると私が思う唯一のケースは、違法なコンテンツの場合です。 その場合は、コメントを削除するか、問題を編集して違法なものがないようにしてください。

私はあなたのポイントが何であるかを見ることができますが、私の場合はまだ同意しません。私のリポジトリを実行しているのは私だけです。そのため、その関数を見逃しているので、そこにある必要のないものを削除します。

私の間違いで問題を作成した場合は、タイトルと本文をInvalidして閉じることができます

私はまだそれが好きではありませんが、他の誰も私に同意しないのを見ます。

私の目には汚れている

はい、汚れていますが、一貫しています🙂

たとえば、ISSUE_TEMPLATEをテストしている場合や、プロジェクトフローを理解しようとしている場合は、独自の問題を

少なくともあなたがリポジトリの所有者である場合。

この機能は、リポジトリの所有者が自分のプロジェクトに適したワークフローを決定する必要があるため、利用できるはずです。

所有者はそれをdbから削除することもできます:)

スパマーは広告に問題を残しており、管理者として私はそれらを削除できません🤦‍♂️毎回DBをクリーンアップする必要がありました...

サイト管理者は、サイトを簡単に維持するために、管理パネルで問題を削除する権限を持っている必要があります

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 今後2週間以内にそれ以上の活動が発生しなければ、閉鎖されます。 貢献していただきありがとうございます。

まだ提起されていない懸念の1つは、法的な理由で一部のコンテンツの削除が必要になる可能性があることです。 たとえば、ユーザーXが問題に本当に違法なものを投稿したとします。 もちろん、彼らのアカウントは即座に終了しますが、現在、サイト管理者は彼らのサイトに違法なコンテンツを持っており、それを削除することはできません。

また、管理者がデータベースから問題を削除する方法を常に知っているとは限らないことに注意してください。 管理者がユーザーを100％信頼できない限り、UI内からこれを行うオプションは必須です（これはめったにありません）。

管理者がデータベースから問題を削除する方法を常に知っているとは限りません。

プルリクエストを削除したいのですが。 GUIが利用可能になる前に、次のSQLで十分ですか？

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

プルリクエストURLの最後の番号が10であると仮定します
http：// localhost ：3200 / org_name / repo_name / pulls / 10

少し意見がありますが、これは、閉じるのではなく削除する必要があると私が信じているもののリストです。

• 違法、攻撃的、またはその他の望ましくないコンテンツを含む問題。
• プロジェクトとはまったく関係のない、完全に無関係なコンテンツ。
• 他の（同様の）プロジェクトの広告
• 作者がトーンダウンを拒否する強い言葉

クローズすることも

• 新しい情報を追加しない重複した問題
• ur s0ftware suxxような根拠や改善のための提案のない批判

これが、管理者とリポジトリメンテナの両方にとって、特定の状況で問題を完全に削除することがしばしば理にかなっているという点を強調することを願っています。

DBから問題を削除しました。これを今すぐ修正するにはどうすればよいですか？

自己ホスト型のgitリポジトリサーバーとして、サイト管理者はリポジトリの所有者が「好きなことを何でも」できるようにする必要があると思います。

例として、私はサーバーの所有者です（そうでなくても、そのようなオプションが有効になっている場合でも同じです）。また、リポジトリの所有者として、自分で問題を開くことを希望します。他の人に私が時間をかけて行っている作業を示し、愚かながらくただけでなく、便利なものを追加することを示します（私が知っている人の90％がコミット履歴を決して見ず、私の勤勉さを証明するカウンターをコミットし、「あなたがやった地獄」と言うだけだからです一日中？ばかげた役に立たないコード？ "）。

しかし、私が自分の問題に取り組んでいるとき（そしてあなたの90％はおそらく一度は少なくとも一度はやったでしょう）、通常は自分のラベルスキームの下でもどこに物を置くべきかわからないので、ラベルを追加してから削除する傾向があります私の「発行履歴が」のようになりますまで、等々ように別のラベルの下の問題を割り当て、この...

そのくだらない決断を削除して、新しい問題を最初からやり直すことができると非常にいいでしょう（または少なくとも、私の決断の「ラベル履歴」を削除する）...

DBから問題を削除しました。これを今すぐ修正するにはどうすればよいですか？

同じ問題が発生した後、私は実際にこれを理解しました。 データベースのrepositoryテーブルに移動します。 未解決の発行数は、2列のnum_issuesとnum_closed_issuesの減数です。 47 num_issuesを46と、カウントが更新されました。

@DJFraz
num_issuesを減らすと、新しい問題を作成しようとしたときにエラー500が発生します。代わりに、 num_closed_issuesを増やす必要がありました。

num_closed_issues変更することも良い考えではありませんでした：）Giteaは問題の表に従ってそれを更新します。
つまり、問題を削除してから、 num_issues + 1が既存の問題インデックスと競合しないことを確認するか、問題を閉じてそのコンテンツを空にするだけです。

：point_up：それが、問題の削除が実装されていない理由です。 パフォーマンス上の理由から、問題の数はDBにキャッシュされ（ num_issues ）、この数は次の問題番号（ num_issues + 1 ）にも使用されます。

DBでこの値を複製し、修正としてlast_issue_nrまたはnext_issue_nrを使用することができます。 または、 hidden booleanをissue-tableに追加することもできます。 後者の場合、問題はUI（およびAPI）からのみ隠されますが、必要に応じて後で参照できます（法的な理由はスレッドで前述しました）

ちょうど私の2セント

この番号は、次の発行番号（ num_issues + 1 ）にも使用されます。

完全ではありません。 現在はSELECT MAX(index)+1 FROM issue WHERE repo_id = ?です。

問題の削除が実装されていないのはまさにそのためです

いいえ、それがあなたがそれらを手動でいじるべきではない理由です:)
理由は気にしません。自分のサイトを完全に制御したいので、この機能を実装する必要があります。

これは、特にスパムの標的にされている場合に、公開されているgiteaのインストールに必要です。

私にとって、クローズ機能はプロジェクトに関連する問題をクローズするためのものである必要があり、削除する方がよい無関係のスパムをクローズするために使用することはできません。

最後のindexをリポジトリテーブルなどに保存する必要があります。

最後のindexをリポジトリテーブルなどに保存する必要があります。

xormがすべてのデータベースでSELECT FOR UPDATEをサポートしている限り、これは間違いなく更新インデックスの問題の解決策のように聞こえます。 そうだと思いますよね？

連続する必要がある（つまり、穴がない）連続値の作成に関して、私がずっと前に行ったプロジェクトでは、それらを生成するための別のテーブルがありました。 例えば：

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

このようにして、次の問題番号を計算するために、次のことを行いました。

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)

このようにして、問題を追加するためのロックを1つだけ作成しました（つまり、トランザクションの残りの部分で実際のリポジトリ行がロックされませんでした）。 行を追加しようとする他のトランザクションは、最初のUPDATEが解決されるのを待ってロックされるため、重複する可能性はありません。 最初のトランザクションがロールバックすると、2番目のトランザクションはその正しい次の値を取得します。

これにより、最新の問題を削除した場合でも、値が再利用されないようにすることもできます。

@ guillep2kいいです

@ guillep2kによって提案された@lunnyソリューションは上司のように合法的なようです。 しかし、 @ DJFrazが2019年8月27日に指摘したように、問題カウンターは実行時に計算され、キャッシュのためにデータベースに保存されるため、それらの処理をどのように実装する必要があると思いますか？
ありがとう。

@ guillep2kによって提案された@lunnyソリューションは上司のように合法的なようです。 しかし、 @ DJFrazが2019年8月27日に指摘したように、問題カウンターは実行時に計算され、キャッシュのためにデータベースに保存されるため、それらの処理をどのように実装する必要があると思いますか？

問題を開いたり閉じたりするときと同じように、「キャッシュされた」値を再計算するだけです。

そのコメントの問題は、ユーザーが変更を反映するために適切な列を更新せずに行を削除しようとしたことです。

そのコメントの問題は、ユーザーが変更を反映するために適切な列を更新せずに行を削除しようとしたことです。

だから、techincally ...データベースから削除物事を_manually_、何を壊すことなく、それに逃げることは可能ですか？

だから、techincally ...データベースから削除物事を_manually_、何を壊すことなく、それに逃げることは可能ですか？

発行番号が再利用されるという問題があります。 悪いコメント#999を削除し、それがたまたま最後である場合、次の良いコメントにも番号#999ますが、これはノーノーノーです。 新しいコメントは実際には#1000あり、番号#999は「未使用」のままにしておく必要があります。 しかし、私はこの問題を修正し、将来コメントを削除する道を開くPRに取り組んでいます。

問題を削除可能にすることに反対している人々へ：問題ありませんが、編集履歴の削除を許可します。

または、不要な問題を完全に非表示にして、管理者が非表示の問題を表示するオプションを追加するのはどうでしょうか。

これにより、法的に危険なコンテンツを自分のサイトから削除できないという問題と、問題リストを整理することができないという問題の両方が修正されます。

これにより、法的に危険なコンテンツを自分のサイトから削除できないという問題の両方が修正されます。

@DarkWiiPlayerは、ペドポルノ画像などの潜在的に違法なコンテンツがサーバードライブで引き続き利用可能であり、警察官からのサービスの要求されたチェックによってアクセスできることです...

問題を隠す：重複した問題や雑然としたものを持ちたくない人にとっては問題ありません。問題の履歴には、ラベルの追加と削除、人の変更、意思決定の変更が含まれます。
ただし、サーバーのディスクに保存されている違法なコンテンツについては問題ありません...

@DarkWiiPlayerは、ペドポルノ画像などの潜在的に違法なコンテンツがサーバードライブで引き続き利用可能であり、警察官からのサービスの要求されたチェックによってアクセスできることです...

それは良い点です。 「警察に見られなくても大丈夫」という視点で見ていましたが、ランダムに見つけた人からサイトの所有者に危害を加える理由はさまざまです。そのようなコンテンツを意図的にアップロードし、警察に通報します。

私はまだ隠された問題は何もないよりはましだと思います、そして問題を編集してその編集履歴をスクラブすることと組み合わせて、それはまだ機能するでしょう。

ただし、理想的には、問題を本当に「削除」するオプションは、すべてのデータをスクラブしてDBで「削除済み」に設定することを意味する場合でも、最善の解決策になります。

それは良い点です。

ありがとう。

「警察が見たことがなければ大丈夫」という観点から見ていたのではないでしょうか。

残念ながら、ストレージメディアに違法なファイルがある場合は、そのようには機能しません... URLで公開されていなくても、レポートが作成されてチェックが行われると、問題はありません。どのくらいの「しかし、それはユーザーがアップロードしたコンテンツです」と言うことができます...

これを行う理由のリストに追加するには：私は現在、他の2人の共同作業者とプライベートリポジトリで作業を整理しているため、現在、私たちのコミュニケーションには、公開しない詳細が含まれています。 ただし、将来、プロジェクトを公開することを決定したときに、リポジトリが公開される可能性があります。 その時点で、プロジェクトの可視性を公開して

いつかこの機能を見るのは素晴らしいことですが、とにかくgiteaのすべての作業に感謝し、素晴らしい作業を続けてください！