Recent Submissions

#1

Okay, maybe we can't have a perfectly tuned mechanism for remembering recent submissions. So how about an imperfect one?

This is the way I remember the old functionality of the Citadel. It may be wrong or depend on some bug, but let's see:

- on logging into the main part of the website, all submissions and comments newer than the last login were recorded on the Recent pages and the comments had their background changed
- the last login time changed to the current time, when one visited the forums... if a Recent page was refreshed, it was most likely empty
- the Recent pages contained anything newer than the last visit of the forums, thus you could see what has changed if you have been away for a while, writing something or chatting - just remember to refresh the page before doing anything on the forum

This may not be the most perfect mechanism, but it does have its logic and you can get used to it - and it should be rather simple to implement, remembering one date and showing everything new.

And it's way better that nothing. :D

Re: Recent Submissions

#2

We do have recent unread in the forums, I don't remember where the link to it's hidden though I've got the url saved... http://www.strolen.com/guild/index.php?action=unread
As for the submission/comments, I thought there was something like that lying around somewhere...

Re: Recent Submissions

#3

Now wait, isn't that pretty much, how the Recent page works? After logging in, it shows everything recent without emphasis. But as new comments are added, their subs are shown in red (at least until one visits the forum).

If we just could have the same functionality for New Since Last Visit - measured exactly against the previous login timestamp, overwritten by a visit of the forums, we could have what we want.

How about that?

Re: Recent Submissions

#4

Did you check the new since last visit right after checking the recent page? They both work off the same timestamp.

It really does sound like an easy request. The timestamp, how it is saved and when exactly it is rewritten is the bear since the forum and site use the same session information. Might go back to the easy fix "new in last 24hrs" and give a choice to increase that time. At least that will work as expected without having to do some crazy submission tracking to figure out what is actually new/old/viewed/unviewed like the forum.

Re: Recent Submissions

#5

http://www.phpbb.com/community/viewtopic.php?p=2987015

Still trying to find a reliable way to do this.

In the same vein, trying to figure out how to notify each author on actions on their posts. Might be a whole new database to track when somebody upvotes a comment, replies to a submission that you have a comment on, etc. Make the main Citadel more like the forum and help spur discussion.

Re: Recent Submissions

#6

http://codeigniter.com/forums/viewthread/134303/P15/

OK, Manfred. Lets figure out how to do this puppy.

Re: Recent Submissions

#7

For any given thread there are several states for a given user:
a) the user has never seen the thread
b) the user has read the thread - including the most recent message - they are up to date
c) the user has read the thread - but has not seen 1 or more of the most recent messages

Views will only be counted when they go to the sub. If they go to the sub, read.

database:

user_id
content_id
read/unread flag

I don't see a need for a date as they discussed. If a comment is updated, mark all the content_id unread for all users.

Does every subscriber subscribe to every submission by default then? # users * # subs?

The good thing is that not every forum user has a Citadel account. I don't make a Citadel account for them unless they actually visit the main Citadel. So all the spammers and such never got a Citadel id. So the total users won't be as high as it is in the forum.

This forum has 2 tables to track it looks like. One tracks the overall forum views, the other tracks each thread.

This is the board tracker, I guess would be like tracking new posts in Items, NPCs, etc. along with the latest sub_id of the entire site. Not sure what that does for them yet except to compare if post is > id_msg then it is new maybe?

id_board | id_member | id_msg

I am not sure I want to track that. If our frontpage was more forum like, which I am not sure I want to go to, with each main category shown then maybe it would make more sense. We seem to be individual submission centric. I guess if we figure out the sub part the other wouldn't be too difficult.

They also track "sent". Here is the table for tracking threads.

id_member | id_topic | id_board | sent

which would be the email notification. So if there is a new comment we would only send 1 reply and tell them there might be others but they won't get notified. Currently I just send them all. :)

So, looking at that, I am still back to the original 3 column table for simple tracking. I was going to have a flag vs. them tracking the most recent sub_id. Not sure the most recent sub number would help but they are obviously smarter than me so need to figure out the why of it before I go off on my own....

Just thinking out loud to get the logic down.

Re: Recent Submissions

#8

Read a tiny bit more on it. This forum tracks read comments.

For us:

user_id, content_id, comment_id

So thinking now, and will write in long hand vs. the id to keep it straight. I visit a submission. The database updates the comment_id for me on that post.

Strolen | Sword Post | Comment # 2

Two more comments are posted, Comment # 3 and Comment # 4.

I visit the site again and view recent.

I do the search to grab all threads that are lower than the current...and get lost. How to identify them with the sub? Comment 3 and 4 may have been on any number of other posts.

How the hell does the latest post id help. ugh.

Just have a flag, if somebody posts a comment in a sub, set it as unread until the visit it. Done. I don't know what queries to run to use the comment_id and match it to the sub to identify the sub as unread. sigh

This thread too: http://codeigniter.com/forums/viewthread/110399/

Re: Recent Submissions

#9

This makes more sense to me but still have to get absorbed into the matrix to have it happen.

quoted from various sources 3 years ago and I found it in an old work document I put together when I was in the middle east. Yes, I have been trying to figure this out for 3 years. ;)

I didn’t get a chance to reply before the thread was locked but I wanted to. The forums are using Beast software, which
Rick Olson and I co-wrote… and 37s is right that’s it’s a royal pain to track read flags on messages in the database
individually. Beast “cheats” by using a combination of your last login time and your browser session to store what
you’ve “read” since your last login… anything prior to your last login is already considered read. And while your browse
your last login time is updated in the database but your session continues to remember what was new when you first
logged in… I’m probably not explaining it the best, but it’s pretty slick.

A little more complex than 37s first implementation but falling far short of their final solution… which I assume is an
actual read flag of some sort in the database for every user for every post…

There are two tables (TOPICS_TRACK_TABLE, FORUMS_TRACK_TABLE) and a user field (user_lastmark) keep that data.

Lately I tried something about and failed, nevertheless learned the principle , get_topic_tracking() function obtains the
unread info.

TOPICS_TRACK_TABLE

In order to obtain unread info, firstly the topic_tracks_table checked if topic last mark time is earlier than message time
with that topic_id. If there is no record for topic_id, ignore this step.

FORUMS_TRACK_TABLE

If the last mark time of forum is earlier than user last visit time and message time in a topic, post or topic may be
unread.

user_lastmark in USERS_TABLE

If there is no count in topic_tracks and forum_tracks table, user_lastmark compared with message time. Then, topic
unread info obtained.

That is what I understand.

You cannot store a permanent indicator of all "read" posts. The amount of storage would exceed that needed for the
actual information. Imagine what would happen if someone signed up on this forum and he marked all existing 664,831
posts as being read. You would not and could not add that many entries to a table or add their user information to that
many entries.

You need to use a date/time "bookmark" system. You could probably examine the SMF (forum) code to see how they do
it.

You basically have a "bookmark" column in the user data table. When someone signs up, the value is set to the current
date/time. This prevents ALL the "unread" items before that point from showing up.

You then store unread items in a short term table. When someone visits your site (any type of activity/page request),
add all the items that are newer than their last "bookmark" date/time to an "unread" table, using their user id as the
key, and update their "bookmark" date/time to the newest data/time on the items that were just added to the short
term table. When you display the items for that visitor, if the item is in the short term table, mark it as "new". As they
read the items, remove that row from the short term table. If they click on a "mark all items as read" link, remove all
their rows from the short term table. If they click on a "mark this item as unread" link, add that item to the short term
table.