Gitea: Os administradores do site devem ter IU para excluir problemas no painel de administração

~ Como dissemos no gitter, não acho que haja um requisito para isso e quase todo o software host git não permite a exclusão do problema. ~

IMHO não é um bug, é um recurso. Isso garante que ninguém manipule a visibilidade do problema.

Não vejo qual é o problema, se o problema é que qualquer um pode apagá-lo, por que não olhar para o "dono" ou para aquele que realmente fez o problema desde o início?

Quer dizer, digamos que eu fiz isso, e então eu penso sobre isso e sei que foi necessário ou meu pedido foi estúpido ou qualquer outro motivo que me faria removê-lo em vez de simplesmente acontecer de graça.

Isso não faz sentido nenhum aos meus olhos

Questões que então se revelam "estúpidas" e fecham são muito úteis! Digamos que alguém tenha a mesma dúvida ou problema, o problema encerrado é a "documentação" sobre algo que então provou não ser um problema e, se o criador do problema adicionar, também conterá instruções sobre como resolvê-lo.

O único caso em que vejo que a exclusão de problemas faz sentido é no caso de conteúdo ilegal. Nesse caso, apenas exclua o comentário ou edite o problema para não ter o material ilegal.

Eu posso ver qual é o seu ponto, mas ainda não concordo no meu caso eu sou o único que executa meu repositório é por isso que sinto falta dessa função deletar coisas que não precisam estar lá

Se você criar um problema meu erro, você pode simplesmente alterar o título e o corpo para Invalid e fechá-lo

Ainda não gosto, mas não vejo nenhum outro concordar comigo.

Aos meus olhos isso é impuro

Imundo sim, mas consistente 🙂

Quando você está, por exemplo, testando um ISSUE_TEMPLATE ou tentando entender o fluxo do projeto, seria muito útil ser capaz de excluir seus próprios problemas ...

Pelo menos quando você é o proprietário do repositório.

Este recurso deve estar disponível porque cabe ao proprietário do repositório decidir qual fluxo de trabalho é adequado para seu projeto.

O proprietário também pode simplesmente excluí-lo do banco de dados :)

Os spammers estão deixando problemas com os anúncios e eu, como administrador, não posso excluí-los 🤦‍♂️ Tive que limpar o banco de dados todas as vezes ...

Os administradores do site devem ter permissões para excluir os problemas no painel de administração para manter o site mais fácil

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele estará fechado se nenhuma outra atividade ocorrer durante as próximas 2 semanas. Obrigado por suas contribuições.

Uma preocupação que ainda não foi levantada é que alguns conteúdos podem exigir remoção por motivos legais. Digamos, por exemplo, que o usuário X poste algumas coisas realmente ilegais em uma edição. Claro, sua conta é encerrada instantaneamente, mas agora o administrador do site tem conteúdo ilegal em seu site e não pode excluí-lo.

Observe também que nem sempre o administrador sabe como remover um problema do banco de dados; uma opção para fazer isso de dentro da interface do usuário é uma obrigação, a menos que os administradores possam confiar em seus usuários 100% (o que raramente é o caso).

nem sempre o administrador sabe como remover um problema do banco de dados;

Eu gostaria de excluir uma solicitação de pull. Antes de a GUI estar disponível, o seguinte SQL é bom o suficiente?

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

Supondo que o número no final do URL de solicitação de pull seja 10
http: // localhost : 3200 / org_name / repo_name / pulls / 10

Apenas um pouco de opinião, mas aqui está uma lista de coisas que acredito que devam ser excluídas em vez de fechadas:

• Problemas com conteúdo ilegal, ofensivo ou indesejado.
• Conteúdo totalmente não relacionado e sem relevância para o projeto.
• Publicidade para outros projetos (semelhantes)
• Linguagem forte que o autor se recusa a moderar

Coisas que poderiam ser fechadas, mas alguns mantenedores e / ou administradores ainda podem querer excluir para manter um backlog mais limpo:

• Problemas duplicados que não adicionam novas informações
• Críticas sem fundamento ou sugestões de melhorias à la ur s0ftware suxx

Espero que isso reforce o ponto de que geralmente faz sentido, tanto para administradores quanto para mantenedores do repositório, deletar problemas completamente em certas situações.

Removido o problema do banco de dados, como consertar isso agora?

Como um servidor de repositório git auto-hospedado, também acho que o administrador do site deve ser capaz de permitir que os proprietários do repositório façam "o que quiserem".

Por exemplo, eu sou o proprietário do meu servidor (e mesmo se eu não fosse, mas tivesse as opções habilitadas para fazer isso, seria o mesmo), e eu gostaria também, como proprietário do meu repo, de abrir os problemas sozinho para mostrar a outras pessoas o trabalho que faço ao longo do tempo e que adiciono coisas úteis, não apenas merdas estúpidas (só porque 90% das pessoas que eu conheço nunca assistem ao histórico de commits e contra-commits provando minha diligência e apenas dizendo "o que diabos você faz o dia todo? código inútil estúpido? ").

No entanto, quando eu trabalho em meus próprios problemas (e também 90% de vocês provavelmente fizeram pelo menos uma vez) geralmente não sei onde colocar as coisas, mesmo sob meu próprio esquema de rótulo, então eu tendo a adicionar um rótulo, em seguida, removê-lo e atribuir o problema em outro rótulo e assim por diante até que meu "histórico de problemas" se pareça com isto ...

Seria muito bom poder apagar essa indecisão de merda e começar um novo problema (ou pelo menos apagar o "histórico do rótulo" da minha indecisão sobre o que ser) ...

Removido o problema do banco de dados, como consertar isso agora?

Na verdade, descobri isso depois que tive o mesmo problema. Vá para a tabela repository do seu banco de dados. A contagem de problemas em aberto é o subtraendo das 2 colunas num_issues e num_closed_issues . Mudei 47 num_issues para 46 e ele atualizou a contagem.

@DJFraz
Diminuir num_issues causa o erro 500 ao tentar criar um novo problema. Em vez disso, tive que aumentar num_closed_issues .

Alterar num_closed_issues também não foi uma boa ideia :) Gitea atualiza de acordo com a tabela de problemas.
Portanto, está removendo problemas e, em seguida, certificando-se de que num_issues + 1 não entrará em conflito com o índice de problemas existente ou apenas fechando um problema e esvaziando seu conteúdo.

: point_up: é exatamente por isso que a exclusão de problemas não foi implementada. Por motivos de desempenho, o número de problemas é armazenado em cache ( num_issues ) no banco de dados, esse número também é usado para qual será o próximo número do problema ( num_issues + 1 ).

Alguém poderia duplicar este valor no banco de dados e ter last_issue_nr ou next_issue_nr como uma correção. Ou pode-se adicionar um hidden -booleano à tabela de problemas. No último caso, o problema só fica oculto na IU (e na API), mas pode ser referenciado posteriormente, se necessário (motivos legais foram mencionados anteriormente no tópico)

Só meus 2 centavos

este número também é usado para qual será o próximo número do problema ( num_issues + 1 ).

Não exatamente. Atualmente é SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

é exatamente por isso que a exclusão de problemas não é implementada

Não, é por isso que você não deve mexer com eles manualmente :)
Não me importo com os motivos, quero controle total sobre meu site, esse recurso deve ser implementado.

isso é necessário para instalações do gitea disponíveis em público, especialmente se você foi alvo de spam.

para mim, o recurso de fechamento deve ser para fechar um problema relacionado ao projeto e não usar para fechar um spam não relacionado que deve ser excluído.

Devemos armazenar o último index na tabela do repositório ou em outro lugar.

Devemos armazenar o último index na tabela do repositório ou em outro lugar.

Isso definitivamente soa como uma solução para o problema do índice de atualização também, contanto que o xorm suporte SELECT FOR UPDATE em todos os nossos bancos de dados. Acho que sim, não é?

Em relação à criação de valores sequenciais que precisam ser consecutivos (ou seja, sem buracos), em um projeto que fiz há muito tempo tínhamos uma tabela separada para gerá-los. por exemplo:

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

Dessa forma, para calcular o próximo número de problema, fizemos o seguinte:

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)

Dessa forma, produzimos apenas um bloqueio para adicionar um problema (ou seja, a linha do repositório real não foi bloqueada para o restante da transação). Outras transações que tentarem adicionar linhas serão bloqueadas, aguardando a resolução do primeiro UPDATE, sem chance de duplicatas. Se a primeira transação for revertida, a segunda obterá o próximo valor correto para ela.

Isso também garantiria que nenhum valor fosse reutilizado, mesmo se excluirmos o problema mais recente.

@ guillep2k isso soa melhor.

A solução @ guillep2k parece legítima como um chefe; mas, como @DJFraz observou em 27 de agosto de 2019, como os contadores de problemas são calculados em tempo de execução, mas depois armazenados no banco de dados para cache, como você acha que o manuseio deles deve ser implementado?
Obrigado.

A solução @ guillep2k parece legítima como um chefe; mas, como @DJFraz observou em 27 de agosto de 2019, como os contadores de problemas são calculados em tempo de execução, mas depois armazenados no banco de dados para cache, como você acha que o manuseio deles deve ser implementado?

É apenas uma questão de recalcular os valores "em cache", assim como fazemos quando abrimos / fechamos qualquer problema.

O problema nesse comentário é que o usuário tentou excluir a linha sem atualizar as colunas apropriadas para refletir a alteração.

O problema nesse comentário é que o usuário tentou excluir a linha sem atualizar as colunas apropriadas para refletir a alteração.

Então, tecnicamente ... É possível deletar _manualmente_ coisas do banco de dados e sair ileso sem quebrar nada?

Então, tecnicamente ... É possível deletar _manualmente_ coisas do banco de dados e sair ileso sem quebrar nada?

Existe o problema dos números de emissão serem reutilizados. Se você deletar o comentário ruim #999 e ele for o último, o próximo comentário bom também receberá o número #999 , que é não, não, não. O novo comentário deve ser de fato #1000 e o número #999 deve ser deixado "não utilizado". Mas estou trabalhando em um PR que resolverá esse problema e abrirá o caminho para a exclusão de comentários no futuro.

Para as pessoas que são contra a possibilidade de excluir problemas: tudo bem, mas permita a exclusão do histórico de edições.

alternativa: Que tal ocultar completamente os problemas indesejados e adicionar uma opção para os administradores verem os problemas ocultos?

Isso resolveria o problema de não ser capaz de excluir conteúdo legalmente perigoso de seu próprio site e desorganizaria a lista de problemas

Isso resolveria o problema de não ser capaz de excluir conteúdo legalmente perigoso de seu próprio site

@DarkWiiPlayer, o que acontece é que o conteúdo potencialmente ilegal, como uma imagem pornográfica de pedo, ainda está disponível na unidade do seu servidor e acessível por meio de uma verificação solicitada de um policial em seus serviços ...

Ocultando problemas: bom para pessoas que não querem ter problemas duplicados e coisas desordenadas com um histórico de problemas cheio de adicionar e remover rótulos e pessoas e decisões que mudam a mente.
Não está bem, entretanto, para conteúdo ilegal armazenado nos discos do servidor ...

@DarkWiiPlayer, o que acontece é que o conteúdo potencialmente ilegal, como uma imagem pornográfica de pedo, ainda está disponível na unidade do seu servidor e acessível por meio de uma verificação solicitada de um policial em seus serviços ...

Este é um bom ponto. Eu acho que estava olhando para isso da perspectiva de que "Se a polícia nunca perceber, você está bem", mas há uma variedade de razões pelas quais isso ainda pode prejudicar o proprietário do site, desde que alguém o encontre aleatoriamente para alguém enviar esse conteúdo intencionalmente e, em seguida, informar a polícia.

Ainda acho que problemas ocultos são melhores do que nada e, em combinação com a edição do problema e a limpeza de seu histórico de edição, ainda funcionaria.

O ideal, porém, é uma opção para realmente "excluir" o problema, mesmo que isso signifique apenas limpar todos os dados e defini-los como "excluídos" no banco de dados, seria a melhor solução.

Este é um bom ponto.

Obrigado.

Acho que estava olhando para isso da perspectiva de que "Se a polícia nunca vir, você está bem"

Infelizmente não funciona assim quando você tem arquivos ilegais em seu meio de armazenamento ... mesmo que eles não estejam publicamente disponíveis através de um URL, se um relatório for feito e um cheque for preenchido, você está ferrado, não importa quanto "mas isso é conteúdo enviado pelo usuário", você pode dizer ...

Para aumentar a lista de motivos para isso: Atualmente, estou organizando um trabalho em um repo privado com 2 outros colaboradores, portanto, nossa comunicação atualmente inclui detalhes que não divulgaríamos publicamente. No entanto, é provável que o repo se torne público no futuro, quando decidirmos lançar abertamente o projeto. Nesse ponto, seria ótimo ter uma maneira de limpar a seção de problemas completamente antes de definir a visibilidade do projeto para o público e, assim, ir ao ar com ele.

Seria ótimo ver esse recurso em algum momento, de qualquer forma, obrigado por todo o trabalho no gitea e continue com o ótimo trabalho!