Skip to:
Content

bbPress.org

Opened 20 months ago

Closed 20 months ago

Last modified 20 months ago

#3378 closed defect (bug) (fixed)

User last activity showing "Sometime ago"

Reported by: johnjamesjacoby Owned by: johnjamesjacoby
Milestone: 2.6.6 Priority: high
Severity: normal Version: 2.0
Component: Component - Users Keywords: commit
Cc:

Description

When viewing a user profile page, sometimes their "Last Activity" shows "sometime ago" even when their last activity is saved and known.

In addition, if the current user has the throttle capability, their Last Activity never gets updated. This is likely due to a flaw with how that feature was ported over from bbPress 1.x, but is still incorrectly used here.

Change History (3)

#1 @johnjamesjacoby
20 months ago

In 7104:

Users: Correctly calculate offset in User Profile > Last Activity.

Previous to this, Last Activity was being saved with time() but then using the site offset on display. For negative timezones, this would cause "sometime ago" type output in screens like User Profiles.

Also correctly update Last Activity when posting new Topics and Replies, and add expiration to transients for anonymous users to prevent them from being autoloaded while also never expiring.

In branches/2.6, for 2.6.6.

See #3378.

#2 @johnjamesjacoby
20 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 7105:

Users: Correctly calculate offset in User Profile > Last Activity.

Previous to this, Last Activity was being saved with time() but then using the site offset on display. For negative timezones, this would cause "sometime ago" type output in screens like User Profiles.

Also correctly update Last Activity when posting new Topics and Replies, and add expiration to transients for anonymous users to prevent them from being autoloaded while also never expiring.

In trunk, for 2.7.0.

Fixes #3378.

#3 @johnjamesjacoby
20 months ago

In 7108:

BuddyPress: Mark all replies when marking topic notifications as read.

This commit fixes a regression - introduced in r6845 - that was causing marking topic notifications as read to fail. It fixes it by looping through all replies to a topic and attempting to mark them all individually. It is not a particularly optimized approach, but it does resolve the regression in such a way that accounts for both topic IDs and reply IDs.

In trunk, for 2.7.0.

Fixes #3378.

Note: See TracTickets for help on using tickets.