Oh I can understand your solution now. 
While that approach might seem straightforward, I’m concerned about the following:
- Reading vs. Posting Access
• Currently, users at TL1 (or above) can both read and post in Categories A and B.
• If we remove the user from TL1 whenever they violate the 14-day rule, they will lose reading access as well. But we only want to block them from posting, not from reading.
- Need to Split Groups
• To solve the “read but can’t post” scenario, we’d have to create multiple sub-groups:
• TL1 limited – can read and reply, but cannot create topics in A or B.
• TL1 full – can read, reply, and create topics.
• If a user violates the 14-day rule, we would move them from TL1 full to TL1 limited. This seems more complicated.
- Automation Complexity
• Even with separate groups, we’d have to automatically move the user back to the “full” group once their cooldown expires.
• This means we must implement logic (e.g., a scheduled job or custom code) that calculates when the 14-day period is over and then reassigns the user from TL1 limited back to TL1 full.
• As a non-programer, I don’t feel confident handling such a complex automation by myself.
In other words, while removing users from certain groups might avoid modifying the posting logic directly, it creates additional groups and complex rules. We only want to restrict posting for 14 days, not reading access or other privileges.
Thank you very much for any suggestions or ideas. I’ve tried integrating things via Discourse APIs and webhooks in n8n, but given my limited coding background, it has been quite challenging for me.