Important NEW indicator disappears from unread topics after after a day or so

I've read that the behavior of the New indicator has been changed in K 3.0 in that posts say New until the user actually reads them. I've upgraded my forums, logged in, there were some new posts. I didn't read them, and logged out. This morning none of them are marked New, same behavior as before. What do I need to do to make posts stay New until the user reads them?

We can confirm that this is a matter that is being looked into.

See github.com/Kunena/Kunena-Forum/issues/1945

Ok, I think I found another interesting bug with the New indicator.

When the user clicks "mark topics read" in a category, the time is stored as a Datetime in the #__kunena_user_categories table. The time everywhere else is stored as a timestamp int.

In KunenaForumCategoryHelper there is a query:

$query = "SELECT t.category_id, COUNT(*) AS new
FROM #__kunena_topics AS t
LEFT JOIN #__kunena_user_categories AS uc ON uc.category_id=t.category_id AND uc.user_id={$db->Quote($user->userid)}
LEFT JOIN #__kunena_user_read AS ur ON ur.topic_id=t.id AND ur.user_id={$db->Quote($user->userid)}
WHERE t.category_id IN ($catlist) AND t.hold='0' AND t.last_post_time>{$db->Quote($session->lasttime)}
AND (uc.allreadtime IS NULL OR t.last_post_time>UNIX_TIMESTAMP(uc.allreadtime) )
AND (ur.topic_id IS NULL OR t.last_post_id != ur.message_id)
GROUP BY category_id";

UNIX_TIMESTAMP takes a Datetime and assumes it's in the timezone of the server.
The dates are actually stored in UTC (JFactory::getDate()->toUnix())
So unless your SQL server's timezone is set to UTC (which it isn't in my case), you get a difference of some hours between the values.

So people mark a category as read, and then it doesn't actually appear to have new messages until some hours later (your UTC offset). If they click on a category, it actually shows them that some threads have new messages, because the rest of the code correctly uses timestamps everywhere, the only place where the time is stored as a datetime is in the #__kunena_user_categories table.

I fixed this with a hack by putting in my server's UTC offset in that query. But maybe this should be fixed globally somehow.

Hope this helps somebody.

(P.S. This still refers to Kunena 2, but I saw the same query in the Kunena 3 source code, so I think the issue is the same.)

Read notification is designed to reset after logout -- basically if you don't return soon after the session times out, Kunena will assume that you have read all the messages you want to and forces all topics older than that to be read.

In Kunena 2.0 we improved this feature by fixing a few important bugs in it, but the changes also allowed to have unlimited read indication. However it was decided that the table is only meant to keep that data available during the session, with hardcoded upper limit of 3 days (after with the data will be deleted). That limit is still valid today.

I'm not happy with the limit, but to overcome it, we need to work around an issue of having the data available only 3 days for all older versions of Kunena. Basically the side effect could be to have all the read topics as new after the update for many users.


On the second issue I've never heard it before and the code hasn't changed after the major bug fix in 2.0.2 or 2.0.3. I'm also not able to reproduce it locally -- I've tried to do that few times during the last 3 days, with no luck. Maybe I'm missing something very obvious, I don't know.. Which version of Joomla are you using?

Are you able to provide actual real query you're seeing (debug mode on) and the result in phpmyadmin? I believe you, but it's a bit hard to solve the issue without being able to reproduce it myself.

OK. The obvious part that I was missing was this:

My computer is always in UTC, recardless of which timezone I pick up (using Ubuntu), so.. It was a bit hard to reproduce the issue. I'll figure out if there's another way to do it..

Here's how I figured out something weird is going on

$date1 = JFactory::getDate();
echo $date1->toFormat() . '<br>';
Result: 2013-10-06 21:01:00

echo $date1->toUnix() . '<br>';
Result: 1381093260

then do this in mysql: SELECT UNIX_TIMESTAMP('2013-10-06 21:01:00');
Result: 1381118460

The difference is the time offset. Arguably, it's a bad practice to have php and mysql run in different time zones (one of them is not UTC), but I am not a shared server so I don't think I can change it.