New topic list not populating correctly
When browsing the topics, the New header shows that there is one new topic I haven't read. In fact, this appears to be accurate because I can just see the topic near the bottom of the browser when it is full screen:
However, going to the New list tells me that I have no new topics:
Bug: New list is not populating correctly.
Repro: Windows 7 Chrome 35
Note: I do have the Meta > Bug category muted, but since the new topic is in Meta, I don't believe that this should be an issue.
One topic was recently moved out of "meta/bug" to "meta".
If that was the cause of this bug, I would expect to not see the topic in the Latest list either. But, as shown in my first screen shot, it does show in my Latest list. That indicates that there is probably a bug in the generation of the New list.
Live correction of recategorization is a hard thing to fix and a bit edge casey, let me know how you feel about the new muting fix I deployed, bugs should really just fade to the background for you.
Is this another instance of the general case of moved topics/posts being marked as unread again?
Nahh I think this is far more subtle ... the machine needs to do a lot of magic if someone changes categories from something you care about to muted.
Live correction of recategorization is a hard thing to fix and a bit edge casey
Except for two things:
- I never saw it as topic in Meta > Bugs. Not once. You can see that if you look in my screenshots (which were taken after a Ctrl+R refresh). So I don't think that this is just a case of recategorization.
- If this were just a recategorization issue, then why was it showing in my Latest list and not my New list? Again, this is after doing a Ctrl+R refresh.
And it honestly wouldn't be that hard to fix if you are getting the lists by doing live DB queries. Just ask the DB which topics are new for the specified user that they haven't muted. Based on earlier comments, Discourse is obviously database driven. Just thinking about it real quick:
- Category/topic status (such as tracking, muted, etc.) could easily be a per user flag in the DB. Just have a table that links the user and the topic/category, and indicates the status for that user. Everything that is driven off of the status could then look at that table to determine the correct behavior for the user.
- A topic's category should just be a foreign key relationship. Period. No need to do anything fancy.
Obviously there's a lot more to the database than just that, but approaching this from a "never-done-a-forum" perspective, that's what I envision as being absolutely pertaining to this bug. Then you use whatever logic you want to build the lists, using the stuff I've identified above as filters.
Based on what I've provided, it's apparent that when building the Latest list, the Mute filter you currently use is working correctly. But it's broken when building the New list. Maybe it is an edge case, but it's a legitimate bug.
let me know how you feel about the new muting fix I deployed
I'm not your tester. I identified a bug, and I was nice enough to let you know about it. With @codinghorror's help, I even helped you pin down the exact scenario where this bug occurs. But I will not spend my time trying to reproduce to see if a related change has fixed this particular bug. That's your job.
But I will not spend my time trying to reproduce to see if a related change has fixed this particular bug.
Is this another way of saying you don't really care if it's fixed?
Not really what I was going for, but I suppose that's one way of looking at it.
Really, I was saying that I'm not devoting more time to determining if they've fixed their bug. Especially since this isn't really something I could test on my own, unless I create a second user account.
OK, I get where you're coming from. It just seemed weird that a deveper would ask the reporter if the bug he reported still existed, and the reporter would tell the dev to take a hike.
Filed Under: Acceptance testing