Difference between revisions of "Proposals/Done/New user probation"
From Mahara Wiki
m (Anitsirk moved page Developer Area/Specifications in Development/New user probation to Developer Area/Specifications in Development/Done/New user probation without leaving a redirect)
Revision as of 16:34, 11 July 2020
This is a feature that was developed for mahara.org to reduce spam content on the page. We had a great deal of spam content created on the site, presumably with the goal of being cross-linked for search engine optimization purposes. In order to combat this, we implement a new user probation system, in which newly self-registered accounts cannot create publicly visible content containing links, thus making the site useless for SEO purposes.
- The launchpad bug: https://bugs.launchpad.net/mahara/+bug/1252101
- The gerrit patch: https://reviews.mahara.org/#/c/3065/
How it works
We add a newuserpoints column to the usr table. When a new user self-registers, this column is populated with a specific number of newuserpoints, stored in $CFG->probationthreshold. A user is considered "probationary" while their newuserpoints >= 1.
Probationary users are forbidden from creating content that would expose URLs or images to the outside world.
We use form validation to print an error and block their action if they try to place an image or URL into one of these:
- A comment
- A wall post
- A forum post
We hide controls to prevent them from taking these actions, which would make content public that could contain URLs:
- Making a group public
- Making a page public
- Creating secret URLs for a page
Getting out of probation
A user's newuserpoints are decreased by one when they take certain actions that show that a nonprobationary user approves of them. Currently there's just one action:
- A non-probationary user posts a reply to one of their forum posts
Additionally, if a user is staff or admin (at the site or institution level), we ignore however many new user points they have and treat them as non-probationary. The idea is that someone had to make the account into an admin or staff, so they must be trustworthy.
And lastly, only user accounts created through self-registration, receive new user points. So users created manually through CSV or from an auth method, will not be subject to probation.
Using the probation API
There are a few ways to use the probation system in Mahara. The functions relating to this are all in lib/antispam.php.
Before creating public content
If you're adding a system that lets a (non-staff, non-admin) user create content that may be publicly accessible, simply call probation_validate_external_links_or_images($text). If it returns true, the content is okay for this user. If it returns false, it is not okay.
If the content is not acceptable, you can use get_string('newuserscantpostlinksorimages'); to display a standard error message.
Note: You don't need to do this for content in standard Blocks. It's only really needed for cases where a user can create content outside of their own Pages -- comments, wall posts, forums, etc.
Before taking other sensitive actions
If you simply want to check whether a user is on probation or not, just call is_probationary_user(). You can optionally pass in a user id; by default it'll check the current logged-in user.
To "vouch for" a probationary user
The probation system is basically a reputation system. The idea is that when a probationary user makes a forum post, and a nonprobationary user responds to it, this indicates that the nonprobationary user thinks the probationary user is worth talking to. And hence, we decrease their probation points by 1.
The function to call, if you want to add other means for the reputation to be raised, is vouch_for_probationary_user($vouchforthisuserid, $vouchinguserid = null, $points = 1);
The only required parameter is the first, which is the ID of the probationary user. The optional second argument is the ID of the nonprobationary user (by default, the current logged-in user). The optional third is the number of points of reputation gained (it defaults to 1).
The first argument is the ID of the probationary user. The second argument is the