Forum system - how to track already read vs new messages, per user

[eluser]Developer13[/eluser]
[quote author="xwero" date="1238600018"]I think you have to see this through a forum members eyes.[/quote]

Ummmm... *ahem* - OVER HERE! Read my post above? Take the CI forums for example. If you click on a thread which you have never read, then hit the back button and refresh your page, that thread becomes read. That's exactly how I like it AS A FORUM MEMBER. I wouldn't want it to NOT be marked as read because I didn't click through every single page and read every single post. So why should it be at the post level??

[eluser]xwero[/eluser]
Developer13 if you look at my second response i provided a solution for that in my second response

If you have a thread link you need to check the click date with the date of the last post and then add that to the read post ids table.

I never said the thread link should do nothing, it's secondary to the post link.

On the CI forum

- last post link next to the forum titles
- forum detail list thread link and post link

[eluser]Developer13[/eluser]
But you're still basing this on the post id which I am apparently too stupid to understand WHY you'd do that. Who reads a single post?

[eluser]TheFuzzy0ne[/eluser]
I agree. I think you just need to track the thread (and forum ID), and the date/time it was read. That way it's very simple to know if there are any unread posts for a thread, because the thread will contain a post where the date/time is a higher value than the one stored in the tracking table.

[eluser]xwero[/eluser]
The CI forum gives you the choice if you want to see the topic or the last post on the time the overview is requested. If you want to make a forum that only shows the last post, the most relevant link IMO, you don't need the thread.

I was thinking of checking the posts id with the latest post ids in the overview is easier than checking the thread id + the read date. in pseudo code this would be

Code:

foreach($page_threads as $thread)
{
     $status_image = 'read_image';
     if($thead->latest_post_date > $user->all_read_date && ! in_array($thread->latest_post_id,$read_post_ids))
     {
        $status_image = 'unread_image';
     }
}

If a new post is added between the time the member checks the page and the thread/post link is clicked that post id should be registered and not the post id of the link.

It's not the idea that the member has to click on every post to mark a thread as read.

[eluser]jedd[/eluser]
I feel like a bit of a twat - I never noticed the date field on the 'Topic Title' (/viewforum/) page was a link to the latest post in that thread - I've always gone to the thread and scrolled down. Oh well.


I think we're agreed that the reference table needs to contain [ user_id , thread_id , message_id ] ... yeah?

I like the idea of storing post_id rather than date, as dates are longer and harder to handle, and contain more information than I need here.

I think that the link on the thread-list (as per my first paragraph) should take you to the next message after the one that's listed in the reference table for the user - and not the most recent message in that thread. This is a subtle distinction, and not hugely important, and I'm also unsure how to elegantly code using just SQL (look for the selected row *after* another identifiable row). I can come back to that.

I like Fuzzy's idea of a self-maintaining table - older posts are cleaned out based on x-number-of-tracked-threads-per-user, or on anything > 1 month, etc. However I think this will be expensive, especially if the check function is called on every page load.

Having said that, I also grok D13's point about setting aside, or even making an allowance for, a finite number of threads to track per user. I agree that it's not the most elegant approach.

One of the points I'm stuck on now is balancing this problem - tracking sufficient number of threads, for an appropriate length of time, without preserving an unreasonable amount of completely useless data in that table.

xwero - I'm curious on your take on handling (or rather minimising) the huge range of permutations here - CI forums as an example, with 80,000 users and this thread number is 110399 - so you only track the correlation once a user walks into a forum - I get that - but do you ever untrack that connection? In reality, you (and the site) doesn't care that you read the last post in a thread that wound up in April 2006, right? You'll likely never hit a thread-list page that shows anything from that era.

Hmm .. I'm wondering if there's an algorithm in there to be had - something along the lines of any post older than (insert arbitrary figure - 2 months?) is considered read - and can consequently have any record of it removed from the db reference table. Again there's the problem of where and when do you clean this out for a given user, but that's slightly easier to solve.

[eluser]jedd[/eluser]
An observation.

On the /viewforum/ (thread index) page, where you get the Topic ... (1 , 2) link. If you get that highlighting as having new messages, and then click on the (1) link ONLY .. come back and refresh the thread index page - it shows that that thread is now fully read.

So the CI forums, at least, register any view activity anywhere within a thread as indicating that that thread is now up-to-date, even though the most recent message(s) have not ever been retrieved from the DB for the user.

[eluser]TheFuzzy0ne[/eluser]
Sorry, Jedd. Which method are you referring to here? The CodeIgniter forums?

[eluser]xwero[/eluser]
#16 response : this is what developer13 and i where discussing earlier. It seems i'm the minority that clicks the date link instead of the thread link as far as this thread goes.

Like i wrote it can be solved by finding the last post of the thread and add that to the read table.

#15 response : there are lots of actions to clean the read table

The all read link/button removes all records before the date the button has been clicked and the user read date is changed.
The thread/post link removes the record that presides the read record for that thread if there is one.
If a user gets deleted the read records for that user will be deleted.
If a thread is closed or deleted all read records for that thread will be removed.
If all posts are read the read table is cleaned and the user read date is changed

The one thing developer13 and my solution lack is a clean way to set a subforum (un)read. So the subforum id is something that needs to be added to the read table too.

[eluser]jedd[/eluser]
Fuzzy - yup, the CI forums.

xwero - the clean methods there still allow for a huge amount of useless information to be retained. I'm pondering different approaches still. Sub-forums - as in the category of forums - I'm happy to leave entirely alone, as I don't need that second level of indirection. So for me, 'forum home' will be a list of forums. Within each forum will be a list of threads/topics. Within each thread will be a list of messages. So at the moment my table is easy:
id
user_id
thread_id
message_id

I was just doodling on some paper, trying to work out the next step - doing notifications (if the user wants them - which is a flag kept in the user table of course) for posts in a given thread. Given each row of this table identifies user & thread (because there'll only ever be one message_id per user/thread combo, as you pointed out) I'm thinking a fifth column in here - a boolean - for notify. I can't see any benefit from putting that information into its own table .. yet.