User profile "notifications" page always shows data of logged in user, regardless of uid in the url [#2108377]

Below is screenshot (names changed) showing inconsistent information on John Smith's user profile page. I can't tell if he is following 0 groups (per "0" in tab title) or following 1 group (since there is 1 group listed indicating that John is following that group)

The number of groups being followed should be displayed unambigously

Following 0 or 1 group?

Furthermore, if I click on the tab "Other Content John I Smith Follows" then I see 6 items listed, not 3.

So I think the numbers displayed in tab titles are wrong.

Comment	File	Size	Author
#3	flags_follow_show_per_user_MODIFIED_VIEW.png	7.54 KB	WebSinPat
#3	flags_follow_show_per_user_ORIGINAL_VIEW.png	4.31 KB	WebSinPat
	groups_following.jpg	18.06 KB	behoppe333

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

behoppe333 CreditAttribution: behoppe333 commented 9 October 2013 at 18:58

Title:

User profile "notifications" page shows wrong #s in tab titles

» User profile "notifications" page shows inconsistent information

I did a bit more research, aided by fact that I already had maillog module installed on my site. Maillog's report of sent emails is consistent with the 0 shown in the tab title: when new posts are added to my moderated group, no email notifications go to John I Smith.

I have changed title of this issue to indicate that I think error is probably in the body, not the title, of each tab on the user notifications page.

Comment #2

WebSinPat CreditAttribution: WebSinPat commented 2 November 2013 at 01:34

I see similar behavior in my installation. in my case, I think the discrepancy comes that although the "title" says "John Smith Follows", the body is actually showing the information for the logged in user. The body stays the same no matter what uid is in the URL user/[uid]/notification-settings. Whereas the title does change to reflect the URL, showing "John Smith Follows" for that user vs "you follow" for the logged in user.

So I'm guessing it's a configuration in the view that displays the info.

Comment #3

WebSinPat CreditAttribution: WebSinPat commented 2 November 2013 at 03:42

Title:	User profile "notifications" page shows inconsistent information	» User profile "notifications" page always shows data of logged in user, regardless of uid in the url
Issue summary:	View changes
Related issues:		+#2001702: Message Subscribe sends emails regardless of flag checkmarks in notification-settings

File	Size
flags_follow_show_per_user_ORIGINAL_VIEW.png	4.31 KB
flags_follow_show_per_user_MODIFIED_VIEW.png	7.54 KB

@behoppe333, let me know if you think I'm taking over your OP if you think your issue is not the same.

I found reference to similar behavior in #2001702: Message Subscribe sends emails regardless of flag checkmarks in notification-settings of always showing the groups followed by the logged in user even when claiming to be for another user. The issue was supposedly fixed for Commons 3.3, but I am still seeing the problem.
The fix in #3 of that issue at https://drupal.org/comment/7483678#comment-7483678 does pass the user object $account as an argument to the relevant functions, but then the view itself (e.g commons_follow_node) is not configured to expect a uid as an argument.

This is the original view configuration which does not have any user relationships and indeed displays flags "by current user"

orginal view does not have any user relationship and displays "by current user"

Here is the modification I made to incorporate the user argument (according to instructions I found in an unrelated issue #1191228: Display Nodes Flagged by a Given User (rather than current user) in a View )
now view relationship and contextual filters included uid, and the flag displays "by any user"

This change is giving me the behavior I expect when I visit user/[uid]/notification-settings.

I'm not sure if this is the right fix for the issue. I see that in message_subscribe_ui.module

 function message_subscribe_ui_tab($account, $flag_name = NULL)
....
$view->set_arguments(array($account->uid));

so the uid is attempted to be passed programmatically rather than by the uid in the URL.
but all the same it does seem that the view is not receiving the argument with the original configuration.

Comment #4

WebSinPat CreditAttribution: WebSinPat commented 5 November 2013 at 00:56

I found this related issue #1920824: Admin viewing another user's notification settings tab shows admin's notification settings that discussed this same issue. The conclusion there seemed to be that another solution would be to disable anyone (ie. user1) from viewing another user's notification-settings page at all, rather than dealing with fixing the relationship and contextual filters of the flag/view code. There is a patch at that issue, which I have not yet tested.