Gitea: Administrator situs harus memiliki UI untuk menghapus masalah di panel admin

~Seperti yang kami katakan di gitter, saya rasa tidak ada persyaratan untuk ini dan hampir semua perangkat lunak git Host tidak mengizinkan untuk menghapus masalah.~

IMHO itu bukan bug, ini fitur. Itu memastikan bahwa tidak ada yang memanipulasi visibilitas masalah.

Saya tidak melihat masalahnya, jika masalahnya adalah siapa pun dapat menghapusnya, mengapa tidak melihat ke "pemilik" atau orang yang benar-benar membuat masalah sejak awal?

Maksud saya katakanlah saya membuat ini, dan kemudian saya memikirkannya dan tahu bahwa itu adalah kebutuhan untuk itu atau permintaan saya bodoh atau alasan lain apa pun yang akan membuat saya menghapusnya alih-alih hanya terjadi tanpa alasan.

Itu tidak masuk akal sama sekali di mataku

Masalah kemudian terbukti "bodoh" dan ditutup sangat membantu! Katakanlah seseorang memiliki keraguan atau masalah yang sama, masalah tertutup adalah "dokumentasi" tentang sesuatu yang kemudian terbukti tidak menjadi masalah, dan jika pembuat masalah menambahkannya, itu akan berisi juga petunjuk tentang cara menyelesaikannya.

Satu-satunya kasus di mana saya melihat menghapus masalah masuk akal adalah dalam kasus konten ilegal. Dalam hal ini, hapus saja komentar atau edit masalah agar tidak memiliki hal-hal ilegal.

Saya dapat melihat apa maksud Anda, tetapi saya masih tidak setuju dalam kasus saya, saya satu-satunya yang menjalankan repositori saya, itulah sebabnya saya melewatkan fungsi itu, hapus hal-hal yang tidak harus ada di sana

Jika Anda membuat masalah kesalahan saya, Anda bisa mengubah judul & isi menjadi Invalid dan menutupnya

Saya masih tidak menyukainya, tetapi saya melihat tidak ada yang setuju dengan saya.

Di mataku itu najis

Najis ya, tapi konsisten

Ketika Anda misalnya menguji ISSUE_TEMPLATE atau mencoba memahami alur proyek, akan sangat membantu jika Anda dapat menghapus masalah Anda sendiri ...

Setidaknya ketika Anda adalah pemilik repositori.

Fitur ini harus tersedia karena pemilik repositori harus memutuskan alur kerja apa yang cocok untuk proyeknya.

Pemiliknya juga bisa menghapusnya dari db :)

Spammer meninggalkan masalah dengan iklan dan saya sebagai admin tidak dapat menghapusnya ️ Harus membersihkan DB setiap saat...

Administrator situs harus memiliki izin untuk menghapus masalah pada panel admin untuk memelihara situs dengan lebih mudah

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Akan ditutup jika tidak ada aktivitas lebih lanjut selama 2 minggu ke depan. Terima kasih atas kontribusi Anda.

Satu kekhawatiran yang belum diangkat, adalah bahwa beberapa konten mungkin memerlukan penghapusan karena alasan hukum. Katakanlah, misalnya bahwa pengguna X memposting beberapa hal yang benar- benar ilegal dalam suatu masalah. Tentu saja, akun mereka dihentikan secara instan, tetapi sekarang administrator situs memiliki konten ilegal di situs mereka dan tidak dapat menghapusnya.

Harap perhatikan juga bahwa tidak selalu administrator tahu cara menghapus masalah dari database; opsi untuk melakukan ini dari dalam UI adalah suatu keharusan kecuali jika administrator dapat mempercayai pengguna mereka 100% (yang jarang terjadi).

tidak selalu administrator tahu cara menghapus masalah dari database;

Saya ingin menghapus permintaan tarik. Sebelum GUI tersedia, apakah SQL berikut ini cukup baik?

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

Dengan asumsi nomor di akhir URL permintaan tarik adalah 10
http://localhost :3200/org_name/repo_name/pulls/10

Hanya sedikit pendapat, tetapi inilah daftar hal-hal yang menurut saya harus dihapus daripada ditutup:

• Masalah yang berisi konten ilegal, menyinggung, atau tidak diinginkan.
• Konten yang sama sekali tidak terkait tanpa relevansi dengan proyek apa pun.
• Beriklan untuk proyek lain (serupa)
• Bahasa yang kuat yang penulis tolak untuk direndahkan

Hal-hal yang bisa saja ditutup, tetapi beberapa pengelola dan/atau administrator mungkin masih ingin menghapus untuk menjaga jaminan simpanan yang lebih bersih:

• Masalah duplikat yang tidak menambahkan informasi baru
• Kritik tanpa dasar atau saran untuk perbaikan la ur s0ftware suxx

Saya harap ini menggarisbawahi poin yang sering kali masuk akal, baik bagi administrator dan pengelola repositori untuk menghapus masalah sepenuhnya dalam situasi tertentu.

Masalah yang dihapus dari DB, bagaimana cara memperbaikinya sekarang?

Sebagai server repo git yang dihosting sendiri, saya juga berpikir administrator situs harus dapat mengizinkan pemilik repositori untuk melakukan "apa pun yang mereka suka".

Sebagai contoh, saya adalah pemilik server saya (dan bahkan jika saya bukan tetapi memiliki opsi yang diaktifkan untuk melakukan itu, itu akan sama), dan saya juga ingin sebagai pemilik repo saya, untuk membuka masalah sendiri untuk menunjukkan kepada orang lain pekerjaan yang saya lakukan dari waktu ke waktu dan bahwa saya menambahkan hal-hal yang berguna, bukan hanya omong kosong bodoh (hanya karena 90% orang yang saya kenal tidak pernah menonton sejarah komit dan komit yang membuktikan ketekunan saya dan hanya mengatakan " 'kamu lakukan sepanjang hari? kode tidak berguna bodoh? ").

Namun ketika saya mengerjakan masalah saya sendiri (dan juga 90% dari Anda mungkin melakukannya setidaknya sekali) biasanya tidak tahu di mana harus meletakkan barang-barang bahkan di bawah skema label saya sendiri, jadi saya cenderung menambahkan label, lalu menghapusnya dan tetapkan masalah di bawah label lain, dan seterusnya hingga "riwayat masalah" saya terlihat seperti ini ...

Akan sangat menyenangkan untuk dapat menghapus keragu-raguan jelek itu dan memulai masalah baru (atau setidaknya menghapus "riwayat label" dari keraguan saya tentang apa yang akan terjadi)...

Masalah yang dihapus dari DB, bagaimana cara memperbaikinya sekarang?

Saya sebenarnya menemukan ini setelah saya memiliki masalah yang sama. Buka tabel repository dari database Anda. Jumlah terbitan terbuka adalah pengurangan dari 2 kolom num_issues dan num_closed_issues . Saya mengubah 47 num_issues menjadi 46 dan itu memperbarui hitungannya.

@DJFraz
Penurunan num_issues menyebabkan kesalahan 500 ketika mencoba membuat masalah baru, saya harus meningkatkan num_closed_issues sebagai gantinya.

Mengubah num_closed_issues juga bukan ide yang bagus :) Gitea memperbaruinya sesuai dengan tabel masalah.
Jadi itu baik menghapus masalah dan kemudian memastikan bahwa num_issues + 1 tidak akan bertentangan dengan indeks masalah yang ada atau hanya menutup masalah dan mengosongkan kontennya.

:point_up: itulah mengapa penghapusan masalah tidak diterapkan. Untuk alasan kinerja, jumlah masalah di-cache ( num_issues ) di DB, nomor ini juga digunakan untuk Nomor Masalah berikutnya ( num_issues + 1 ).

Seseorang dapat menduplikasi nilai ini di DB dan memiliki last_issue_nr atau next_issue_nr sebagai perbaikan. Atau seseorang dapat menambahkan hidden -boolean ke tabel masalah. Dalam kasus terakhir, masalahnya hanya disembunyikan dari UI (dan API), tetapi nanti dapat dirujuk jika perlu (alasan hukum disebutkan sebelumnya di utas)

Hanya 2 sen saya

nomor ini juga digunakan untuk Nomor Edisi berikutnya ( num_issues + 1 ).

Tidak terlalu. Saat ini SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

itulah mengapa menghapus masalah tidak diterapkan

Tidak, itu sebabnya Anda tidak boleh mengacaukannya secara manual :)
Saya tidak peduli dengan alasan, saya ingin kontrol penuh atas situs saya, fitur ini harus diterapkan.

ini diperlukan untuk instalasi gitea yang tersedia di publik terutama jika Anda telah menjadi sasaran spam.

bagi saya fitur close harus untuk menutup masalah yang terkait dengan proyek dan tidak digunakan untuk menutup spam yang tidak terkait yang sebaiknya dihapus.

Kita harus menyimpan index pada tabel repositori atau sesuatu yang lain.

Kita harus menyimpan index pada tabel repositori atau sesuatu yang lain.

Itu pasti terdengar seperti solusi untuk masalah indeks pembaruan juga, selama xorm mendukung SELECT FOR UPDATE pada semua dbs kami. Saya pikir itu benar, bukan?

Mengenai pembuatan nilai sekuensial yang harus berurutan (yaitu tidak ada lubang), dalam proyek yang saya lakukan sejak lama, kami memiliki tabel terpisah untuk menghasilkannya. misalnya:

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

Dengan cara ini, untuk menghitung edisi berikutnya #, kami melakukan hal berikut:

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)

Dengan cara ini, kami hanya menghasilkan satu kunci untuk menambahkan masalah (yaitu baris repositori yang sebenarnya tidak dikunci untuk sisa transaksi). Transaksi lain yang mencoba menambahkan baris akan dikunci menunggu UPDATE pertama diselesaikan sehingga tidak ada kemungkinan duplikat. Jika transaksi pertama dibatalkan, transaksi kedua akan mendapatkan nilai berikutnya yang benar untuk itu.

Ini juga akan memastikan bahwa tidak ada nilai yang digunakan kembali, meskipun kami menghapus edisi terbaru.

@guillep2k kedengarannya lebih baik.

@lunny solusi yang diusulkan oleh @guillep2k tampaknya sah seperti bos; tetapi seperti yang dicatat @DJFraz pada 27 Agustus 2019, karena penghitung masalah dihitung runtime tetapi kemudian disimpan dalam basis data untuk caching, menurut Anda bagaimana penanganannya harus diterapkan?
Terima kasih.

@lunny solusi yang diusulkan oleh @guillep2k tampaknya sah seperti bos; tetapi seperti yang dicatat @DJFraz pada 27 Agustus 2019, karena penghitung masalah dihitung runtime tetapi kemudian disimpan dalam basis data untuk caching, menurut Anda bagaimana penanganannya harus diterapkan?

Ini hanya masalah menghitung ulang nilai "cache", seperti yang kita lakukan ketika kita membuka/menutup masalah apa pun.

Masalah dalam komentar itu adalah bahwa pengguna berusaha menghapus baris tanpa memperbarui kolom yang sesuai untuk mencerminkan perubahan.

Masalah dalam komentar itu adalah bahwa pengguna berusaha menghapus baris tanpa memperbarui kolom yang sesuai untuk mencerminkan perubahan.

Jadi, techincally ... itu adalah mungkin untuk _manually_ hal hapus dari database dan pergi dengan itu tanpa merusak?

Jadi, techincally ... itu adalah mungkin untuk _manually_ hal hapus dari database dan pergi dengan itu tanpa merusak?

Ada masalah nomor masalah yang digunakan kembali. Jika Anda menghapus komentar buruk #999 dan kebetulan menjadi yang terakhir, komentar baik berikutnya akan mendapatkan nomor #999 juga, yaitu tidak, tidak, tidak. Komentar baru seharusnya sebenarnya #1000 dan nomor #999 harus dibiarkan "tidak digunakan". Tapi saya sedang mengerjakan PR yang akan memperbaiki masalah ini dan membuka jalan untuk menghapus komentar di masa mendatang.

Untuk orang-orang yang menentang membuat masalah dapat dihapus: baiklah, tetapi kemudian izinkan untuk menghapus riwayat edit.

sebagai alternatif: Bagaimana dengan sepenuhnya menyembunyikan masalah yang tidak diinginkan dari tampilan dan menambahkan opsi bagi administrator untuk melihat masalah tersembunyi?

Ini akan memperbaiki masalah dengan tidak dapat menghapus konten yang berbahaya secara hukum dari situs Anda sendiri dan mengacaukan daftar masalah

Ini akan memperbaiki masalah dengan tidak dapat menghapus konten yang berbahaya secara hukum dari situs Anda sendiri

@DarkWiiPlayer masalahnya adalah, bahwa konten yang berpotensi ilegal, seperti gambar porno pedo, masih tersedia di drive server Anda, dan dapat diakses dengan pemeriksaan yang diminta pada layanan Anda dari petugas polisi...

Menyembunyikan masalah: baik untuk orang yang tidak ingin memiliki masalah duplikat dan hal-hal yang berantakan dengan riwayat masalah yang penuh dengan penambahan dan penghapusan label dan orang-orang dan keputusan yang berubah pikiran.
Namun tidak baik untuk konten ilegal yang disimpan di disk server...

@DarkWiiPlayer masalahnya adalah, bahwa konten yang berpotensi ilegal, seperti gambar porno pedo, masih tersedia di drive server Anda, dan dapat diakses dengan pemeriksaan yang diminta pada layanan Anda dari petugas polisi...

Itu poin yang bagus. Saya kira saya melihatnya dari perspektif bahwa "Jika polisi tidak pernah melihatnya, Anda baik-baik saja", tetapi ada berbagai alasan mengapa itu mungkin masih membahayakan pemilik situs, dari seseorang yang secara acak menemukannya hingga seseorang sengaja mengunggah konten semacam itu, lalu memberi tahu polisi.

Saya masih berpikir masalah tersembunyi lebih baik daripada tidak sama sekali, dan dalam kombinasi dengan mengedit masalah dan menghapus riwayat editnya, itu akan tetap berfungsi.

Idealnya, opsi untuk benar-benar "menghapus" masalah, meskipun ini hanya berarti menghapus semua data dan menyetelnya ke "dihapus" di DB, akan menjadi solusi terbaik.

Itu poin yang bagus.

Terima kasih.

Saya kira saya melihatnya dari perspektif bahwa "Jika polisi tidak pernah melihatnya, Anda baik-baik saja"

Sayangnya itu tidak bekerja seperti itu ketika Anda memiliki file ilegal di media penyimpanan Anda ... bahkan jika mereka tidak tersedia untuk umum melalui URL, jika laporan dibuat dan cek diajukan, Anda kacau, tidak peduli berapa banyak "tapi itu konten yang diunggah pengguna" yang bisa Anda katakan ...

Untuk menambah daftar alasan untuk memiliki ini: Saya saat ini mengatur pekerjaan di repo pribadi dengan 2 kolaborator lain, sehingga komunikasi kami saat ini mencakup detail yang tidak akan kami ungkapkan secara publik. Namun kemungkinan repo akan dipublikasikan di masa mendatang ketika kami memutuskan untuk merilis proyek secara terbuka. Pada saat itu akan sangat bagus untuk memiliki cara untuk menghapus bagian masalah sepenuhnya sebelum mengatur visibilitas proyek ke publik dan dengan demikian membukanya dengan itu.

Akan sangat menyenangkan untuk melihat fitur ini di beberapa titik, bagaimanapun juga terima kasih untuk semua pekerjaan di gitea dan terus bekerja dengan baik!