Moderating the events and users.

[intelagense]

This discussion involves issue #213 and some further changes that may be needed for the event and user schemas. This is a proposal for how to handle some of the moderation after implenting AdminJS.

Users schema:

The registered users will need roles to access the AdminJS interface and create events. Users may also be banned if necessary.

Roles:

• admin An admin user has full access to the AdminJS interface and can perform all administrative tasks, including managing users, events, and other content.
• moderator A moderator user has limited access to the AdminJS interface and can perform moderation tasks, such as reviewing and approving events.
• user A regular user is a member of the community who can create and view events, but does not have access to the AdminJS interface.
• probation A user on probation is restricted from creating events due to a reported or flagged event that is currently under review.
• banned A banned user is no longer able to access the calendar app or create events.

userNotes:

Additionally a userNotes string or array can be used to store messages from the moderators as well as any additional info generated or collected at the time of the offense.

Events:

The event status states indicate the current status of an event.

Status:

• moderated This state suggests that the form data has been reviewed and approved by a moderator.
• unmoderated This state suggests that the form data has not been reviewed by a moderator, but is assumed to be good.
• flagged This state suggests that the form data has been flagged by a filter or registered user has reported it as potentially bad, and is waiting to be reviewed by a moderator.
• denied This state suggests that the form data has been reviewed by a moderator and found to be inappropriate or harmful.

eventNotes:

A eventNotes string or array can be used to store messages from the moderators and admins describing any actions taken.

Usage

With these fields in place, we can stack levels of protection as needed instead of a "one size fits all" approach to moderation.

1. Reactive moderation

At the basic level, moderation only occurs after an event is flagged or reported. This means that all events will be visible on the calendar unless they are specifically reported by a user or flagged during form submission.

2. Lazy moderation

At this level, moderation is optional but events will be hidden from outside users unless they are approved by a moderator. This will keep the calendar view clean for outside visitors, and does not require moderation for all events. However, this also means that valid events may be hidden from users who are not logged in or do not have an account. One way to address this issue is to include placeholder titles on unmoderated events which can encourage the users to log in to see the event details.

3. Fully monitored moderation

The next layer would be to hide all unmoderated events until they are approved by a moderator, requiring manual approval of all events. This is the most restrictive level of moderation and requires a lot of overhead, but also provides the highest level of protection for both outside users and registered users.

4. Dystopia

The fourth layer is to completely hide the calendar from all outside viewers in case of a serious problem.

In all cases, any event that is flagged or reported should be hidden from the calendar for all users except the user who created it. The user who created the event will see it on the calendar as a greyed out event with text indicating that it is pending or under review.

[MatthewBozin]

This seems doable, we could add some middleware on the backend that filters the array of events to display based on the current level of moderation.

[InstincDev]

These changes will validate the use/need of AdminJs. Once the Schemas are updated, human moderation as well as changes to the levels of moderation can be easily handled through the dashboard.

[isaaclee12]

I'm a proponent for level 3 - Fully monitored moderation. We could have the backend do some basic filtering to ensure none of the big no-no words get in. This would alleviate some of the workload on whoever would be manually approving the posts.

I had the idea that we could have two independent tables with one containing "pending" posts, and another containing "approved" posts.

Another thing to keep in mind is how we control who has access to the Adminjs, and how admins and moderators would access the admin.js for the production build. I'm wondering if the Adminjs could be deployed as a separate app with it's own GitHub repository on cyclic that simply connects to the MongoDB database. This would allow us to have control over who can access the source code for AdminJS, and give us an extra layer security via obfuscation of the admin interface.