Forum

But the same logic is used in the threaded mode - if you display the message, it means you've read it.

Yes, but in threaded mode, I select the one message I'm interested in to mark it as read. I can display their subject lines with indicators of whether they are read or not first. So, clicking on a discussion in threaded mode doesn't display all of the messages on the screen at one time.

Maybe the 'seen/unseen' will work. Good idea.

I was avoiding this intentionally...    I think we ignore that for now, and treat it as unseen. Ideally, it would be nice to have a mail responder that would allow me to mark it as seen from my inbox - maybe even provide a reply - but that's future....

mike

But seriously, my concern is only for the nested and flat modes. If I join a discussion already in progress, or don't follow it as often as I should, or its simply just extremely active, then all of the posts are displayed the moment I access it. What if I don't get 'round to actually reading them all that time? That's where I find it a bad thing to mark 'displayed' as 'read'

With threaded, its much more obvious.

Okay.

Let's start at the list of discussions page. Here we currently list the discussions in the forum with number of replies. The only call we have to make at this time is to count the number of replies to the discussion post (already required):

SELECT p.discussion, (count(*)) as replies
    FROM forum_posts p, forum_discussions d
    WHERE p.parent > 0 AND p.discussion = d.id
    GROUP BY p.discussion

To add any other information (number read / unread), we will have to as a minimum, make one more SQL call.

My way, would require two more calls, one to count the posts before the cut-off date (and therefore read) :

SELECT COUNT(*)
    FROM forum_posts
    WHERE discussion = $discussionid
        AND modified < $cutoffdate

and one to count the read posts:

SELECT COUNT(*)
    FROM forum_read
    WHERE userid = $userid AND discussionid = $discussionid

The total unread would be the number of posts less the other two counts. We already do the total number of posts. The forum_read sql is relatively painless because we're searching on two indeces. The only expensive part is the count of posts by date - the one your way wouldn't need.

For the forums and course pages, currently we only count discussions, not posts. So, no matter what we would need at least one more SQL call. If all we want is to display unread posts, your way will be the cheapest by far. But, wouldn't we want more info - number of posts as well? I would think that if we're going to display unread posts per forum, we probably want to be able to display total posts per forum as well. In fact, it becomes pretty complex once you want to count posts for a forum.

$total_posts =
SELECT COUNT(*)
    FROM forum_discussions d, forum_posts p
    WHERE d.forum = $forumid AND p.discussion = d.id

$expired_posts =
SELECT COUNT(*)
    FROM forum_discussions d, forum_posts p
    WHERE d.forum = $forumid AND p.discussion = d.id
    AND p.modified < $cutoffdate

$user_read =
SELECT COUNT(*)
    FROM forum_read
    WHERE userid = $userid AND forumid = $forumid

Maybe we should also think of adding the forum id to each post? This would allow us to more easily count these records without having to merge the discussion table all the time. What do you think to that?

I'm not against storing unread posts, its just that I like the idea of tracking only one event by using read posts (view the post), vs. several using unread posts (add post, update post, add user, remove user).

mike

I actually did it the other way around...I set Moodle to recoginze the Username and Password for phpBB.

To do this:

1. log into Moodle as an Admin and click on "Users"
2. Click on "Authentication"
3. From the dropdown select "Use an external database"
4. Complete the database informaiton (blue area below) for your phpBB database.  You should know the database name, user and password...these are for your phpBB database. The table is named "xxx_users" (replace the x's with whatever you set the table prefix to be). The database user field is "username" and the password field is "user_password". (You may want to check these in your phpBB database just to make sure, but I assume these will be the same since they are created automoatically by phpBB).
5. Since the passwords in phpBB are encrypted in the database, I selected "MD5 encryption" for the last entry.
6. The remainder of the entries are optional and pretty self-explanitory.

Save these settings and you are done.

Now, you won't be able to create accounts in Moodle. You create your accounts in phpBB and then use the same username and password to log into Moodle. Once you create an account in phpBB, the first time you log into Moodle it will prompt you to complete your profile for Moodle.

Hope this helps.

Steve