Default views created by this module, signup_available_signups and signup_current_signups, enables any user (including anonymous user) to view signups of other users (even if the user does not have permission to view all signups). Just replace x with any user id in the following URLs, and you will be able to view their signups.

http://example.com/user/x/signups/
http://example.com/user/x/signups/current
http://example.com/user/x/signups/available

You could restrict the user by adding this code snippet to the argument validation of both signup_available_signups and signup_current_signups views.

<?php

global $user;
$self = ($argument == $user->uid) ? TRUE : FALSE;
$permitted = user_access('view all signups');

if ($permitted || $user->uid == 1) {
  return TRUE;
}
else if ($self) {
  return TRUE;
}
else {
  return FALSE;
}

?>

So what the code snippet above does is, it restrict users to view only their current/available signups. It will only allow an admin or users with "view all signups" permission to view other user's signups and/or all signups.

CommentFileSizeAuthor
#5 367297-5.signup_views_access_plugin.patch11.56 KBdww
#3 367297-3.signup_views_access_plugin.patch4.47 KBdww

Comments

zd370’s picture

zd370 commented

since user 1 will have all permissions by default no need to check for user 1... 

<?php

global $user;
$self = ($argument == $user->uid) ? TRUE : FALSE;
$permitted = user_access('view all signups');

if ($permitted || $self) {
  return TRUE;
}
else {
  return FALSE;
}

?>

remove <?php ?> from the snippet

dww’s picture

dww
we/he/they
commented
Version: 6.x-1.0-rc3 » 6.x-1.x-dev
Assigned: Unassigned » dww
Status: Needs review » Active

Argument validation is the wrong time to test for this, since at that point, returning FALSE results in a 404 (page not found), not a 403 (access denied). The best way to solve this problem is to define our own access plugin (something like "View per-user signup lists" in the UI), add an option to define which argument to use for the access check, etc. Then in the appropriate access methods, check this option, call the helper to grab the current (validated) value of that argument, and do our logic to decide if the given $account should have access to see the per-user issue queue for the given argument. I should hopefully be able to work on this sometime on Friday @ DCDC, if all goes well. See also #380734: project/issues/user a 404 when not logged in, which needs to be solved in almost exactly the same way.

dww’s picture

dww
we/he/they
commented
Status: Active » Needs work
StatusFileSize
new 367297-3.signup_views_access_plugin.patch4.47 KB

Ugh, this was a more complicated than I hoped, but I've basically got this working now. This patch adds a new views access plugin that has knowledge of the view arguments and enforces the logic that a user either needs the 'view all signups' permission, or to be trying to view a list of their own signups, to be granted access. I'm marking this "needs work" since this patch doesn't yet fix the default signup views to take advantage of the new plugin. Before I do that, I want to see if merlinofchaos is willing to try to generalize this as a feature for views itself.

zd370’s picture

zd370 commented

thanks dww for going to this extent for patching the issue...

dww’s picture

dww
we/he/they
commented
Status: Needs work » Needs review
StatusFileSize
new 367297-5.signup_views_access_plugin.patch11.56 KB

This fixes a few minor problems with the access plugin code, and updates the default views to use it. I also fixed the default views in a few related ways while I was at it:

- the argument now uses the user argument validator
- the argument handler now sets the page title based on the UID in the URL
- for the block display, the argument is overridden to use the UID from the currently logged in user as the default argument

Pretty sure this is now everything we need. Anyone care to test this? You'll need to apply the patch, clear your views cache, revert these views if you've customized them, and rebuild your menu.

zd370’s picture

zd370 commented

I will give it a try, as I am using your module on my site already.

dww’s picture

dww
we/he/they
commented

Minor wording change to the description on the argument selector in the access plugin itself. Otherwise, same code. I committed something similar for project_issue just now (#380734: project/issues/user a 404 when not logged in) so I'd like to get this in ASAP. Any testing results would be much appreciated. Thanks!

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

I tested this on two sites. One is of dubious history - a local install - and I got weird results.

The second is slightly more reliable and everything worked perfectly. So, I'd call this RTBC from a functional perspective.

zd370’s picture

zd370 commented

tested on my site... working...

dww’s picture

dww
we/he/they
commented
Status: Needs review » Postponed
Issue tags: +requires-views-6.x-2.4

Yeah, I'm just hesitant to commit this patch until views 6.x-2.4 is officially released, since people are going to be confused and things will be broken if they try running signup 6.x-1.0-rc4 and views 6.x-2.3... :( Otherwise, yes, I think this is RTBC.

zd370’s picture

zd370 commented

I am sure you know Views 2.4 came out a few days ago. I was wondering, if you are going to commit this patch.

dww’s picture

dww
we/he/they
commented
Status: Postponed » Needs review

Yes, I will, thanks for the reminder. More testing (especially for folks upgrading) would be welcome.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Fixed

Committed to HEAD and DRUPAL-6--1. I'm hoping to release RC4 in the very near future, which will include this fix.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

michellezeedru’s picture

michellezeedru commented

Sorry to comment on a closed issue, but I am using 6.x-1.0-rc4 and do not see this issue resolved. The "Signups" tab still appears to an anonymous user on all user profile pages, with access to a list of signups. I expected this to go away with the fix above. Am I missing a permissions setting somewhere? Are my expectations incorrect? Thanks for the help.

dww’s picture

dww
we/he/they
commented

You'll need to clear your views and menu caches after upgrading to RC4.

Also, make sure the anonymous role doesn't have the 'view all signups' permission.

michellezeedru’s picture

michellezeedru commented

Thanks for your response. I confirmed that I have flushed all caches, and "Administer All Signups" permission is not granted for Anonymous role. Anything else I can check?

crosendahl’s picture

crosendahl commented

The default for the View 'signup_current_signups' allows anyone to access the view, which is likely what you're seeing.

Edit the View and change Access from 'none' to 'View per-user signup lists'.

That solved the problem for me.

michellezeedru’s picture

michellezeedru commented

Thanks for the suggestion #18, but the access for that view was already set to View Sign Up User List. I tried playing with this, though, setting it by role, but didn't seem to make a difference.

michellezeedru’s picture

michellezeedru commented

How is "View per-user signup lists" as a views setting supposed to work. Should this option be listed on my permissions page? It's not.

BenK’s picture

BenK commented

Subscribing....

zdean’s picture

zdean commented

subscribing...