I would like to hide topics on the Latest page from users who are members of a certain “bad” group. I believe this can be done with a theme component but am open to ideas. This is a one-off use case, and I don’t need a UI to edit the parameters.
Here is a similar effort, maybe a starting point. The approach is to use api.modifyClass to add a class on the topics (<tr>'s in the Latest page), then a few lines of css to set that class to display: none. I assume one can get the user in modifyClass and add the class if the user is a member of the “bad” group.
(I realize this does not affect their permissions, they can still see the topic in the Categories or Search view, they will still get emails, they could discover my trick and edit their local css, etc. I just want to create a nuisance and get them to take an action. Given all the constraints I think this approach will work.)
When do you need it done?
Next few weeks.
What is your budget, in $ USD that you can offer for this task?
I forgot to mention, we still want to allow them to see one topic on their Latest- the updated Terms of Service.
I don’t like it much either, but it’s the best I can come up with. The goal is to get all users to sign the updated ToS, with higher than usual importance. There was discussion at How to force existing users to accept ToS that perhaps Discourse Policy could help. But Policy does not enforce anything, and because of the importance of the new ToS we want something more than a blue bubble to nag the users. We had a plugin developed a few years ago to add members to a group when they accepted a policy, and that worked for some things, but I can’t see how to make it work for this.
We already have a fairly elaborate set of groups and categories, so we can’t just change permissions on each category from ‘everyone’ to ‘tos-acceptors’. If category permissions supported boolean logic, perhaps we could change permissions to allow only users who are members of both ‘premium-group’ and ‘tos-acceptors’. But it doesn’t support that.
I don’t have a strong opinion on how to nag them. If there was any built-in enforcement of Discourse Policy, I would use that. But we need more than a blue bubble in this case.
I also briefly considered redirecting them with a permalink if they’re not a member of tos-acceptors. That’s still an option if we could get the user id or username tacked on to the permalink url as query parameters. If we redirect them to a Docusign or something, I could set up a webhook to add them to the group ‘tos-acceptors’ so they stop getting redirected. Does that sound like a better plan?
Maybe look at one of the existing “Gate” components and adjust their criteria? These have pretty annoying blockers and inform users what’s expected in a plain straightforward way.
A plugin that would allow a complex permission setting for categories would be useful in a lot of situations. That may be the best way to spend dev time for that problem ?
Maybe with a slug formula in a text setting :
e.g.: (#tos-acceptor or #direct-concern) and #premium-group