Gitea: Los administradores del sitio deben tener una interfaz de usuario para eliminar problemas en el panel de administración

~ Como dijimos en gitter, no creo que exista un requisito para esto y casi todo el software de host de git no permite eliminar el problema. ~

En mi humilde opinión, no es un error, es una característica. Se asegura de que nadie manipule la visibilidad del problema.

No veo el problema, si el problema es que cualquiera puede eliminarlo, ¿por qué no mirar al "propietario" o al que realmente hizo el problema desde el principio?

Quiero decir, digamos que hice esto, y luego lo pienso y sé que era necesario o que mi solicitud era estúpida o cualquier otra razón que me haría eliminarlo en lugar de simplemente tener lugar para nada.

Eso no tiene ningún sentido en mis ojos

¡Los problemas que luego resultan ser "estúpidos" y se cierran son muy útiles! Digamos que alguien tiene la misma duda o problema, el problema cerrado es "documentación" sobre algo que luego demostró no ser un problema, y ​​si el creador del problema lo agrega, también contendrá instrucciones sobre cómo resolverlo.

El único caso en el que veo que eliminar problemas tiene sentido es en el caso de contenido ilegal. En ese caso, simplemente elimine el comentario o edite el problema para no tener contenido ilegal.

Puedo ver cuál es su punto, pero todavía no estoy de acuerdo en mi caso, soy el único que ejecuta mi repositorio, es por eso que echo de menos esa función, elimine las cosas que no tienen que estar allí.

Si crea un problema por mi error, puede simplemente cambiar el título y el cuerpo a Invalid y cerrarlo

Todavía no me gusta, pero veo que ninguno de los otros está de acuerdo conmigo.

En mis ojos eso es inmundo

Inmundo sí, pero consistente 🙂

Cuando, por ejemplo, está probando un ISSUE_TEMPLATE o tratando de comprender el flujo del proyecto, sería muy útil poder eliminar sus propios problemas ...

Al menos cuando eres el propietario del repositorio.

Esta función debería estar disponible porque depende del propietario del repositorio decidir qué flujo de trabajo es adecuado para su proyecto.

El propietario también podría eliminarlo de la base de datos :)

Los spammers están dejando problemas con los anuncios y yo, como administrador, no puedo eliminarlos 🤦‍♂️ Tuve que limpiar DB cada vez ...

Los administradores del sitio deben tener permisos para eliminar los problemas en el panel de administración para mantener el sitio más fácilmente

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se realizan más actividades durante las próximas 2 semanas. Gracias por sus aportaciones.

Una preocupación que aún no se ha planteado es que algunos contenidos pueden requerir la eliminación por razones legales. Digamos, por ejemplo, que el usuario X publica cosas realmente ilegales en un problema. Por supuesto, su cuenta se cancela instantáneamente, pero ahora el administrador del sitio tiene contenido ilegal en su sitio y no puede eliminarlo.

También tenga en cuenta que no siempre el administrador sabe cómo eliminar un problema de la base de datos; una opción para hacer esto desde la interfaz de usuario es imprescindible a menos que los administradores puedan confiar en sus usuarios al 100% (lo que rara vez es el caso).

no siempre el administrador sabe cómo eliminar un problema de la base de datos;

Me gustaría eliminar una solicitud de extracción. Antes de que la GUI esté disponible, ¿el siguiente SQL es suficientemente bueno?

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

Suponiendo que el número al final de la URL de la solicitud de extracción es 10
http: // localhost : 3200 / org_name / repo_name / pulls / 10

Solo un poco de opinión, pero aquí hay una lista de cosas que creo que deberían eliminarse en lugar de cerrarse:

• Problemas que incluyen contenido ilegal, ofensivo o no deseado.
• Contenido completamente no relacionado y sin relevancia para el proyecto en absoluto.
• Publicidad para otros proyectos (similares)
• Lenguaje fuerte que el autor se niega a atenuar.

Cosas que podrían simplemente cerrarse, pero algunos mantenedores y / o administradores aún pueden querer eliminar para mantener una acumulación más limpia:

• Problemas duplicados que no agregan información nueva
• Críticas sin fundamento ni sugerencias de mejora a la ur s0ftware suxx

Espero que esto subraye el punto de que a menudo tiene sentido, tanto para los administradores como para los encargados del mantenimiento del repositorio, eliminar los problemas por completo en determinadas situaciones.

Problema eliminado de DB, ¿cómo solucionarlo ahora?

Como servidor de repositorios git autohospedado, también creo que el administrador del sitio debería poder permitir que los propietarios del repositorio hagan "lo que quieran".

Como ejemplo, soy el propietario de mi servidor (e incluso si no lo fuera pero tuviera las opciones habilitadas para hacerlo, sería lo mismo), y también me gustaría, como propietario de mi repositorio, abrir problemas yo mismo. para mostrarle a otras personas el trabajo que hago a lo largo del tiempo y que agrego cosas útiles, no solo estupideces (solo porque el 90% de las personas que conozco nunca miro cometen historial y se comprometen a contrarrestar mi diligencia y solo dicen "'diablos lo haces todo el día? estúpido código inútil? ").

Sin embargo, cuando trabajo en mis propios problemas (y también el 90% de ustedes probablemente lo hizo al menos una vez), generalmente no sé dónde poner las cosas, incluso bajo mi propio esquema de etiquetas, por lo que tiendo a agregar una etiqueta, luego eliminarla y asignar el problema con otra etiqueta, y así sucesivamente hasta que mi "historial de problemas" se parezca a esto ...

Sería muy bueno poder eliminar esa indecisión de mierda y comenzar un nuevo problema (o al menos eliminar el "historial de etiquetas" de mi indecisión de qué ser) ...

Problema eliminado de DB, ¿cómo solucionarlo ahora?

De hecho, me di cuenta de esto después de tener el mismo problema. Vaya a la tabla repository de su base de datos. El recuento de problemas abiertos es el sustraendo de las 2 columnas num_issues y num_closed_issues . Cambié 47 num_issues a 46 y actualicé el recuento.

@DJFraz
Disminuir num_issues causa el error 500 al intentar crear un nuevo problema, tuve que aumentar num_closed_issues lugar.

Cambiar num_closed_issues tampoco fue una gran idea :) Gitea lo actualiza de acuerdo con la tabla de problemas.
Por lo tanto, se trata de eliminar problemas y luego asegurarse de que num_issues + 1 no entre en conflicto con el índice de problemas existente o simplemente cerrar un problema y vaciar su contenido.

: point_up: es exactamente por eso que no se implementa la eliminación de problemas. Por razones de rendimiento, el número de problemas se almacena en caché ( num_issues ) en la base de datos, este número también se utiliza para determinar cuál será el próximo número de problema ( num_issues + 1 ).

Se podría duplicar este valor en la base de datos y tener last_issue_nr o next_issue_nr como solución. O se podría agregar un hidden -boolean a la tabla de problemas. En el último caso, el problema solo está oculto en la interfaz de usuario (y la API), pero luego se puede hacer referencia a él si es necesario (las razones legales se mencionaron anteriormente en el hilo)

Solo mis 2 centavos

este número también se usa para lo que será el próximo número de emisión ( num_issues + 1 ).

No exactamente. Actualmente es SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

esa es exactamente la razón por la que no se implementa la eliminación de problemas

No, es por eso que no deberías meterte con ellos manualmente :)
No me importan las razones, quiero un control total sobre mi sitio, esta función debería implementarse.

esto es necesario para las instalaciones de gitea disponibles en público, especialmente si ha sido blanco de spam.

para mí, la función de cierre debe ser para cerrar un problema relacionado con el proyecto y no usar para cerrar un correo no deseado no relacionado que es mejor eliminar.

Deberíamos almacenar el último index en la tabla de repositorio o algo más.

Deberíamos almacenar el último index en la tabla de repositorio o algo más.

Eso definitivamente también suena como una solución al problema del índice de actualización, siempre que xorm admita SELECT FOR UPDATE en todas nuestras bases de datos. Creo que sí, ¿no?

Con respecto a la creación de valores secuenciales que deben ser consecutivos (es decir, sin agujeros), en un proyecto que hice hace mucho tiempo teníamos una tabla separada para generarlos. p.ej:

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 esta manera, para calcular el siguiente número de problema, hicimos lo siguiente:

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 esta manera, producimos solo un bloqueo para agregar un problema (es decir, la fila del repositorio real no se bloqueó para el resto de la transacción). Otras transacciones que intenten agregar filas se bloquearán esperando que se resuelva la primera ACTUALIZACIÓN, por lo que no habrá posibilidad de duplicados. Si la primera transacción se revierte, la segunda obtendrá el siguiente valor correcto.

Esto también garantizaría que no se reutilicen valores, incluso si eliminamos el último problema.

@ guillep2k eso suena mejor.

La solución de @ guillep2k parece legítima como un jefe; pero como señaló @DJFraz el 27 de agosto de 2019, dado que los contadores de problemas se calculan en tiempo de ejecución pero luego se almacenan en la base de datos para su almacenamiento en caché, ¿cómo crees que se debe implementar el manejo de esos?
Gracias.

La solución de @ guillep2k parece legítima como un jefe; pero como señaló @DJFraz el 27 de agosto de 2019, dado que los contadores de problemas se calculan en tiempo de ejecución pero luego se almacenan en la base de datos para su almacenamiento en caché, ¿cómo crees que se debe implementar el manejo de esos?

Es solo una cuestión de recalcular los valores "almacenados en caché", tal como lo hacemos cuando abrimos / cerramos cualquier problema.

El problema en ese comentario es que el usuario intentó eliminar la fila sin actualizar las columnas apropiadas para reflejar el cambio.

El problema en ese comentario es que el usuario intentó eliminar la fila sin actualizar las columnas apropiadas para reflejar el cambio.

Entonces, técnicamente ... ¿ ES posible _manualmente_ eliminar cosas de la base de datos y salirse con la suya sin romper nada?

Entonces, técnicamente ... ¿ ES posible _manualmente_ eliminar cosas de la base de datos y salirse con la suya sin romper nada?

Existe el problema de la reutilización de los números de emisión. Si elimina el comentario malo #999 y resulta ser el último, el siguiente comentario bueno también obtendrá el número #999 , que es no no no. El nuevo comentario debería ser de hecho #1000 y el número #999 debería dejarse "sin usar". Pero estoy trabajando en un PR que solucionará este problema y allanará el camino para eliminar comentarios en el futuro.

Para las personas que están en contra de que los problemas se puedan eliminar: bien, pero luego permitan eliminar el historial de edición.

alternativamente: ¿Qué tal ocultar completamente los problemas no deseados de la vista y agregar una opción para que los administradores vean los problemas ocultos?

Esto solucionaría tanto el problema de no poder eliminar contenido legalmente peligroso de su propio sitio como eliminar el desorden de la lista de problemas

Esto solucionaría el problema de no poder eliminar contenido legalmente peligroso de su propio sitio

@DarkWiiPlayer, la

Ocultar problemas: está bien para las personas que no quieren tener problemas duplicados y cosas desordenadas con un historial de problemas lleno de agregar y eliminar etiquetas y personas y decisiones que cambian de opinión.
Sin embargo, no está bien para el contenido ilegal almacenado en los discos del servidor ...

@DarkWiiPlayer, la

Ese es un buen punto. Supongo que lo estaba viendo desde la perspectiva de que "si la policía nunca lo ve, estás bien", pero hay una variedad de razones por las que eso podría dañar al propietario del sitio, desde alguien que lo encuentra al azar hasta alguien subir intencionalmente dicho contenido y luego informar a la policía.

Sigo pensando que los problemas ocultos son mejores que nada, y en combinación con la edición del problema y la limpieza de su historial de edición, aún funcionaría.

Sin embargo, idealmente, una opción para "eliminar" verdaderamente el problema, incluso si esto solo significa eliminar todos los datos y configurarlos como "eliminados" en la base de datos, sería la mejor solución.

Ese es un buen punto.

Gracias.

Supongo que lo estaba viendo desde la perspectiva de que "si la policía nunca lo ve, estás bien".

Desafortunadamente, no funciona así cuando tienes archivos ilegales en tu medio de almacenamiento ... incluso si no están disponibles públicamente a través de una URL, si se hace un informe y se archiva una verificación, estás jodido, no importa. cuánto "pero eso es contenido subido por el usuario" puede decir ...

Para agregar a la lista de razones para tener esto: actualmente estoy organizando el trabajo en un repositorio privado con otros 2 colaboradores, por lo que nuestra comunicación actualmente incluye detalles que no revelaríamos públicamente. Sin embargo, es probable que el repositorio se haga público en un momento futuro cuando decidamos lanzar abiertamente el proyecto. En ese momento, sería genial tener una forma de borrar la sección de problemas por completo antes de establecer la visibilidad del proyecto al público y, por lo tanto, salir a la luz.

Sería genial ver esta función en algún momento, de todos modos gracias por todo el trabajo en gitea y sigan con el gran trabajo.