Gitea: Site administrators should have UI to delete issues on admin panel

~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.~

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

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

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.

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

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

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

In my eyes thats unclean

Unclean yes, but consistent 🙂

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.

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.

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

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

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

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.

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).

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

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.

Removed issue from DB, how to fix this now?

As a self-hosted git repo server I also think the site administrator should be able to allow repository owners to do "whatever they like".

As an example, I am the owner of my server (and even if I wasn't but had the enabled options to do such, it would be the same), and I would like also as owner of my repo, to open issues myself to show other people the work I do over time and that I add useful stuff, not just stupid crap (only because 90% of the people I know never watch commit history and commits counter proving my diligence and just say " 'the hell you do all day? stupid useless code? ").

However when I work on my own issues (and also 90% of you probably did at leas once) don't usually know where to put things even under my own label scheme, so I tend to add a label, then to remove it and assign the issue under another label, and so on so forth until my "issue history" looks something like this...

It would be very nice to be able to delete that crappy indecision and start a new issue over (or at least delete the "label history" of my indecision of what to be)...

Removed issue from DB, how to fix this now?

I actually figured this out after I had the same issue. Go the the repository table of your database. The open issue count is the subtrahend of the 2 columns num_issues and num_closed_issues. I changed 47 num_issues to 46 and it updated the count.

@DJFraz
Decreasing num_issues causes error 500 when trying to create new issue, I had to increase num_closed_issues instead.

Changing num_closed_issues wasn't a great idea either :) Gitea updates it according to issues table.
So it's either removing issues and then making sure that num_issues + 1 won't conflict with existing issue index or just closing an issue and emptying its content.

:point_up: that is exactly why deleting issues isn't implemented. For performance reasons the number of issues are cached (num_issues) in the DB, this number is also used for what the next Issue Number is going to be (num_issues + 1).

One could duplicate this value in the DB and have last_issue_nr or next_issue_nr as a fix. Or one could add a hidden-boolean to the issue-table. In the latter case the issue is only hidden from the UI (and API), but can later be referenced if necessary (legal reasons was mentioned earlier in the thread)

Just my 2 cents

this number is also used for what the next Issue Number is going to be (num_issues + 1).

Not quite. Currently it's SELECT MAX(index)+1 FROM issue WHERE repo_id = ?.

that is exactly why deleting issues isn't implemented

No, that's why you shouldn't mess with them manually :)
I don't care about reasons, I want full control over my site, this feature should be implemented.

this is needed for gitea installations available in public especially if you have been targeted with spam.

for me the close feature must be for closing an issue related to the project and not use to close an unrelated spam which is must better to be deleted.

We should store the last index on repository table or something others.

We should store the last index on repository table or something others.

That definitely sounds like a solution to the update index problem as well, as long as xorm supports SELECT FOR UPDATE on all our dbs. I think it does, isn't it?

Regarding the creation of sequential values that need to be consecutive (i.e. no holes), in a project I did long ago we had a separate table for generating those. e.g.:

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

This way, to calculate the next issue #, we did the following:

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)

This way, we produced only one lock to add an issue (i.e. the actual repository row was not locked for the remaining of the transaction). Other transactions attempting to add rows will be locked waiting for the first UPDATE to resolve so no chance of duplicates. If the first transaction rolls back, the second one will get the correct next value for it.

This would also ensure that no values are reused, even if we delete the latest issue.

@guillep2k that sounds better.

@lunny solution proposed by @guillep2k seems legit like a boss; but as @DJFraz noted on 27th of Aug 2019, since issue counters are calculated runtime but then stored in database for caching, how do you think handling those should be implemented?
Thanks.

@lunny solution proposed by @guillep2k seems legit like a boss; but as @DJFraz noted on 27th of Aug 2019, since issue counters are calculated runtime but then stored in database for caching, how do you think handling those should be implemented?

It's only a matter of recalculating the "cached" values, just as we do when we open/close any issue.

The problem in that comment is that the user attempted to delete the row without updating the appropriate columns to reflect the change.

The problem in that comment is that the user attempted to delete the row without updating the appropriate columns to reflect the change.

So, techincally... it IS possible to _manually_ delete things from database and get away with it without breaking anything?

So, techincally... it IS possible to _manually_ delete things from database and get away with it without breaking anything?

There's the problem of issue numbers being reused. If you delete bad comment #999 and it happens to be the last, the next good comment will get the number #999 too, which is no no no. The new comment should be in fact #1000 and the number #999 should be left "unused". But I'm working on a PR that will fix this issue and pave the way for deleting comments in the future.

To the people who are against making issues deletable : fine, but then allow to delete edit history.

alternatively: How about completely hiding unwanted issues from view and adding an option for administrators to view hidden issues?

This would fix both the problem with not being able to delete legally dangerous content from your own site and de-clutter the issue-list

This would fix both the problem with not being able to delete legally dangerous content from your own site

@DarkWiiPlayer the thing is, that the potentially illegal content, such as a pedo pornographic image, is still available on your server drive, and accessible by a requested check on your services from a police officer...

Hiding issues: fine for people who don't want to have duplicate issues and cluttered stuff with issue history full of adding and removing labels and people and mind changing decisions.
Not fine however for illegal content stored on the disks of the server...

@DarkWiiPlayer the thing is, that the potentially illegal content, such as a pedo pornographic image, is still available on your server drive, and accessible by a requested check on your services from a police officer...

That's a good point. I guess I was looking at it from the perspective that "If the police doesn't ever see it, you're fine", but there's a variety of reasons why that might still harm the site owner, from someone randomly finding it to someone intentionally uploading such content, then informing the police.

I still think hidden issues is better than nothing, and in combination with editing the issue and scrubbing its edit history, it would still work.

Ideally though, an option to truly "delete" the issue, even if this just means scrubbing all data and setting it to "deleted" in the DB, would be the best solution.

That's a good point.

Thanks.

I guess I was looking at it from the perspective that "If the police doesn't ever see it, you're fine"

Unfortunately it doesn't work like that when you have illegal files in your storage medium... even if they're not publicly available through a URL, if a report is made and a check is filed, you're screwed, no matter how much "but that's user uploaded content" you can say...

To add to the list of reasons for having this: I am currently organizing work in a private repo with 2 other collaborators, thus our communication currently includes details we wouldn't publicly disclose. However chances are the repo will be made public at a future point when we decide to openly release the project. At that point it would be great to have a way to wipe the issues section entirely before setting the project visibility to public and thus going into the open with it.

Would be great to see this feature at some point, anyhow thanks for all the work on gitea and keep up the great work!