# Granular group-based permissions for anonymous and logged in users

**URL:** https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273
**Category:** Announcements
**Tags:** groups
**Created:** [May 13, 2026, 1:18am UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273 "2026-05-13T01:18:57Z")
**Posts on this page:** 1
**Showing post:** 38

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [August 13, 2026, 9:07am UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/38 "2026-08-13T09:07:27Z")

</div>

I think so. Otherwise, the solution to this bug could have been different.

> [@Fallback for \`user\_in\_X\` theme setting support fails when resolved value is false](https://meta.discourse.org/t/fallback-for-user-in-x-theme-setting-support-fails-when-resolved-value-is-false/408524/3):
>
> The fallback should only happen when `Object.hasOwn(settings, "user_in_copy_button_allowed_groups")` is false

It also makes sense to me. `user_in_x` also checks groups the frontend doesn’t know about, because the group is only visible to admins or its visibility is limited by default, like `everyone`. So you get different results depending on what you use, so combining the two could have unexpected consequences.

---

_[View the full topic](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273)._