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

@TimerWolf commented on GitHub (Feb 13, 2017):

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

@TimerWolf commented on GitHub (Feb 13, 2017): 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

GiteaMirror commented

@thehowl commented on GitHub (Feb 13, 2017):

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.

@thehowl commented on GitHub (Feb 13, 2017): 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.

GiteaMirror commented

@TimerWolf commented on GitHub (Feb 13, 2017):

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

@TimerWolf commented on GitHub (Feb 13, 2017): 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

GiteaMirror commented

@bkcsoft commented on GitHub (Feb 13, 2017):

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

@bkcsoft commented on GitHub (Feb 13, 2017): If you create an issue my mistake, you can just change the title & body to `Invalid` and close it

GiteaMirror commented

@TimerWolf commented on GitHub (Feb 13, 2017):

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

In my eyes thats unclean

@TimerWolf commented on GitHub (Feb 13, 2017): I still don´t like it, but i see the none other agree whit me. In my eyes thats unclean

GiteaMirror commented

@bkcsoft commented on GitHub (Feb 14, 2017):

Unclean yes, but consistent 🙂

@bkcsoft commented on GitHub (Feb 14, 2017): Unclean yes, but consistent 🙂

GiteaMirror commented

@lborgman commented on GitHub (Feb 4, 2018):

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.

@lborgman commented on GitHub (Feb 4, 2018): 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.

GiteaMirror commented

@jamesbanogon commented on GitHub (Jun 2, 2018):

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.

@jamesbanogon commented on GitHub (Jun 2, 2018): 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.

GiteaMirror commented

@tboerger commented on GitHub (Jun 2, 2018):

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

@tboerger commented on GitHub (Jun 2, 2018): The owner could also just delete it from the db :)

GiteaMirror commented

@Mikanoshi commented on GitHub (Jan 4, 2019):

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

@Mikanoshi commented on GitHub (Jan 4, 2019): Spammers are leaving issues with ads and I as admin cannot delete them 🤦‍♂️ Had to clean DB every time...

GiteaMirror commented

@lunny commented on GitHub (Jan 5, 2019):

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

@lunny commented on GitHub (Jan 5, 2019): Site administrators should have permissions to delete the issues on admin panel for maintaining the site easier

GiteaMirror commented

@stale[bot] commented on GitHub (Mar 6, 2019):

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.

@stale[bot] commented on GitHub (Mar 6, 2019): 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.

GiteaMirror commented

@DarkWiiPlayer commented on GitHub (Apr 1, 2019):

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

@DarkWiiPlayer commented on GitHub (Apr 1, 2019): 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).

GiteaMirror commented

@yanOnGithub commented on GitHub (Apr 25, 2019):

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

@yanOnGithub commented on GitHub (Apr 25, 2019): > 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? ```sql 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

GiteaMirror commented

@DarkWiiPlayer commented on GitHub (Apr 26, 2019):

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.

@DarkWiiPlayer commented on GitHub (Apr 26, 2019): 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.

GiteaMirror commented

@Mikanoshi commented on GitHub (Jun 6, 2019):

Removed issue from DB, how to fix this now?

@Mikanoshi commented on GitHub (Jun 6, 2019): Removed issue from DB, how to fix this now? ![bug](https://user-images.githubusercontent.com/5113439/59034545-a8c42c00-8884-11e9-89fb-8661b62af2e9.png)

GiteaMirror commented

@bryanpedini commented on GitHub (Jun 16, 2019):

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

@bryanpedini commented on GitHub (Jun 16, 2019): 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](https://imgur.com/a/TumnlxL)... 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)...

GiteaMirror commented

@DJFraz commented on GitHub (Aug 27, 2019):

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 commented on GitHub (Aug 27, 2019): > Removed issue from DB, how to fix this now? > > ![bug](https://user-images.githubusercontent.com/5113439/59034545-a8c42c00-8884-11e9-89fb-8661b62af2e9.png) 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.

GiteaMirror commented

@Mikanoshi commented on GitHub (Aug 29, 2019):

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

@Mikanoshi commented on GitHub (Aug 29, 2019): @DJFraz Decreasing `num_issues` causes error 500 when trying to create new issue, I had to increase `num_closed_issues` instead.

GiteaMirror commented

@Mikanoshi commented on GitHub (Sep 4, 2019):

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.

@Mikanoshi commented on GitHub (Sep 4, 2019): 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.

GiteaMirror commented

@bkcsoft commented on GitHub (Sep 30, 2019):

☝️ 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

@bkcsoft commented on GitHub (Sep 30, 2019): :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

GiteaMirror commented

@guillep2k commented on GitHub (Sep 30, 2019):

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

@guillep2k commented on GitHub (Sep 30, 2019): > > > 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 = ?`.

GiteaMirror commented

@Mikanoshi commented on GitHub (Sep 30, 2019):

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.

@Mikanoshi commented on GitHub (Sep 30, 2019): > 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.

GiteaMirror commented

@netorica commented on GitHub (Jan 13, 2020):

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.

@netorica commented on GitHub (Jan 13, 2020): 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.

GiteaMirror commented

@lunny commented on GitHub (Jan 13, 2020):

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

@lunny commented on GitHub (Jan 13, 2020): We should store the last `index` on repository table or something others.

GiteaMirror commented

@guillep2k commented on GitHub (Jan 13, 2020):

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?

@guillep2k commented on GitHub (Jan 13, 2020): > > > 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?

GiteaMirror commented

@guillep2k commented on GitHub (Jan 13, 2020):

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 commented on GitHub (Jan 13, 2020): 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.

GiteaMirror commented

@lunny commented on GitHub (Jan 13, 2020):

@guillep2k that sounds better.

@lunny commented on GitHub (Jan 13, 2020): @guillep2k that sounds better.

GiteaMirror commented

@bryanpedini commented on GitHub (Jan 13, 2020):

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

@bryanpedini commented on GitHub (Jan 13, 2020): @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.

GiteaMirror commented

@guillep2k commented on GitHub (Jan 13, 2020):

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

@guillep2k commented on GitHub (Jan 13, 2020): > > > @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.

GiteaMirror commented

@bryanpedini commented on GitHub (Jan 21, 2020):

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?

@bryanpedini commented on GitHub (Jan 21, 2020): > 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?

GiteaMirror commented

@guillep2k commented on GitHub (Jan 21, 2020):

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.

@guillep2k commented on GitHub (Jan 21, 2020): > > > 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.

GiteaMirror commented

@KaKi87 commented on GitHub (Sep 8, 2020):

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

@KaKi87 commented on GitHub (Sep 8, 2020): To the people who are against making issues deletable : fine, but then allow to delete edit history.

GiteaMirror commented

@DarkWiiPlayer commented on GitHub (Sep 8, 2020):

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

@DarkWiiPlayer commented on GitHub (Sep 8, 2020): 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

GiteaMirror commented

@bryanpedini commented on GitHub (Sep 8, 2020):

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

@bryanpedini commented on GitHub (Sep 8, 2020): > 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...

GiteaMirror commented

@DarkWiiPlayer commented on GitHub (Sep 8, 2020):

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

@DarkWiiPlayer commented on GitHub (Sep 8, 2020): > @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.

GiteaMirror commented

@bryanpedini commented on GitHub (Sep 8, 2020):

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

@bryanpedini commented on GitHub (Sep 8, 2020): > 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...

GiteaMirror commented

@simonrepp commented on GitHub (Nov 2, 2020):

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 commented on GitHub (Nov 2, 2020): 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!

GiteaMirror commented

@link2xt commented on GitHub (Apr 22, 2021):

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

@link2xt commented on GitHub (Apr 22, 2021): @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.

GiteaMirror commented

@bryanpedini commented on GitHub (Apr 22, 2021):

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

@bryanpedini commented on GitHub (Apr 22, 2021): 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).

GiteaMirror commented

@link2xt commented on GitHub (Apr 22, 2021):

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.

@link2xt commented on GitHub (Apr 22, 2021): > 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.

GiteaMirror commented

@simonrepp commented on GitHub (Apr 23, 2021):

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

@simonrepp commented on GitHub (Apr 23, 2021): > @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.

GiteaMirror commented

@lunny commented on GitHub (Apr 23, 2021):

depend on #15599

@lunny commented on GitHub (Apr 23, 2021): depend on #15599

GiteaMirror commented

@bryanpedini commented on GitHub (Apr 23, 2021):

depend on #15599

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

@bryanpedini commented on GitHub (Apr 23, 2021): > depend on #15599 Will wait for that, thank you for the continous interest in this topic!

GiteaMirror commented

@6543 commented on GitHub (May 7, 2021):

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

@6543 commented on GitHub (May 7, 2021): 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

GiteaMirror commented

@mjfs commented on GitHub (Jun 10, 2021):

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 commented on GitHub (Jun 10, 2021): 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.

GiteaMirror commented

@nicorac commented on GitHub (Jun 10, 2021):

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

@nicorac commented on GitHub (Jun 10, 2021): @mjfs: It was a pleasure to read your thoughts. I completely agree with all of your points 👍

GiteaMirror commented

@lunny commented on GitHub (Jun 14, 2021):

Since #15599 merged, PRs are welcome!!!

@lunny commented on GitHub (Jun 14, 2021): Since #15599 merged, PRs are welcome!!!

GiteaMirror commented

@6543 commented on GitHub (Jul 13, 2021):

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

@6543 commented on GitHub (Jul 13, 2021): v1.15.0 is in freeze and no pulls where made ... moved onto next milestone

GiteaMirror commented

@Nixellion commented on GitHub (Oct 22, 2021):

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.

@Nixellion commented on GitHub (Oct 22, 2021): 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.

GiteaMirror commented

@bryanpedini commented on GitHub (Oct 22, 2021):

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

@bryanpedini commented on GitHub (Oct 22, 2021): > 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](https://git.bjphoster.com)) 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](https://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](https://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?)

GiteaMirror commented

@Nixellion commented on GitHub (Oct 22, 2021):

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.

@Nixellion commented on GitHub (Oct 22, 2021): 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.

GiteaMirror commented

@bryanpedini commented on GitHub (Oct 22, 2021):

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.

@bryanpedini commented on GitHub (Oct 22, 2021): 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](https://gitea.com)... but yeah you could argue that private repos too benefit from this feature implementation, that's no doubt.

GiteaMirror commented

@RandomErrorMessage commented on GitHub (Dec 2, 2021):

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.

@RandomErrorMessage commented on GitHub (Dec 2, 2021): 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.

GiteaMirror commented

@KaKi87 commented on GitHub (Dec 4, 2021):

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.

@KaKi87 commented on GitHub (Dec 4, 2021): 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.

GiteaMirror commented

@lunny commented on GitHub (Dec 4, 2021):

@KaKi87 You could already delete repos from admin panel

@lunny commented on GitHub (Dec 4, 2021): @KaKi87 You could already delete repos from admin panel

GiteaMirror commented

@KaKi87 commented on GitHub (Dec 4, 2021):

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

@KaKi87 commented on GitHub (Dec 4, 2021): 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

GiteaMirror commented

@bryanpedini commented on GitHub (Dec 6, 2021):

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

@bryanpedini commented on GitHub (Dec 6, 2021): > @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?

GiteaMirror commented

@KaKi87 commented on GitHub (Dec 6, 2021):

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.

@KaKi87 commented on GitHub (Dec 6, 2021): > 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.

GiteaMirror commented

@bryanpedini commented on GitHub (Dec 6, 2021):

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

@bryanpedini commented on GitHub (Dec 6, 2021): > > 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).

GiteaMirror commented

@RandomErrorMessage commented on GitHub (Dec 7, 2021):

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.

@RandomErrorMessage commented on GitHub (Dec 7, 2021): 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.

GiteaMirror commented

@KaKi87 commented on GitHub (Dec 7, 2021):

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.

@KaKi87 commented on GitHub (Dec 7, 2021): > 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.

GiteaMirror commented

@Peter-Pinkster commented on GitHub (Mar 16, 2022):

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

@Peter-Pinkster commented on GitHub (Mar 16, 2022): Let me delete!! Only for that reason I need to find alternatives.

GiteaMirror commented