basic spam detection

[sgfost]

uses two methods:

• timing form load->submission time
• using a honeypot field hidden from real users with css

logs actions to a SpamModeration model with a generic fk to content models. actions such as deactivating the user or allowing the post can then be taken via a WIP admin view

TODO:

• [x] test coverage
• [x] usable admin view with
  • confirming/rejecting spam assessment
  • filtering
  • option to deactivate user on confirm (or default?)
  • email reminder when X number of spam objects pile up, or after Y amt of time (?)
• [x] add more context to SpamContent detailing how/why we think its spam, flexible enough that it can also be used for detecting with NLP (think ahead to reconciling #693)

resolves comses/planning#235

[sgfost]

spam content, and deleted events/jobs for that matter, still show up in the site-wide search. Need to find a good way to filter those from the general search but struggling to figure out how it currently does this for non-live codebases..

[alee]

spam content, and deleted events/jobs for that matter, still show up in the site-wide search. Need to find a good way to filter those from the general search but struggling to figure out how it currently does this for non-live codebases..

good catch, we should have a

@classmethod
get_indexed_objects(cls)

defined for Events, MemberProfiles, Jobs

[sgfost]

ah that's it, thanks

The bulk of this is done, just need to put up a few tests. I think it ought to work as a more flexible base for using the work in #693 as another detection method, but lmk if you have any thoughts or concerns when you get around to it

[sgfost]

Thx, I'll make a new issue with these needed changes as to not block merging if its in a 'good enough' state