Site administrators should have UI to delete issues on admin panel #923

Closed TimerWolf closed 2 years ago

Gitea version (or commit ref): 6aacf4d
Git version: 191
Operating system: Ubuntu Server
Database (use [x]):
- [ ] PostgreSQL
- [x] MySQL
- [ ] SQLite
Can you reproduce the bug at https://try.gitea.io:
- [ ] Yes (provide example URL)
- [ ] No
- [x] 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!](https://www.bountysource.com/issues/41969457-delete-issues?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).

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

bug

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!

@simonrepp For your use case it is better to create a new repository and push there, then delete this one, to avoid accidentally missing something that should be deleted.

Anyway, GitHub allows to delete issues completely, and there are many use cases above.

Tho, may be for ignorance on the subject but I still don't quite understand why IDs are not reusable... Like, 999 was deleted, not just unlisted or hidden but completely removed from the DB and the respective cached issue counters (all of them) are adjusted too; why you can't use 999 again? It's then like it has never been there (provided you update all of the counters, of course).

Tho, may be for ignorance on the subject but I still don't quite understand why IDs are not reusable...

Because there can be external links to it, and they will point to the wrong issue/comment then.

@simonrepp For your use case it is better to create a new repository and push there, then delete this one, to avoid accidentally missing something that should be deleted.

@link2xt Yes and no - keep in mind that there are other things connected to an existing repository that one might not want to lose(/feel like setting up all over again): Collaborator permissions, Branch protections, Wiki, Projects, Pull Requests, etc., so it is a viable option, but I'd say it depends on the specific situation.

depend on #15599

depend on #15599

Will wait for that, thank you for the continous interest in this topic!

idear from discord chat:

... deleted flag and render a "this issue was deleted (because <reason>)" page ...
maybe render the special page only for normal users. admins and owners could see the original issue in read-only mode

cc @KN4CK3R

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:

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

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

Since #15599 merged, PRs are welcome!!!

go-gitea / gitea

Site administrators should have UI to delete issues on admin panel #923

Description