Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow moderators to hide or delete offensive content #182

Open
brylie opened this issue Apr 23, 2018 · 4 comments
Open

Allow moderators to hide or delete offensive content #182

brylie opened this issue Apr 23, 2018 · 4 comments

Comments

@brylie
Copy link
Member

brylie commented Apr 23, 2018

We want to discourage trolling or other abusive behavior in the CiviWiki community. Create a basic moderation system to allow admin users and moderators to hide or delete threads and other content. Use the inbuilt Django role base access control where possible.

@delta-plus
Copy link
Contributor

Okay, how does this approach sound: When a user is to become a moderator, they're added to a moderators group from the admin panel which has permissions like "Can delete/change thread", "Can delete/change civi", etc. Currently, the deleteCivi function in write.py only checks if the user is the author of the civi before deleting it. I'd modify that to also delete the civi if the user has the correct permissions (user.user_permissions). I'd also add a view to threads which would only be visible to moderators and admins and would allow hiding/deleting anything in the thread (including the whole thread). Perhaps something like Reddit's "Comment score below threshold" feature could be added to hide civis that are only slightly evil, but allow them to be viewed after clicking some icon deliberately.

@JOO33
Copy link
Member

JOO33 commented Apr 30, 2018

@delta-plus Sounds good, but seems like there are multiple facets to the idea, and while it sounds like a great feature, I would hold off on the hiding/threshold feature until a later milestone. I recommend you first focus on just the moderator role. The current system we have lacks a organized permission system and a group structure, so this will be a great time to implement it as well if needed.

From all this it seems to me there are three main use cases to get at initially:

  • Users can be assigned/removed as moderators on a Thread
  • Moderators can modify the assigned Thread
  • Moderators can modify Civis within the Thread

@brylie brylie added this to the 0.3 milestone May 1, 2018
@brylie
Copy link
Member Author

brylie commented May 1, 2018

At the very least, hold off until 0.3 milestone. We still have work to do in 0.2.

@GokuMizuno GokuMizuno self-assigned this Aug 10, 2018
@GokuMizuno GokuMizuno modified the milestones: 0.3, 0.4 Sep 19, 2018
@jgbmattos
Copy link

@JL24. Looks to me that are two different approaches for this problem:

  1. To have a global permission for editing/deleting threads/civis.
  2. Assignee a user as moderator to one specific thread.

For first approach wouldnt be better to use the already existing permissions, "api | thread ..." and "api | civi ..."?. It seems that those permissions are not being used, at least in that context.

For second approach, i think it would be necessary to create another permission, something like "api | moderator | add/remove" and in the front end check if the current user has moderators permissions and if true show a button to add some user as moderator to the thread.

In order to add some user as moderator would be necessary, as well, to create a couple of tables relating users to threads and users to civis.

I didnt fully understand why something more than the first approach is necessary in current scenario.

For future implementations would be nice to have some sort of notification, that her/his thread civi is being deleted/hide etc.. Also if any user could by moderator, maybe would be necessary to have some way to notify bad behavior by moderators

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants