Granular group-based permissions for anonymous and logged in users

[martin (Martin Brennan)]

@moin this PR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub is now merged and I’m adding docs in DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub . I’ve fixed discourse-copy-post with DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub and now I am going through our other official plugins to see if any others need the same treatment (e.g. you already pointed to GitHub - discourse/discourse-unanswered-filter · GitHub )

For your own Filter Favorites , you can see the copy-post example I did, but basically you need to add resolve_group_membership: true to both default_favorite_filters_groups and custom_favorite_filters_allowed_groups , then they will be available as booleans depending on the user’s group memberships on settings as settings.user_in_default_favorite_filters_groups and settings.user_in_custom_favorite_filters_allowed_groups respectively, and you now no longer need to manually check user group IDs on the frontend.

@Moin

The default setting for the default filters is “everyone,” because I find it helpful for even unregistered users to be able to see and use the default filters. The problem is that everyone changes to ‘logged_in_users’ even though I specifically selected it. Do I need to create a custom migration for this so that admins currently using everyone will continue to have filters for unregistered users in the future? When does this migration need to take place? Or does every admin need to change this individually after you have run the migration?

I would change the default of default_favorite_filters_groups to 4|5 in your theme component, which is logged in & anonymous users, rather than 0 (everyone) which is going away soon.

I will make a note to run a DB migration on theme settings when I get rid of the everyone group, I need to do one for site settings too, this will happen when the upcoming change moves to permanent in the next few weeks (depending on whether other issues come up and how fast I get through fixing other themes/components that need resolve_group_membership added).

@Moin

So here it would make sense if I didn’t allow anonymous_users as a selection. How do I do that in a theme component? Is there already an example for this?

No there is no way to do this at the moment like there is for site settings…I don’t think it’s necessary to add right now, you can just mention this in the setting description and guard with currentUser in the frontend anyway. Maybe in future I will add this if there is more need.