Aanand Shekhar Roy writes: > Hi, Does the following approach for auto moderation sound fine or > am I on the wrong path ?
I wouldn't call it "automoderation", I would prefer "post throttling". This is more suggestive of what is actually happening (moderation usually involves filtering on content). > > I think we neet to make changes in handler to_outgoing.py in method process. > 1) We need to make two databases : > Table1 Schema-> [ user_id | Thread name | list_id | count | > last_msg_posted_at ] > user_id, list_id, Thread name together act as primary key. > It stores the count of number of posts of a user on a particular thread > and the time corresponding to the last post. I think you should provide an option to just throttle the user on a given list, too. Possibly with different default throttling parameters. > Table2 Schema-> I don't see why you would have a separate table for messages. Just add the post_after_time attribute to the message's metadata. > [message_id | user_id |Thread name| list_id |don't_post_before_time] here, > don't_post_before_time=(last_msg_posted_at)+(count/10)*d I think you probably want count//10 here IIUC. I'm guessing you want the delay to be zero until the poster hits 10, right? In Python 2, 5/10 == 0, but in Python 3 it's 0.5. 5//10 == 0. > where, "d" will be delay set by list-admin, eg 3 hrs. > > 2) The count variable is accessed from Table1. > > 3) When process is called and a new message entry comes: > a) case 1: It is the first post by user on that thread then we create a > new entry in Table1 with count 1 and last_msg_posted_at_time = posting > time of that message. Then the corresponding entry is made in Table2 > with new count and calculated don't_post_before _time. > case 2: It is not the first post implies there is already an entry > in Table1 then we increase its count by 1 and we calculate > don't_post_before_time using count and last_msg_posted_at_time. > After making the corresponding entry in Table2 using values just > calculated we update last_msg_posted_at_time in Table1 with the value of > don't_post_before_time of this entry > b)Now we iterate over all entries in Table2 and whoever has > don't_post_before_time < current_time we remove the corresponding entry > form Table2 and enqueue it in outgoing queue else it stays in the > database. In my proposal to put it in metadata, you would just enqueue the message in outgoing and have OutgoingRunner check for post_after_time. If not present or present and expired, post the message, otherwise leave it in queue. If you do it your way, you need to have a separate queue (storage) for messages waiting for their post_after_times. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
