Posted by Enideo on November 17, 2011 at 4:49pm
2 followers
Jump to:
| Project: | Activity Log |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
So in the end we have multiple messages about joining organic groups.
I have a feeling this may be because there's no date parameter?
Comments
#1
Actually I think the issue may be related to also using the realname module
#2
#3
I think this is related to #1344938. I've spent a little while looking at it.
Adding 'target_type' => 'user' to:
'og_user_insert' => array('callback' => 'activity_log_regenerate_og_join',
'file' => $path,
'target_type' => 'user',
),
certainly removed the old entries, but I think that's incorrect behaviour. I'm stumped at how to do anything else right now, would really like user's own profiles only to show their activities!
#4
I don't quite understand the problem you're describing but I think this issue is the same as #1351904: Joining organic group not appearing with correct date
#5
Sorry but I don't believe this is a dup, let me try to be clearer.
First of all, it's not technically on the 6.x-2.x-dev branch, it's the one that comes with commons (I believe that is 6.x-2.0-beta1). Having said that, I have applied the #1351904 patch (and some other small, not relevant ones e.g. #1273288 ). As a side note, when I use the dev branch, it's a complete mess as none of the tokens are replaced.. I'm not sure if this is Commons' fault or not and for now, I don't have time to investigate.
In my case, on regenerating activity (multiple times even, during development at least) I start to see multiple activities for each time a user joins a group. I realised that the part of the code above is used to remove entries from the database in the function activity_log_regenerate_prepare() and that without a target type, those entries weren't being removed. In my db, the target_type is clearly 'user', hence my change above correctly removes these entries.
So whilst this has been fixed, I'm not sure it's the correct approach. For one thing, 'user' is already declared as a target_type in the same function for the 'user_insert' key. (I have to admit, I'm not 100% sure what target_type is exactly referring to, whether it's acting user or context related. Perhaps the target_type entry should be written in the db as 'og_user', but I have no idea how to write this, those rule actions are way too complicated!
The main reason I'm still concerned that the fix above is wrong is because it has the effect of not showing any og_user_insert activity the news stream or groups streams (but it is on user streams). At this point, I am rather lost.. perhaps you could point me in the right direction or we can work together to get a solution, either with this branch or dev if you think this issue has already been resolved.
In any case, for now, I'm not panicking, I will just continue without showing when people joined groups, for my users missing info is better than incorrect or duplicate information.. However fixing would be best, for everyone.
#6
Ah, got it. You're right, this is broken. Turns out there's not any straightforward way to tell which activities are related to which Rules events, so Activity Log takes the easy route and just deletes activity messages that are about the entity types that certain Rules events are associated with. The "group join" action isn't associated with a specific entity type, so Activity Log doesn't know what to delete for it.
The "right" way to resolve this is to examine every Rule to see if it reacts to the og_user_insert event. If it does, then check if it has activity message templates associated with it; and if it does, then delete any activity messages that use those templates.
The "easy" way to resolve this is to disallow regenerating group joins.