Gitea: 站点管理员应该有用户界面来删除管理面板上的问题

~正如我们在gitter上所说的，我认为没有这个要求，几乎所有的git主机软件都不允许删除问题。~

恕我直言，这不是错误，而是一个功能。 它确保没有人操纵问题的可见性。

我没有看到问题，如果问题是任何人都可以删除它，为什么不看看“所有者”或从一开始就真正提出问题的人呢？

我的意思是说我做了这个，然后我想了想，知道它有任何需要，或者我的请求很愚蠢，或者任何其他原因会让我删除它，而不是一无所获。

这在我眼里毫无意义

问题然后被证明是“愚蠢的”并被关闭是非常有帮助的！ 假设有人有同样的疑问或问题，已解决的问题是某事的“文档”，然后被证明不是问题，如果问题创建者添加它，它还将包含有关如何解决它的说明。

我认为删除问题有意义的唯一情况是在非法内容的情况下。 在这种情况下，只需删除评论或编辑问题以不包含非法内容。

我可以明白你的意思，但我仍然不同意我的情况，我是唯一一个运行我的存储库的人，这就是为什么我想念那个功能删除不需要的东西

如果你创建了一个问题，我的错误，你可以将标题和正文更改为Invalid并关闭它

我仍然不喜欢它，但我看到没有其他人同意我。

在我眼里那是不洁的

不干净是的，但始终如一 🙂

例如，当您正在测试 ISSUE_TEMPLATE 或试图了解项目流程时，能够删除您自己的问题将非常有帮助......

至少当您是存储库的所有者时。

此功能应该可用，因为由存储库的所有者决定适合他/她的项目的工作流。

所有者也可以从数据库中删除它:)

垃圾邮件发送者留下了广告问题，我作为管理员无法删除它们🤦‍♂️ 每次都必须清理数据库...

站点管理员应该有权删除管理面板上的问题，以便更轻松地维护站点

此问题已自动标记为过时，因为它最近没有活动。 如果在接下来的 2 周内没有进一步的活动，它将关闭。 感谢你的贡献。

尚未提出的一个问题是，出于法律原因，某些内容可能需要删除。 比如说，例如用户 X 在一个问题中发布了一些非常非法的内容。 当然，他们的帐户立即被终止，但现在网站管理员在他们的网站上有非法内容，无法删除。

另请注意，管理员并不总是知道如何从数据库中删除问题； 从 UI 中执行此操作的选项是必须的，除非管理员可以 100% 信任他们的用户（这种情况很少见）。

管理员并不总是知道如何从数据库中删除问题；

我想删除一个拉取请求。 在GUI可用之前，以下SQL是否足够好？

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

假设 pull request URL 末尾的数字是 10
http://localhost :3200/org_name/repo_name/pulls/10

只是一点意见，但这里有一个我认为应该删除而不是关闭的列表：

• 包含非法、攻击性或其他不需要的内容的问题。
• 完全不相关的内容，与项目无关。
• 其他（类似）项目的广告
• 作者拒绝淡化的强烈语言

事情可能只是被关闭，但一些维护者和/或管理员可能仍然要删除，以保持清洁积压：

• 没有添加新信息的重复问题
• 没有任何基础的批评或改进建议 à la ur s0ftware suxx

我希望这强调了这一点，对于管理员和存储库维护者来说，在某些情况下完全删除问题通常是有意义的。

从数据库中删除了问题，现在如何解决？

作为一个自托管的 git repo 服务器，我还认为站点管理员应该能够允许存储库所有者“做任何他们喜欢的事情”。

举个例子，我是我的服务器的所有者（即使我不是但有启用的选项来这样做，它也是一样的），我也想作为我的 repo 的所有者，自己打开问题向其他人展示我随着时间的推移所做的工作，并且我添加了有用的东西，而不仅仅是愚蠢的废话（只是因为我认识的 90% 的人从不看提交历史，提交反证我的勤奋，只是说“你做的真他妈的整天？愚蠢的无用代码？”）。

然而，当我处理我自己的问题时（你们中的 90% 可能至少做过一次）通常不知道把东西放在哪里，即使在我自己的标签方案下，所以我倾向于添加一个标签，然后删除它和将问题分配到另一个标签下，依此类推，直到我的“问题历史”看起来像这样......

能够删除那个蹩脚的优柔寡断并重新开始一个新问题（或至少删除我优柔寡断的“标签历史”）会非常好......

从数据库中删除了问题，现在如何解决？

在遇到同样的问题后，我实际上想出了这一点。 转到数据库的repository表。 未解决的问题计数是两列num_issues和num_closed_issues的减数。 我将47 num_issues更改46并更新了计数。

@DJFraz
尝试创建新问题时，减少num_issues会导致错误 500，我不得不增加num_closed_issues 。

更改num_closed_issues也不是一个好主意:) Gitea 根据问题表更新它。
因此，它要么删除问题，然后确保num_issues + 1 不会与现有问题索引冲突，要么只是关闭问题并清空其内容。

:point_up: 这正是没有实施删除问题的原因。 出于性能原因，问题的数量（ num_issues ）被缓存在数据库中，这个数字也用于下一个问题编号（ num_issues + 1 ）。

可以在数据库中复制此值，并使用last_issue_nr或next_issue_nr作为修复。 或者可以在问题表中添加hidden -boolean。 在后一种情况下，该问题仅对 UI（和 API）隐藏，但稍后可以在必要时引用（该线程前面提到了法律原因）

只是我的 2 美分

此编号还用于表示下一个发行编号 ( num_issues + 1 )。

不完全的。 目前它是SELECT MAX(index)+1 FROM issue WHERE repo_id = ? 。

这就是为什么没有实施删除问题的原因

不，这就是为什么你不应该手动弄乱它们:)
我不在乎原因，我想完全控制我的网站，应该实现这个功能。

这是公共可用的 gitea 安装所必需的，特别是如果您已成为垃圾邮件的目标。

对我来说，关闭功能必须用于关闭与项目相关的问题，而不是用于关闭必须更好地删除的无关垃圾邮件。

我们应该将最后的index存储在存储库表或其他东西上。

我们应该将最后的index存储在存储库表或其他东西上。

只要 xorm 在我们所有的数据库上都支持SELECT FOR UPDATE ，这听起来也绝对是更新索引问题的解决方案。 我想是的，不是吗？

关于需要连续（即没有孔）的顺序值的创建，在我很久以前做的一个项目中，我们有一个单独的表来生成这些值。 例如：

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

这样，为了计算下一个问题#，我们做了以下事情：

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)

这样，我们只产生了一个锁来添加一个问题（即实际存储库行没有为事务的剩余部分锁定）。 其他尝试添加行的事务将被锁定，等待第一个 UPDATE 解决，因此没有重复的机会。 如果第一个事务回滚，第二个事务将获得正确的下一个值。

这也将确保没有值被重用，即使我们删除了最新的问题。

@guillep2k听起来更好。

@guillep2k提出的@lunny解决方案看起来像老板一样合法； 但正如@DJFraz在 2019 年 8 月 27 日指出的那样，由于问题计数器是在运行时计算的，然后存储在数据库中以进行缓存，您认为应该如何处理这些问题？
谢谢。

@guillep2k提出的@lunny解决方案看起来像老板一样合法； 但正如@DJFraz在 2019 年 8 月 27 日指出的那样，由于问题计数器是在运行时计算的，然后存储在数据库中以进行缓存，您认为应该如何处理这些问题？

这只是重新计算“缓存”值的问题，就像我们打开/关闭任何问题时所做的那样。

该评论中的问题是用户试图删除该行而不更新相应的列以反映更改。

该评论中的问题是用户试图删除该行而不更新相应的列以反映更改。

所以，techincally ......它可以从数据库中删除_manually_东西，摆脱它不会破坏任何东西？

所以，techincally ......它可以从数据库中删除_manually_东西，摆脱它不会破坏任何东西？

存在问题编号被重用的问题。 如果你删除坏评论#999并且它恰好是最后一个，下一个好的评论也会得到数字#999 ，这是不不不。 新注释实际上应该是#1000并且数字#999应该“未使用”。 但我正在开发一个 PR 来解决这个问题，并为将来删除评论铺平道路。

对于反对使问题可删除的人：很好，但允许删除编辑历史记录。

或者：如何从视图中完全隐藏不需要的问题并为管理员添加一个选项以查看隐藏的问题？

这将解决无法从您自己的站点中删除具有法律危险的内容和整理问题列表的问题

这将解决无法从您自己的网站删除合法危险内容的问题

@DarkWiiPlayer问题是，潜在的非法内容，例如

隐藏问题：对于那些不想有重复问题和杂乱无章的问题的人来说，这很好，问题历史充满了添加和删除标签以及人们和改变主意的决定。
然而，对于存储在服务器磁盘上的非法内容来说，这并不好......

@DarkWiiPlayer问题是，潜在的非法内容，例如

那是个很好的观点。 我想我是从“如果警察没有看到它，你就没事”的角度来看它的，但是有多种原因可能仍然伤害网站所有者，从某人随机发现它到某人故意上传此类内容，然后通知警方。

我仍然认为隐藏的问题总比没有好，结合编辑问题并清除其编辑历史记录，它仍然可以工作。

理想情况下，真正“删除”问题的选项，即使这只是意味着清理所有数据并将其设置为“已删除”在数据库中，也是最好的解决方案。

那是个很好的观点。

谢谢。

我想我是从“如果警察没有看到它，你就没事”的角度来看它的

不幸的是，当您的存储介质中有非法文件时，它不会像那样工作......即使它们不是通过 URL 公开可用的，如果进行了报告并提交了检查，无论如何，您都被搞砸了您可以说多少“但那是用户上传的内容”...

添加到具有此原因的列表中：我目前正在与其他 2 位合作者在一个私人回购中组织工作，因此我们的沟通目前包括我们不会公开披露的细节。 然而，当我们决定公开发布该项目时，回购有可能在未来公开。 在这一点上，最好有办法在将项目可见性设置为公众之前完全清除问题部分，从而将其公开。

在某个时候看到这个功能会很棒，无论如何感谢 gitea 上的所有工作，并保持出色的工作！