This bug probably doesn't affect many users, and only those with multiple boards.

We're using RankID to display album user stats among other places, I suspect. There's some sort of rankID assignment bug with multiple boards that I haven't tracked down but which affects certain processes like displaying a user's profile. The album_getstats() method is returning nulls for usrAlbums and usrAlbumImages causing a runtime.

Attached yaf0601a.jpg is the runtime.

Attached yaf0601b.jpg is what's being returned from yaf_user_getalbumsdata.

Attached yaf0601c.jpg is the yaf_rank table showing the issue. The user's assigned rank in yaf_user is "10", the current boardID is "1." So no records are returned so the isnull(c.UsrAlbums,0) isnull(c.UsrAlbumImages,0) has no effect as @RankData table has no records.

The point is that using a single RankID value and support multiple boards seems a bit off. What I'll do is update the RankIDs to support BoardID =1 (the main forum) and monitor when changes occur.

Thanks,
Dave

We're using RankID to display album user stats among other places, I suspect. There's some sort of rankID assignment bug with multiple boards that I haven't tracked down but which affects certain processes like displaying a user's profile.

Lo mate.

Bet you a beer that its when a user posts and upgrades to the next rank. The upgrade routine doesn't pass the boardID or take it into account to get the next rank; they then have a rank thats not linked to that board.

Let me know as this is gonna cause me a migraine when I finally get my multiboard installation running.

---

Actually I stand corrected; someone fixed that one. Kudos to them.

---

Let me know as this is gonna cause me a migraine when I finally get my multiboard installation running.

LOL! I'll start looking into this today yet. I may not have the exact sequence of events for you, but we should know when the rank change occurs. You're right, considering requiring rank-based functionality in additional boards and basing logic on boardID=1 ranks, we could be popping a lot of Excedrins.

I'll post back with anything pertinent to the cause.

Thanks for your comments,
Dave

Mek, Dave... let's make sure and start an issue on the tracker if this is deemed an issue. Otherwise, we lose track of what got changed where. 😉

Mek, Dave... let's make sure and start an issue on the tracker if this is deemed an issue. Otherwise, we lose track of what got changed where. ;)

You da man, so what you say I do. I'll add something to the tracker in the next 24 hrs. Want to look at it some more.

Thanks,
Dave

Good news to report and an embarrassing confession. First the confession, I was missing a critical piece of YAF logic in that each board creates its own user. So while my report was correct (user daveburke in Board 1 had a rankID of 10, which was associated with Board 2--causing the runtime on yaf_user_getalbumsdata null data), I found no bad RankID assignments from any Board 2 processes.

SO FORGET THE BAD RANKID ISSUE, in other words. How certain of my key user RankIDs got screwed up, I don't know, but I'm not worrying about it. Mek, we don't have to budget for Excedrins anymore.

My apologies for the noise. I do have some thoughts on the yaf_user_getalbumsdata logic which I'll post on a separate thread.

Thanks,
Dave