I am using WordPress SSO to authorize folks who have purchased a membership (I implemented custom logic in WordPress to determine whether they are members). All is working well but I am wondering how to handle cancelled members.
Obviously the cancellation of their membership will means they can’t logon. Unfortunately, I do need to manually log them out when they cancel, in case they keep accessing the forum and keeping their session alive (doing anything manually was something I thought I’d left behind when I switched from my Facebook group).
But I have two additional issues on my mind
What happens to topics / posts they posted to the forum? I want these to remain, so presumably that mean I can’t delete the user
I do want to make sure digest eMails are not sent to cancelled members. Discourse is blissfully unaware that the account has been cancelled until I do “something”. What is that, with the proviso that I don’t want to remove their content.
Is all addressed by user supression and are they are best practices for how to automated this? I am assuming some form of custom code, but checking in case I can avoid that.
You can anonymize them. That way the information stays, but not the user.
Other thing you could use, is implement custom logic, to instead of creating the user, adding them to a new group. That way, the digest should be able only to those that can access the category.
Other thing you could do, is run somekind of cronjob, that forces a logout (or account removal) on all the users that have been cancelled.
Thank you, @marianord. I am afraid I don’t fully follow the second paragraph. When you say “instead of creating the user”, at what stage in the user lifecycle do you mean? I’m probably missing a simple point here but I’m unclear on the suggestion. Can you please clarify?
Also, I will look at the anonymize feature, but a couple of questions about that.
How will their content show up in terms of the user name displayed next to their posts?
If I am successful in getting them to re-subscribe to my membership (same eMail, etc) will that “anonmyize” in any way i.e. will their old posts be lit up again with their username?
By the way, the biggest concern I have in all this is the digest eMail, since it’s a custom-facing thing (emails being sent). I assume another option is to manually change their digest configuration to never send them, right (though that’s again a manual step and hopefully do-able via an API somehow eventually).
If that is feasible, then I don’t technically need to do anything with the user. They can stay as valid users in Discourse, the emails will stop (see above) but they can no longer log on.
Suspending the user through the Discourse API might be a good way to automate this. When a user is suspended, they are logged out of Discourse and they will no longer be send digest emails. If a message is given when the user is suspended, that message will be sent as an email to the user. This could be used to encourage them to renew their membership.
One thing to note is that suspension was designed to handle difficult users, it wasn’t designed to handle the case of an expired membership that may be renewed in the future. You may find that you need to customize your site’s user_notifications.account_suspended.text_body_template text to customize the template of the email that is sent to suspended users.
Posts created by an anonymized user look like this:
There is no easy way to un-anonymize a user. The only approach I know of is to merge the anonymous user with a new user from the Rails console. Since anonymizing a user removes all identifying data from the user, it could be hard to know which accounts to merge. If there is a chance that users will renew their memberships, suspending the user is probably a better approach.
Yes, from what you say, suspension seems like the right approach here. But I do have a question about the eMails sent. I have CRM-based eMails that are sent when folks cancel so I don’t want Discourse to send anything at all.
You mention “If a message is given when the user is suspended, that message will be sent as an email to the user.”.
If I do NOT provide a message, does that mean that nothing is sent and i don’t need to worry about updating the template at all (since it will never be sent)?
Just looking at suspension, perhaps I am a little unclear about how the “Suspension Reason” and eMail fields are used.
Basically my goal is to suspend the user and do absolutely nothing else
This is correct. The easiest way to test it is to create a user with a throw-away email address and try suspending and unsuspending them through the UI.
When a user is suspended, a suspended_until and reason must be set. These fields are displayed to a suspended user when they attempt to login to the site. You can customize this text by searching for login.suspended_with_reason on your Admin / Customize / Text page.
Unless you enable the hide suspension reasons site setting, there will be a notice that the user has been suspended displayed on the usercard and profile page of the suspended user. If you enable the hide suspension reasons site setting, the notice will only be seen by staff.
