Expose a views handler "MySite user" for other modules to add a MySite uid filter [#198904]

For other modules (like OG) to show nodes pertaining to a mysite user, instead of the currently logged-in user, MySite could expose the following functions:

/*
* Allow replacement of current group so we can cache these queries.
*/
function mysite_views_query_substitutions($view) {
  global $user;

  if (arg(0) == 'mysite' && is_numeric(arg(1))) {
    $uid = arg(1);
  }
  else {
     $uid = $user->uid;
  }
  $ret_array = array('***MYSITE_USER***' => $uid);

  return $ret_array;
}

/*
* Simple array for MySite user.
*/
function mysite_handler_filter_mysiteuser() {
  return array('***MYSITE_USER***' => t('MySite User'));
}

In the case of OG, it may be then able to add a filter to the current filter set:

+        'mysiteuid' => array(
+          'field' => 'uid',
+          'name' => t('Og: Post in MySite User Subbed Groups'),
+          'operator' => 'views_handler_operator_eqneq',
+          'list' => 'mysite_handler_filter_mysiteuser',
+          'list-type' => 'select',
+          'help' => t('Posts are filtered to groups that current MySite user is a member of.'),
+        ),           
+      ),

This filter would be almost identical to the existing OG filter "uid". I'm submitting this feature request for discussion because this can be the case for many other modules that may provide a better integration with MySite.

One important aspect of this integration is that the other modules should ask whether the module is enabled or not, before adding the filter. Also, and this is strictly related to views, perhaps MySite could maintain the filter definitions by itself? That would be nicer, because other modules may not be willing to maintain that code in their codebase if the shared userbase with MySite is not large enough.

Thanks.

Comments

Comment #1

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 7 December 2007 at 22:09

Version:

5.x-2.15

» master

Will review the effects of adding this to the mysite module.

Comment #2

a_c_m CreditAttribution: a_c_m commented 18 December 2007 at 15:05

This is a nicer solution that the one i have used (having droplets pass the owner uid as an argument to droplet views). Looking forward to seeing it implemented.

Comment #3

a_c_m CreditAttribution: a_c_m commented 18 December 2007 at 17:14

Just implemented this, works like a charm!

Nicely done Mariano

Comment #4

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 18 December 2007 at 21:05

Nice. This will get into the 5.x.3 release.

Comment #5

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 5 January 2008 at 20:29

Status:

Active

» Needs review

To be clear, this is all that needs implementing, right:

/**
 * MySite Views support 
 * Code by mariano.barcia http://drupal.org/node/198904
 * Allow replacement of current group so we can cache these queries.
 */
function mysite_views_query_substitutions($view) {
  global $user;
  if (arg(0) == 'mysite' && is_numeric(arg(1))) {
    $uid = arg(1);
  }
  else {
     $uid = $user->uid;
  }
  $ret_array = array('***MYSITE_USER***' => $uid);
  return $ret_array;
}

/*
* Simple array for MySite user.
*/
function mysite_handler_filter_mysiteuser() {
  return array('***MYSITE_USER***' => t('MySite User'));
}

Comment #6

Owen Barton CreditAttribution: Owen Barton commented 7 January 2008 at 04:20

While I can see that there are some situations in which this could be useful, I actually much prefer the droplets passing the uid as an argument (I have a patch for this over at http://drupal.org/node/203009). The reason I prefer this is that it avoids duplication of views. When building big sites this is an issue, and it is much nicer to have N views, each taking a uid argument that can be used in lots of places than 2N (or 3 or 4N) views, each with a context specific uid filter. Not only is it more work to update these, but it adds work in managing all the different places they can appear.

Comment #7

a_c_m CreditAttribution: a_c_m commented 15 January 2008 at 18:24

Grunnog2, while i agree with you, OG is a special case (there may be others) as currently there is no way to get a listing of groups for a given UID, so this patch is needed for those situations.

Comment #8

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 15 January 2008 at 19:35

So how do I address both of these valid use-cases without causing a collision?

Comment #9

a_c_m CreditAttribution: a_c_m commented 15 January 2008 at 20:05

While Mariano's solution is very nice and offers better integration between modules, the UID as an argument for droplets has the more coverage without modification of other modules, only a few edge cases don't support it (OG being one). I've been using that method for several months now (i even forgot the official distribution didn't have it) and its very useful !

That said, why not offer both? They don't conflict?

Anyone know why OG doesn't allow filtering by UID argument in views?

Comment #10

Owen Barton CreditAttribution: Owen Barton commented 15 January 2008 at 20:38

That said, why not offer both? They don't conflict?

Yeah, I think that there is a place for both - it certainly wouldn't hurt (and filters are admittedly easier to grok for newbie-views-ers)

Anyone know why OG doesn't allow filtering by UID argument in views?

Ta da!
http://drupal.org/node/196488

Comment #11

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 16 January 2008 at 00:30

You'll have to pardon my Views ignorance a little here.

What I read above is that I can implement both patches (this and http://drupal.org/node/203009) without conflict?

Is that correct?

Comment #12

mariano.barcia CreditAttribution: mariano.barcia commented 17 January 2008 at 10:07

Hi everybody,

I haven't been checking this thread lately, now I'm catching up a little. Thanks drayen, you know, without knowing the internals of droplet.inc, I made this quick patch using my limited knowledge of views. I was not aware of the patch provided in http://drupal.org/node/203009, and I was looking for the same functionality provided by that patch.

Now, what I found interesting about Grugnog2's patch is that it provides a kind of "context" info to views by automatically passing the UID argument. It doesn't work for all cases (what if a view expects the first argument to be a month number? or OG) but it's close.

I think mysite introduces a new concept in navigation. Without mysite, you have the global $user variable that provides the context of the currently logged-in user. Now, with mysite, don't you think we need a $mysite_user variable or something that can be used by other modules?

Along the same lines of Grugnog2's patch, I can think of having the $user variable replaced by mysite user UID. Whoa. That would provide the ultimate context information, and it would work with OG and all other modules. But I'm sure it would also break a lot of things in Drupal. And that's because, while you would mostly need $mysite_user, there will be some times when you need $user.

I'm not sure we could escape from that fact, and that's related to what Grugnog2 has pointed out related to the duplication of views. Best approach to that would be: if you don't have a specific need of using the currently logged in user, build all views with the mysite-uid argument instead of current-uid argument. But that would need that many other modules modify their existing views integration.

I believe the two patches conform an interesting solution. Grugnog2's patch provides a seamless integration with most of the modules, and mimics the context information. The patch above offers integration with other modules to specifically implement the mysite-uid argument, like the special case with OG which have a set of views that doesn't fit the first UID.

Ken:
yes the patch is the first chunk of code. The second part is an example of a filter, that has security issues (it exposes posts from groups that may be private). But in order to have the list of subscribed groups of the mysite-uid you would have to add this one:

 'mysiteuidsimple' => array(
          'field' => 'uid',
          'name' => t('Og: Group in MySite User Subbed Groups'),
          'operator' => 'views_handler_operator_eqneq',
          'list' => 'og_handler_filter_mysiteuser',
          'list-type' => 'select',
          'help' => t('Groups are filtered to groups that current MySite user is a member of.'),
        ),

Comment #13

mariano.barcia CreditAttribution: mariano.barcia commented 17 January 2008 at 11:10

Ken,

Sorry, I think the patch needs some more love.

The base patch is the 1st chunk of code. That would go into a mysite_views.inc, as it is related to views integration.

However, the 2nd chunk of code is still needed to make things work with OG. I'm almost sure that, with some additions, we could provide the new filter declaration in the same mysite_views.inc file, so to avoid having to hack og_views.inc. But still didn't have time to test it...

Comment #14

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 17 January 2008 at 16:09

This is going to need some developer love other than mine to get committed.

Comment #15

bomarmonk CreditAttribution: bomarmonk commented 9 February 2008 at 00:36

What about the node access arbitration that is in Drupal 5's core? Couldn't a patch somehow allow MySite to work through access control so that MySite can show content based on permissions (edit, view, etc.), so that permissions granted through Organic Groups and other modules could determine what was shown on the MySite page? Or is this already implemented? I just don't know. I will download and play with this module! It sounds great, either way.