This is because in activity_log_log_action() in activity_log.rules.inc, the created time is being set to $target['timestamp'] (i.e. the group node's created time) instead of the correct time. We use $target['timestamp'] instead of time() so that activity messages get the right time assigned when they are regenerated. This works when the action is "create new [status/node]" but not for any other action.
The fix is probably only a few lines, but not immediately obvious to me.
Using time() means all upgrades will have their activity completely out of order (in fact, probably in reverse order). If you want to make that change in Commons, fine, but it's not going into Activity Log.
I think the best solution is actually to have a special function like this:
function _activity_log_action_timestamp($value = NULL) {
static $timestamp;
if (empty($timestamp)) {
$timestamp = time();
}
if (is_null($value)) {
return $timestamp;
}
$timestamp = $value;
}
Then we should call _activity_log_action_timestamp(activity_log_get_timestamp($object)) in _activity_log_regenerate_object(). When we're actually saving activity messages, we can call _activity_log_action_timestamp() to determine the relevant timestamp.
We'll need some smarter handling in activity_log_get_timestamp() so it only uses the target timestamp when a status/node creation event is invoked. Also, there is no way to determine at what time a user joined a group, so I'm not sure what to do with group joins when regenerating.
Comments
Comment #1
icecreamyou commentedThis is because in activity_log_log_action() in activity_log.rules.inc, the created time is being set to $target['timestamp'] (i.e. the group node's created time) instead of the correct time. We use $target['timestamp'] instead of time() so that activity messages get the right time assigned when they are regenerated. This works when the action is "create new [status/node]" but not for any other action.
The fix is probably only a few lines, but not immediately obvious to me.
Comment #2
batsonjayYuk.
If this is a question of choosing between the two, we should optimize for normal activity, not status regeneration.
Unless you can see the "right" solution, maybe this should be changed to use time()...
??
Comment #3
icecreamyou commentedUsing time() means all upgrades will have their activity completely out of order (in fact, probably in reverse order). If you want to make that change in Commons, fine, but it's not going into Activity Log.
I think the best solution is actually to have a special function like this:
Then we should call
_activity_log_action_timestamp(activity_log_get_timestamp($object))in_activity_log_regenerate_object(). When we're actually saving activity messages, we can call_activity_log_action_timestamp()to determine the relevant timestamp.We'll need some smarter handling in activity_log_get_timestamp() so it only uses the target timestamp when a status/node creation event is invoked. Also, there is no way to determine at what time a user joined a group, so I'm not sure what to do with group joins when regenerating.
Comment #4
mstef commentedJoining/leaving a group, following a user activity items are timestamp-less.
Comment #5
icecreamyou commentedPretty sure this should fix it
https://github.com/acquia/commons/commit/f545cb7ead1f15427e7df7bf1a6dcd0...
Comment #6
mstef commentedTesting now
Comment #7
mstef commentedThat does fix the order in which they appear, but the message still don't contain visible timestamps. Is there any way to have that show up?
Comment #8
icecreamyou commentedUnrelated issue. That should be covered in #1258674: Some activity items do not contain time stamps