To block spam, we will implement admin review process. The first entry created by an unverified user will need to be approved by an admin before it's published live.
Dev tasks
UI
[ ] Add a new button in the admin section of their profile page, label "Review Entries"
[ ] Build a new page that's only accessible by admin called Review, links to the previous button. This page contains data table view displaying the title of each entry waiting for review, and an "Approve" and "Reject" button on each row.
[ ] Support pagination of 100 entries per page at a time. Allowing the user to move back/forth between pages.
[ ] Currently, we have a field called accepted_date in users data model, which aren't being used. We will use this field to tell if the user was verified by admin.
[ ] If users.accepted_date field is null, any entry that the user posts has to go to the review bucket.
[ ] When a new user(users.accepted_date == null) tries to publish their entry, set the things.hidden flag to true. And the entry won't be auto-translated, not until it's approved.
[ ] If users.accepted_date field is set, meaning the user was previously approved, in this case publish and translate like we now do. It won't show up in the review bucket, and published right away.
[ ] Please make sure this new entry does not show up in their draft list. Basically, the logic is
Update - the review entries button will show up on the Content Chooser page for admins (not the profile page, as noted above). This is already built:
@paninee - please make the following changes:
[ ] change button text to "Approve / Block New Entries"
[ ] add text below the button: "New entries must be approved by an admin. Approving an entry will automatically approve all entries by that user, and their future entries won't require review. Blocking an entry will block that user and permanently delete all of their entries from the database, please review carefully."
To block spam, we will implement admin review process. The first entry created by an unverified user will need to be approved by an admin before it's published live.
Dev tasks
UI
Review
, links to the previous button. This page contains data table view displaying the title of each entry waiting for review, and an "Approve" and "Reject" button on each row.Auth0 setup
We need to block the user by calling Auth0 Management API https://auth0.com/docs/api/management/v2/#!/Users/patch_users_by_id. In order to do that we need to follow this step https://auth0.com/docs/secure/tokens/access-tokens/get-management-api-access-tokens-for-production and use the existing machine-to-machine key called
Participedia API
Logic
accepted_date
inusers
data model, which aren't being used. We will use this field to tell if the user was verified by admin.users.accepted_date
field is null, any entry that the user posts has to go to the review bucket.users.accepted_date == null
) tries to publish their entry, set thethings.hidden
flag to true. And the entry won't be auto-translated, not until it's approved.users.accepted_date
field is set, meaning the user was previously approved, in this case publish and translate like we now do. It won't show up in the review bucket, and published right away.!things.published ==> draft
things.published && things.hidden && authors.user.accepted_date == null ==> Waiting for Review
things.published && !things.hidden ==> Published
things.hidden
to falseusers.accepted_date
blocked
totrue
Existing user/data
accepted_date
to all admin users. They're all pre-approved.scripts/
folder to pre-approve all existing users who currently has written at least 1 extry AND has no hidden entries.