Site administrators should have UI to delete issues on admin panel

[TimerWolf]

• Gitea version (or commit ref): 6aacf4d
• Git version: 191
• Operating system: Ubuntu Server
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Under issues, why can´t it be optional under the settings for the current repositorie to allow delete an issues if you don´t feel to keep it?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[lunny]

As we said on gitter, I don't think there is a requirement for this and almost all the git host software don't allow to delete issue.

[tboerger]

IMHO it's not a bug, it's a feature. It makes sure that nobody manipulates the issue visibility.

[TimerWolf]

I don´t see the problem, if the problem is that anyone can delete it, why just not look it to "owner" or the one that actully made the issue from the start?

I mean lets say i made this, and then i think about it and know that it was any need for it or my request was stupid or any other reason that would make me remove it insted of just take place for nothing.

Thats make no sense at all in my eyes

[thehowl]

Issues than then prove to be "stupid" and get closed are very helpful! Say someone has the same doubt or problem, the closed issue is "documentation" on something which then proved not to be an issue, and if the issue creator adds it it will contain also instructions on how to solve it.

The only case in which I see deleting issues making sense is in case of illegal content. In that case, just delete the comment or edit the issue to not have the illegal stuff.

[TimerWolf]

I can see what your point is, but i still don´t agree in my case i am the only that run my repositorie thats why i miss that function do delete stuff that don´t has to be there

[bkcsoft]

If you create an issue my mistake, you can just change the title & body to Invalid and close it

[TimerWolf]

I still don´t like it, but i see the none other agree whit me.

In my eyes thats unclean

[bkcsoft]

Unclean yes, but consistent 🙂

[lborgman]

When you are for example testing an ISSUE_TEMPLATE or trying to understand the project flow it would be very helpful to be able to delete your own issues ...

At least when you are the owner of the repository.

[jamesbanogon]

This feature should be available because it's up to the owner of the repository to decide what workflow is suitable for his/her project.

[tboerger]

The owner could also just delete it from the db :)

[Mikanoshi]

Spammers are leaving issues with ads and I as admin cannot delete them 🤦‍♂️ Had to clean DB every time...

[lunny]

Site administrators should have permissions to delete the issues on admin panel for maintaining the site easier

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[DarkWiiPlayer]

One concern that has not been brought up yet, is that some content may require removal for legal reasons. Say, for example that user X posts some really really illegal stuff in an issue. Of course, their account is terminated instantly, but now the site administrator has illegal content on their site and can't delete it.

Also please note that not always the administrator knows how to remove an issue from the database; an option to do this from within the UI is a must unless the administrators can trust their users 100% (which is rarely the case).

[yanOnGithub]

not always the administrator knows how to remove an issue from the database;

I would like to delete a pull request. Before the GUI is available, are the following SQL good enough?

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

Assuming the number at the end of the pull request URL is 10
http://localhost:3200/org_name/repo_name/pulls/10

[DarkWiiPlayer]

Just a bit of opinion, but here's a list of things I believe should be deleted instead of closed:

• Issues containing illegal, offensive or otherwise unwanted content.
• Completely unrelated content with no relevance to the project whatsoeve.
• Advertising for other (similar) projects
• Strong language that the author refuses to tone down

Things that could just be closed, but some maintainers and/or administrators may still want to delete to keep a cleaner backlog:

• Duplicate issues that add no new information
• Criticism without any foundation or suggestions for improvements à la ur s0ftware suxx

I hope this underlines the point that it often makes sense, both for administrators and repository maintainers to delete issues completely in certain situations.

[Mikanoshi]

Removed issue from DB, how to fix this now?

[mjfs]

It is really important to be pragmatic when it comes to futures like this. In an ideal world there would be no need to delete an issue, unfortunately that is not where we all live.

Since one can not be entirely sure from reading the comments (and related issue that is closed) what the current stance is on the implementation of "delete an issue" feature, perhaps the following arguments could help with formulating a position that this feature is needed for API as well as for GUI:

1. The fact is that people make mistakes and by not allowing a clutter free way of undoing certain completely understandable missteps the only result of this is a burden to others. This can manifest as increased complexity exposed to the user, unnecessary filtering of issues, wasted time and focus when going through the issues etc.

2. There are sometimes legal requirements covering data deletion (incl. general ones, such as Right to be forgotten in the EU or obligation to moderate content). Sometimes there is a room for interpretation and implementation can vary, but taking an option off the table from the start is hard to swallow. At the very least it causes unnecessary friction and loss of time.

3. Appropriate authorization scheme should make it possible to allow deletion only for certain roles that even currently already can achieve the same goal, only with a lot less overhead - database level issue deletion is already an option. At the same time audit trail (whichever - database or application level) is the one that should allow reviewing the circumstances, not necessarily application-level visibility.

4. Unfortunately as with other things in life, there are cases when with certain individuals the motives are less than pure. Be it malice, selfishness or some other driver behind it, mitigating unjustified loss of time for an organisation or individual that is the victim in such cases should be key.

5. When testing platform integration, exploring the functionalities etc., it is often a real time safer if one can get to the original state with as few steps as possible. Not allowing for issue deletion again means unnecessary loss of time in this context.

6. Ability to delete an issue is a basic future that users expect from Gitea simply because it is offered as a standard feature in other platforms (e.g. GitLab, Github) and going in the other direction is diverging from an industry standard. This again just leads to unnecessary friction.

7. By not allowing issue deletion, external issue processing now has to handle those special cases, which means unnecessary complexity in the whole chain that Gitea might be a part of (e.g. covering HelpDesk, Resource management, Integration etc.), additional risk of errors and loss of development time.

8. Some features, such as the ones covering the ability to move an issue between repositories can imply an ability to delete an issue. It Does of course depend on the actual implementation, but one could simply create an empty repository, move issue there and then delete the repository.

9. Even Git allows for a deletion of certain steps in various ways, one conclude that in the case of issue management Gitea should try to be consistent with a key part of its internals.

[nicorac]

@mjfs: It was a pleasure to read your thoughts.
I completely agree with all of your points 👍

[lunny]

Since #15599 merged, PRs are welcome!!!

[6543]

v1.15.0 is in freeze and no pulls where made ... moved onto next milestone

[Nixellion]

I just want to +1 for this feature request as well as add another real world example of when it would be really useful.

We're working on a project and we've created a few dozen issues which include different tasks that we had planned to do. Then after a while we've had a lengthy discussion and reevaluation of our project which made those old issues completely irrelevant. We want to just remove all of them and start from scratch. Recreating the repo is not something we'd like to do, because we make use of Wiki which would be lost as well, and we would still want to keep some of the existing issues, and switching repos feels like unnecessary work.

Just Closing all issues would not provide any value to us, it would just leave a lot of clutter in closed issues, completely useless ones. We are not going to waste our time going through all the closed issues trying to find one that might match some new issue, that's just a waste of time.

So we would really like to just delete most of the issues we have, that would be much cleaner solution to our problem. It's a management tool, and IMO it should not enforce any kind of specific workflow when it does not have to.

Thank you, I hope this feature will make it's way into new versions.

[bryanpedini]

Just Closing all issues would not provide any value to use, it would just leave a lot of clutter in closed issues, completely useless ones.

Let me introduce another issue about this issue (sorry for the words trick): duplicate/troll/spam issues.
We get it, just mark it as "duplicate" and perhaps even lock it to collaborators only. But when all the issues have the same or similar title and users are stupid and continue to post du/tri/quadruplicate issues (let's face it, we're talking about the majority here, if GitHub is to be taken as example, the majority of people are stupid and don't even push a single repo, they just sit here and complain and watch) then they would just need to be removed for the sake of us members of the Homo Sapiens Sapiens specie (the intelligent kind) that want to really contribute and we surely don't want to dig through dozens of dozenplicated issues!!

Wait wait wait - yes I used strong words up there - you maybe are part of the intelligent kind of people, but not everybody's you and the majority of the users dictate the behavior that a platform needs to adopt.
Your one-man private Gitea installation (like mine here) is totally fine, I even disabled registration, that thing is for me and me only and I mostly don't even use issues, I have a Kanban (Trello-like) board to manage new features and bugfix statuses, not issues. But my one-man installation is not gitea.com, it does not allow registrations, it does not allow those kind of stupid people to dictate the behavior of my installation.
Github.com on the other end, allows for such stupid-er kind of people to freely open shitty issues like that was their only jobs (believe me when I say I have an history of people I explicitly reported to GitHub for being just jerks or trolls or spammers), and as such, issues need to get deleted, such that the community actually benefits from that decisions (you don't want to dig through all that one spammer's issues, don't you? yes you deleted his account and perhaps blocked his email, but you didn't delete the issues, did you?)

[Nixellion]

Well, I would also argue that when people look at Gitea they probably are trying to find a self hosted Git option, no? I would think even more so than GitLab, because of how lightweight gitea is. And for private repos deleting issues is something that should be an option.

[bryanpedini]

I was looking down at it from the perspective of a public open registrations Gitea installation like the Gitea org themselves are trying to do with gitea.com... but yeah you could argue that private repos too benefit from this feature implementation, that's no doubt.

[RandomErrorMessage]

I'm seeing commercial spam issues in the wild. I feel like this should be considered high priority. Spam is already pretty bad, not having any tools to remove it is even worse.

[KaKi87]

My self-hosted Gitea instance is also victim of spam despite using reCaptcha.
In this case, however, I'm more in need of an UI to delete user repos and accounts in one click.

[lunny]

@KaKi87 You could already delete repos from admin panel

[KaKi87]

Yes, but only one at a time, so I was forced to create a script to automatically delete a fake account's repo then the account itself.
https://git.kaki87.net/KaKi87/deno-gitea-destroy-user

[bryanpedini]

@KaKi87 You could already delete repos from admin panel

Wait, I haven't had the necessity yet so I haven't tryed it, but doesn't deleting a user also delete all its repositories? You have to manually delete all repos to be able to then delete the user?

[KaKi87]

You have to manually delete all repos to be able to then delete the user?

Yes, that's why I had to create a script.

[bryanpedini]

You have to manually delete all repos to be able to then delete the user?

Yes, that's why I had to create a script.

Gasp, lucky me that I have a privatized no-registrations instance and never had to deal with it... This probably confirms that we don't only need an admin panel to delete issues, but to generally delete stuff more easily (being them issues, spam accounts, random repos from an hacked account or somebody who shared/losed their password, etc etc).

[RandomErrorMessage]

I want to emphasize that there is a lot of interest in spamming Gitea right now. I just imagine there's some spammer forum somewhere where they're trading tips and links to known open repos. These are clearly humans who are creating these accounts, they're verified by email, completing hCaptcha. They do everything.

They make repos that contain spam files, they make issues that contain spam contents, they make profiles that contain spam details, they sometimes just make accounts that are effectively blank except a username but their username is clearly an attempt to generate SEO. I can deal with all of these things right now, except issues.

[KaKi87]

These are clearly humans who are creating these accounts, they're verified by email, completing hCaptcha. They do everything.

Actually, there are at least two known ways to bypass captchas, regardless of the provider or the website using it : headless browsers and slave-based APIs.

[Peter-Pinkster]

Let me delete!!
Only for that reason I need to find alternatives.

[fnetX]

@Peter-Pinkster You are welcome :)

Seriously, instead of complaining you might just have had a look to see this is already available in the 1.17 release - and if you really need this, you can of course build this from source already.

I'm fine if you look for alternatives and complain there.