Team-Tea-Time / laravel-forum

A slim, lean forum package designed for quick and easy integration in Laravel projects
https://laravel-forum.teamteatime.net/
MIT License
602 stars 165 forks source link

Admin validation of content #285

Closed alextoader closed 2 years ago

alextoader commented 2 years ago

Hi,

I need to have my forum content validated by the admin before showing it on the website. (also banning users might be needed here) I am wondering if you want this implemented in the core too? If so, maybe we can communicate how you think is better to be implemented - maybe you want to make some rough specks?

Cheers, AlexT

Riari commented 2 years ago

Hey, sorry it has taken me a while to reply. I like the idea, but I'm a bit unsure about whether it should go into the core - if it does then I think it might warrant introducing a feature flags/toggles array in the config and having it disabled by default.

It would certainly be easier to implement in the core since it could just modify the existing posts table to add a nullable approved_at timestamp.

If you're not already working on a solution, would you be interested in doing a PR along with a feature toggle? Otherwise, would you mind letting me know what solution you're rolling with? Thanks!

alextoader commented 2 years ago

Hi,

This feature is for a project I am working on but is not exactly urgent. I just looked at what is waiting for us ahead and I am glad I did. So I don't have yet a decision but this looks like the best solution so far. I will come back in a few days with more details. Cheers! And yes I will do all that you said if we decide to go with this. I would like it to be in the core so maybe this will help with a bigger life maintenance hopefully :)

Riari commented 2 years ago

Great, thanks! In that case, some points to consider for a potential implementation when you get back to this (no rush):

  1. Would you only need this feature to be enabled globally, or on a per category basis as well?
  2. Would you need the ability to require approval of posts as well as threads?
  3. How granular would you need policy checks to be? Would a single ability such as CategoryPolicy::approveContent suffice?
  4. Would you need the ability to set a future approval date on an unapproved thread or post?
  5. Should unapproved content be visible in any way to other users?
  6. Should it be possible to unapprove a piece of approved content?

I have my own thoughts on these, which are:

  1. It should have a feature toggle to globally enable/disable the feature, and a new bool on Category to enable it for each category (similar to the existing bools for enabling threads and privacy)
  2. Ideally I would limit the feature to threads for the sake of a simpler implementation, but I can see the use in applying it on a post level as well
  3. I think either approveContent or both approveThreads and approvePosts in CategoryPolicy should be sufficient
  4. We would kind of get this functionality for free if we use an approved_at timestamp, but I'm not convinced it would be very useful (especially on posts), so I would prefer to omit this
  5. Unapproved content should only be visible to users with permission to approve it (similar to the way soft-deleted content is handled)
  6. I think this should be an option from a UX perspective, because a moderator/admin might mistakenly approve a piece of content but still want it to be available for other mods/admins to review. If a piece of unapproved content needs to be flat out rejected, then it should simply be deleted

Hopefully that makes sense - the biggest consideration for me is whether or not it needs to work on a per-post basis. If it does, then I'll think a bit more on how to do that efficiently as it would obviously affect things like pagination.

alextoader commented 2 years ago

Hi, good points. For me, the business requirement is posts approval not even threads. In forums, a common situation is spam posting. I already have a website where users can comment and with all the filters and captcha, I still get a lot of spam probably from real users. So I don't have time to actively moderate my content as it happens - I just go once a day and approve/delete spam. Also knowing posts require admin approval - discourages spam.

  1. I need this globally - I can't leave categories unguarded.
  2. Posts approval - this is our main objective.
  3. Not sure
  4. Agree - let's do features when requested or needed.
  5. Unapproved content should simply not be visible on the website - it should only be visible in admin->content moderation. Here we should have tabs like Threads, posts listed with a few actions available. Like: approve, delete, and then in future releases - send message to the user, ban user, temporarily block the user for X time.
  6. Agree - admins should see the Unaprove button on threads and posts. Such a post will be sent back to the moderation area.

From my perspective, the feature needs an approved_atand a page in the admin area (visible only to admins) where posts and threads are listed with 2 actions for the beginning - approve/delete. I tend to do things iterative - start with a minimal working solution then improve on it after I see how is working and I observe new requirements. I hope this makes sense. On the pagination, I don't see the problem - in the public website we just take content that is approved and paginate it - so could you detail this pls or any other issues you see?

Another concern I have is that I am a backend dev and not very good with Vue. I would need to bring a colleague to do the frontend part, which is not a huge deal but it goes out of my scope a little bit. So.. would you consider having the admin section done in the traditional way? Just asking not a huge deal.

Cheers!

PS As we go deeper into this, if you don't want to clogger the git with this discussion, you can contact me by email toader_alexandru@yahoo.com or other means of communication... whatsapp, teams.etc.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.