当用户处于没有 create 权限的分类中时，我仍然能看到 <kbd>**新建主题**</kbd> 按钮。
点击它会打开编辑器，但未选择任何分类：
当我进入该分类时，系统确实提示我没有在此处创建的权限。
我敢肯定，在这种情况下，<kbd>**新建主题**</kbd> 按钮应该只是变灰。这一点有变化吗？
Meta 上那位老好人 AI 机器人给我指了 2025 年的这项变更。我们能否回滚或禁用它？依我看，这似乎很容易让用户感到困惑。
嗯……我可能搞错了，但也许是“只读分类的默认子分类”这个站点设置？这有帮助吗？
我们认为不会回退此更改。我们坚持在相关 PR 中阐述的理由：我们不想仅仅因为用户无权在某个分类下发帖，就阻止他们打开编辑器。也许他们希望在其他分类下发帖，但需要引用该受限分类中的话题。
由于这不是一个缺陷，我已将您的话题移至 UX 分类，以便您进一步讨论。
我对当前实现的不满在于，“新建主题”按钮在他们可以发帖和不能发帖的分类中看起来一模一样，直到他们点击进入某个分类并重新选择当前分类时，才意识到该分类是 只读 的。而使用之前的方法，用户能立刻明白自己无法在那里创建主题。
我理解这种实现背后的理由，但它假设最终用户能够理解其执行方式及原因。我知道我的用户会对这一点感到困惑。我想我会尝试构建一个能复现旧方法的功能。
作为背景说明，我们正在调整一项政策：针对内部人员在某些曾经允许发帖的分类中发帖的限制。我力求让这一变更万无一失，以避免不可避免的困惑。
你能详细说明一下这里的意思吗？
1 个赞
这对我来说是一个有趣的问题，我能理解双方的逻辑。
首先想到的是，可以弹出某种提示或警告，告知用户您尝试创建的主题最终将出现在当前类别之外的某个地方，原因是您不允许在此类别中创建主题……
我意识到，当前的运作方式可能导致主题被创建在不理想或不最合适的类别中。
当然，话题发起人也可以使用 CSS 隐藏按钮或修改按钮文字，这有点取巧，但……
每个社区的情况都不同，我能理解这可能会让一些不太熟悉技术的用户感到困惑。
在这种情况下，我能理解这一请求的重要性。
1 个赞