Posts made on hidden staff forums is bumping Recent Activities posts list on Dashboard down for guests and members

1st Official Post
    Affected App
    WoltLab Suite Forum

    Not sure if you consider this a bug or not?


    Here is what's happening. I have a staff forum hidden from view for guests and members. it is set-up to not count any posts made on it towards a members post count. What I'm seeing happen is that, if I'm talking to a staff member on that hidden forum and then look at the Dashboard page as guest logged out. Recent Activity (post list) is decreasing and not getting replaced with other posts (if all last posts made was on the hidden staff forum), none was made on public forums. So eventually a guest will end up seeing no recent activities on dashboard listed (posts) if staff are just using the hidden forum posting all the time. Same thing is going to happen for members as well, not just guests.


    Why are posts made on a hidden staff forum that members and guests don't have permission to see, are they bumping the post list down for them on Recent Activates on Dashboad page. And then not getting replaced with other posts because both groups don't have permission the view the posts that is bumping the oldest ones of recent activities list. I can have 10 posts from public forums listed to guests and members in recent activites on dashboard. If between me and another staff member we make 10 posts in 10 minutes on the hidden staff forum - there will NO recent activities (posts) listed to guest or members anymore.


    I have even tried unticking the boxes for the staff forum to: not index post in search, not count them towards similar threads, not count posts towards a members post count. Still makes no difference.

    • Official Post

    The recent activities are provided by the framework itself and feature a generic implementation to handle arbitrary activities. The only drawback is that you cannot verify the permissions on query time, it is required to fetch the activities and then check them against the corresponding data (e.g. checking access rights for a thread when handling a "liked a post" activity).


    Because these checks are rather expensive due to all the data being loaded, the system will simply flag all activities with insufficient permissions as inaccessible and eventually hiding them from the viewer. Interesting enough that it took over 2 years until someone actually noticed this, which pretty much proves the point that this behavior is all fine unless you have a very low activity forum with relatively high activity in non-public forums.

    Quote from Alexander Ebert

    Interesting enough that it took over 2 years until someone actually noticed this, which pretty much proves the point that this behavior is all fine unless you have a very low activity forum with relatively high activity in non-public forums.

    True, if other people are also using the public forums posting often that guests and members can read, then it wouldn't be so noticeable when staff are talking on a hidden forum at same time which guests and members cannot read. Still though, it's not ideal when you're using the Dashboard like I am as main landing page, relying a lot on "showing recent activities" to drive visitors to read latest posts made on public forums - if forum is small with not much activity going on and you're talking on a hidden staff forum with somebody. Visitors and members are often going to be seeing no recent activities listed at all, all because public posts keep being bumped off list by hidden staff posts being replaced with nothing else. What is worse as wel, is recent activities makes up for most the space taken up in middle area to extend it being longer than sidebar length. You end up with a very long sidebar and nothing much listed in main middle area.


    This same behaviour is going to happen as well. if lets say you created some forums that only certain usergroups can read and use, using forum promotions to move users into higher groups.

    • Official Post

    I can see your point and we don't take these kind of performance-sensitive decisions lightly. The primary issue is that it is not possible to determine accessibility ahead of time, which means that a specific amount of activities have to be fetched and populated with data (which itself requires more queries to get everything) before evaluation can take place. I'll try to describe the possible scenarios below:

    • (current) load a fixed amount of activities, slight chance of having one item being removed from view
    • load way more items (e.g. 40 all though only 20 are displayed at maximum), negative impact on performance, slight chance of having one item being removed from view (slighter than 1. though)
    • same as 1. but keep fetching items until the desired amount of accessible items is reached, awful performance and unpredictable resource consumption

    As you can see there is no perfect solution for this, every possible attempt to ensure ending up with fully filled activity list comes at a price. The chance of having at least one item removed from view is super low unless you have a small forum or almost all areas are non-public. Since neither of these cases match the average forum, we've went with a solution that covers roughly 99% of all forums perfectly and will not negatively impact performance on larger forums, thus scaling everything up nicely.


    To recap everything, our current solution is a trade-off between performance and usability. All though less optimal in some cases, it works for the absolute majority and will not change for now. We may make changes to the functionality of this feature in future major releases though.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login