惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

爱范儿
爱范儿
WordPress大学
WordPress大学
C
Check Point Blog
GbyAI
GbyAI
U
Unit 42
Google DeepMind News
Google DeepMind News
B
Blog RSS Feed
Blog — PlanetScale
Blog — PlanetScale
J
Java Code Geeks
I
InfoQ
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Hugging Face - Blog
Hugging Face - Blog
Vercel News
Vercel News
博客园 - 【当耐特】
美团技术团队
小众软件
小众软件
S
SegmentFault 最新的问题
Jina AI
Jina AI
阮一峰的网络日志
阮一峰的网络日志
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
The Cloudflare Blog
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
Visual Studio Blog

Discourse Meta - Latest posts

Horizon: High Context Topic Cards I'd like to ask what this file /var/www/discourse/vendor/data/RT_sRGB.icm is used for? Discourse to Markdown Plugin How to verify a subdomain (mysite.discourse.group) in Google Search Console? Reader Mode Publishing WordPress gallery posts on Discourse Discourse User Feedback New user filter by custom field and contact Interact with discourse from Python? Why we can't type the assignee in the search of a post to assign - home screen app Redis Flushall Category-toggled one-touch move post Some sort of variable to eliminate duplicate text? Why did this plugin replacement fail? Add user to list modal often appears above the mobile viewport sceen Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience Wp-discourse feature request - do not show comments with specific tag? Are there any good Chinese plugins? Discourse ID and 2FA Discourse MCP is here! Sample Forum to See Admin Features? I am unable to register for a free Discourse site Wikipedia Lookup Add text for /login (like js.create_account.disclaimer for /signup) How can i set disable Markdown & Default to Rich Text What's the background image size for the Welcome Banner? How do I enable Associated Accounts with 2FA? Hamburger toggle Support <span data-attribute> in the rich editor Cannot disable read-only mode on Free Plan
Split “delete all posts and topics allowed groups” into o...
Ethsim2 (Ethan ) · 2026-05-23 · via Discourse Meta - Latest posts

I would like to suggest splitting the delete all posts and topics allowed groups setting into narrower permissions.

At the moment, the setting is broad: it allows selected groups to delete posts and topics created by other users, and also to see deleted posts/topics. That makes sense for moderators or trusted moderation groups, but it is too powerful for a use case where I only want users to have stronger control over their own content.

To clarify, I do not mean permanent deletion/hard deletion from the database.

I am mainly asking about the ordinary user-facing deletion/revision-history behaviour: for example, when a user deletes their own post, whether it leaves the usual deleted-post placeholder, whether previous edit content remains accessible through the revision-history UI, and whether there could be a narrower permission for managing that on a user’s own posts only.

A possible split could be:

  1. delete own posts and topics allowed groups
  2. delete all posts and topics allowed groups

The first setting would only apply to content authored by the current user. The second setting would keep the current wider behaviour for groups that are trusted to delete other users’ content and see deleted content.

This would make it easier to follow least-privilege role design. For example, a site might want TL4/Leader users, or a custom trusted group, to have more control over deleting their own posts/topics without also granting them moderation-like power over other users’ content.

I realise there would need to be safeguards, especially where deleting the first post would affect a topic containing other users’ replies. In those cases, Discourse could keep the current restriction, require moderator intervention, or limit the own-content permission to replies/topics without replies.

The main request is for an own-content deletion/revision-history permission that is separate from the current global delete permission, so admins do not have to choose between ordinary user soft deletion and a much broader “can delete other users’ posts/topics” permission.

Ethsim2 (Ethan ) 2

I think part of the confusion here is that there may be a distinction between different “see deleted content” checks.

Looking at PostGuardian, an individual deleted post does not appear to become visible through can_see_post? merely because the user is in delete_all_posts_and_topics_allowed_groups.

For example, individual deleted-post visibility seems to go through:

def can_see_deleted_post?(post)
  return false if !post.trashed?
  return false if @user.anonymous?
  return true if is_staff?
  post.deleted_by_id == @user.id && @user.has_trust_level?(TrustLevel[4])
end

So a non-staff TL2 user in delete_all_posts_and_topics_allowed_groups would not necessarily be able to open/read every deleted post body via can_see_post?.

However, the same setting is also used here:

def can_see_deleted_posts?(category = nil)
  is_category_group_moderator?(category) ||
    @user.in_any_groups?(SiteSetting.delete_all_posts_and_topics_allowed_groups_map)
end

That means the setting is still conceptually broader than just “author can withdraw their own content”. It appears to be used both for deleting other users’ visible posts and for at least some deleted-post visibility/listing affordances.

So my concern is less “this setting definitely exposes every deleted post body in every endpoint”, and more that the current permission combines several concepts:

  1. deleting other users’ posts/topics;
  2. seeing or listing deleted posts/topics in some contexts;
  3. giving authors more control over their own footprint.

For my use case, I would only want the third one.

That is why I think an own-content setting would be cleaner. It could allow a user to delete/withdraw their own posts/topics, subject to existing safeguards, without granting broader moderation-like permissions over other users’ content or deleted-content visibility.

Ethsim2 (Ethan ) 3

To clarify the UI behaviour I would want: I am not asking for deleted content to become visible to ordinary users.

For an own-content deletion permission, the ideal behaviour would be viewer-sensitive:

  • the author can see that their own post has been withdrawn/deleted, perhaps in the usual red deleted-post styling or collapsed state, so they understand what happened and can recover it if recovery is allowed;
  • staff/moderators retain whatever audit and moderation visibility is appropriate;
  • ordinary users should see no trace of the deleted content at all - no post body, no revision history, and ideally no deleted-post placeholder.

So the distinction I am asking for is author control over their own visible footprint, without giving non-staff users deleted-content visibility or global power over other users’ posts/topics.

Ethsim2 (Ethan ) 4

One extra nuance is revision history.

From looking at PostRevisor, edit history is stored separately through PostRevision, so I am not suggesting that an own-content deletion permission should necessarily hard-delete revision records or remove auditability.

The permission I am imagining is more about ordinary user-facing visibility: whether the author can withdraw their own post/topic, whether the deleted-post placeholder remains, whether ordinary users can view previous edit content, and whether staff/moderators retain whatever audit/moderation access is appropriate (e.g via the “VIEW N HIDDEN REPLY”)

So the split I am asking for is not:

  • “let users erase all traces from the database”

but rather:

  • “let users have more control over their own visible content/footprint”
  • without also granting them global powers to delete other users’ content or see deleted content generally.