D 6.8
User Points 6.x-1.0
User Point Contributed Modules 6.x-1.x-dev (2009-Jan-13)

Logged in as user/1. At "admin/user/userpoints" i clicked on "details" for one of those userpoint entries. But ended at /myuserpoints/{number} and drupal say "Access denied"...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jredding’s picture

Status: Active » Postponed (maintainer needs more info)

I tested against dev and couldn't duplicate this issue.

Can you please test this again with
(1) disabling all contrib modules
(2) with the latest 6 dev version.

Thanks

CKIDOW’s picture

Version: 6.x-1.x-dev » 6.x-1.0
Status: Fixed » Postponed (maintainer needs more info)

That's interesting... I wanted to check this issue with current activated modules a few seconds ago. I already updated all modules to latest version and Drupal 6.9. There is no bug at the moment. Don't have time to check with the versions I mentioned above.

fred0’s picture

I've seen this too. It occurs when a user has no points transactions in the database. To be clear, a user can have zero points if they've received and then lost the points to total to zero. That is 2 transactions and they show in the /myuserpoints page. A user who has never received any points has no transactions and gets the access denied page instead. I would agree that this should be marked as a bug since an access denied page is confusing to a user.

jredding’s picture

great thanks you guy. I couldn't replicate so now that I have more information I'll try to duplicate and then fix this as soon as I can. I'm traveling today so I expect at least >12 hours.

jredding’s picture

I just tested this again. As user 1 and as a test user I was able to view the account details even if the account had 0 points (but transactions)
My tests were
2 users

Login as User 1
Grant 10 points to testuser
Grant -10 points to testuser
try to view account details at /myuserpoints/2 <--test user id
click on user's account /user/2 then click view
click on "Users by points" then click user's account then view next to points
Everything worked fine

Login as testuser
visit account click view
click on Users by points then details next to account.
These all passed.

So far I can't duplicate this error.

If you are still experiencing this error please try to document everything that is happening. You could try using something like Jing to screencast how to duplicate this error.

I'm trying here.

(I tested this on stable and dev)

jredding’s picture

OK now I'm closer to duplicating this error. This is what I have.

If I am user with 0 points and I navigate to /myuserpoints/3 then I get an "Access denied" message.
This is actually by design because that page doesn't exist (yet) moreover there are no links anywhere to this page.

Now I did find a "bug" but its not an "Access denied" error.
How to recreate
1) Create at least 2 additional users. we'll call them userpoints_admin and testuser
Grant userpoints_admin the permissions "administer userpoints" "view userpoints" "view user profiles"
2) Log in as userpoints_admin and navigate to /user/testuser (or the id of the testuser)
3) click "view" next to the 0 on the user account's page
--- a Page not found error will be returned.

tested again 6-x-dev.

jredding’s picture

OK based on what I saw before I "fixed" the issue. The issue was that the code was returning a page not found if the user in question did not have any transactions in the database. This "bug" arose from the new user permission "view own userpoints"; which elevated the former permission "view userpoints".

Its been fixed and committed to dev, give it some time and then check it out and comment.

shunshifu’s picture

I'm also having an access denied issue. It's on the top contributors page

http://www.breakpal.com/userpoints/list/all

I've went over and over my permissions and upgraded to dev and still have the problem..

Thanks

Phil

prosiktuno’s picture

I have a same problem.

jredding’s picture

Please do not change the topic of the issue.
If there is a bug or an issue with userpoints top contributor please report it on that module.

At this point I do not know if 4venture is having an issue with top contributors or with the userpoints module.

shunshifu’s picture

Sorry, my bad. I was thinking I was in the right module

prosiktuno’s picture

Sorry, I don't undestood at first time.
I can't see any userpoints before I added point to myself. After that everything is fine.
But I have question.
How I can remove my nickname from this list http://www.mysite.com/en/userpoints?
Is it possible?
Thanks.

ckng’s picture

Here is how to replicate the problem, in 6.x-1.0 & 6.x-1.x-dev also:

- admin (uid 1) & 1 user (eg. uid 3)
- add a point to the user
- goto auction/myuserpoints/3
as admin - access denied,
as the user - ok
- there is a link beside the username at admin/user/userpoints

fred0’s picture

To expand on ckng's steps, the specific issue is that any user who has no point activity in the database (not zero points as one could have activity that sums to zero) gets this error.
On my site, I had to manually add 1 point to my admin user (uid 1) and the other user who does some management so they both could access the general user's point info. The manual add was required since those users are exempt from earning points.

giggler’s picture

I have the same problem. If I'm the user, then I can see my own points. But as an admin role, I can click on "detail" next to each user's name, but access denied even though under points, it shows each users having 1 point.

I've just tried adding 1 point to admin role also and it still doesn't work. Under permissions setting everything that can possibly be checked are checked for the admin role.

kmillecam’s picture

I wasn't able to reproduce this problem /until/ in uninstalled userpoints (wiped the tables clean) and re-installed.

Now, as user 1, I can browse to a user's profile page and click the "view" link next to their userpoints but get an "Access Denied" message.

HTH,
Kevin

dragonwize’s picture

I too can confirm this issue. Here is my fix for it. When doing any special user access user 1 should always return true. I've also enabled it for those with points admin permission as well.

Replace userpoints_access_my_points() in userpoints.module with this:

function userpoints_access_my_points() {
  global $user;
  if ($user->uid === 1 || user_access('USERPOINTS_PERM_ADMIN')) {
    return TRUE;
  }
  return ( _userpoints_user_exists($user->uid) && 
    ((user_access(USERPOINTS_PERM_VIEW) && user_is_logged_in()) || user_access(USERPOINTS_PERM_VIEW_OWN)) );
}

The if conditional is all that is added.

ckng’s picture

Status: Postponed (maintainer needs more info) » Needs review

#17 patch is good to go.

altparty’s picture

#17 works for me too.

kbahey’s picture

Version: 6.x-1.0 » 6.x-1.x-dev
Status: Needs review » Needs work

Can we have a proper patch against -dev for this?

dragonwize’s picture

Status: Needs work » Needs review
FileSize
715 bytes
kbahey’s picture

Status: Needs review » Fixed

Committed.

Thank you.

Version: 6.x-1.0 » 6.x-1.x-dev
Status: Postponed (maintainer needs more info) » Closed (fixed)

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

yoeld’s picture

Version: 6.x-1.x-dev » 6.x-1.1
Status: Closed (fixed) » Active

Hello,

I would like to reopen this issue, since I have the same problem using the version 6.x-1.1 (2009-Oct-21). In that version, the patch of #17 is already integrated, but still I have the access denied error.

Thanks.

Holoduke’s picture

I experience the same problem.
Drupal 6.14
User Points 6.x-1.1

Holoduke’s picture

I am not familiar with patch, sorry. I re-wrote 2 lines at function:

function userpoints_list_my_userpoints() {
$overall_total = 0;
$unapproved_total = 0;
$approved_total = 0;

global $user;

// User which are displaying points for
$uid = (int)arg(1);
if ($uid) {
if ($uid != $user->uid && !user_access(USERPOINTS_PERM_ADMIN)) {
// If not the same as logged in user
drupal_access_denied();
return;
}
}
else {
// Default to currently logged in user
$uid = $user->uid;
}
$point_user = user_load(array('uid' => $uid));

// Check permissions
if(!user_access(USERPOINTS_PERM_VIEW)) {
// User has no access to view points
drupal_access_denied();
return;
}
elseif (!user_access(USERPOINTS_PERM_VIEW_OWN)) {
// User has no access to view own points
drupal_access_denied();
return;
}
... function continues....

The first change allow USERPOINTS_PERM_ADMIN to access althought they are not the requested user.
The second change allow USERPOINTS_PERM_VIEW override USERPOINTS_PERM_VIEW_OWN perm.

thanks for userpoints, these module is great!!

yoeld’s picture

Hello Jose,

Thanks alot. This has solved my problem!

Yoel

kurkuma’s picture

#26 works like a charm. Fixes the problem with access to other users points, even with user 1.
Thanks Holoduke.

kbahey’s picture

Status: Active » Needs review

So, what is the verdict here? Can we agree on one right way to fix this so I can commit it?

Docc’s picture

FileSize
1.31 KB

k got rid of the else statement and put it in a proper patch.

jeboy’s picture

In my case, a user can view his own points (details) but the administrator still cannot view userpoints of other users (/drupal/admin/user/userpoints) it says 'Access denied'

Liliplanet’s picture

Patch works great, thx!

Holoduke’s picture

What is the URL at nav. bar when you get 'Access denied'?
Have you modified the module code with lines detailed above?

If you don't know how perform changes, you may wait until next module release (I don't know if changes have been commited to module).

j_ten_man’s picture

Has it really taken a year to fix this issue? I found the bug in under 2 minutes. Patch #30 works great for me.

BenK’s picture

I'm also experiencing this problem and will test the patch in #30....

--Ben

domik’s picture

Hi,

How can i implement the patch ?? I have no idea where I have to paste the code in in userpoints.module

thx

mcurry’s picture

subscribe

benmmc’s picture

#30 works great. Thanks!

ManyNancy’s picture

Status: Needs review » Reviewed & tested by the community

Time to commit?

dawehner’s picture

Patch worked also fine for me.

nirad’s picture

The patch in #30 did not work for me. I am trying to access "/userpoints/list/period" with any authenticated user.

leprechau’s picture

#30 works great for me and is a very sane fix, I would like to also see uid1 have full access by default but that would make the if statements longer and less visually appealing. I for one am fine with making sure the 'administrator' role has the proper permissions checked. So here is my vote for committing #30 as is to the dev tree.

@nirad#41
you will have to grant anonymous user view points permission to do that...and the patch in #30 should work for you

jomorlo’s picture

#30 works for me!

mcurry’s picture

...I would like to also see uid1 have full access by default but that would make the if statements longer and less visually appealing. I for one am fine with making sure the 'administrator' role has the proper permissions checked. ...

I hope I didn't misunderstand that comment.

The admin user (UID 1) always has all privileges. There is never a need to do an explicit test for UID 1 to allow admin access. Calling user_access() always returns true for user id 1. Here's a snippet from the user_access() function:

// User #1 has all privileges:
  if ($account->uid == 1) {
    return TRUE;
  }

See: http://api.drupal.org/api/function/user_access

EDIT:
So, I think the main thing is to avoid using negative logic (!user_access(...)) to block user access. For example, in the patch above, the following logic should be used:

if ($uid == $user->uid || user_access(USERPOINTS_PERM_ADMIN)) {
  // ...
  // ... perform 'access allowed' actions
}
else {
   drupal_access_denied();
   return;
}

Holoduke’s picture

As this is the first time I proposed a module change i tried to modify as less as possible.
I agree with your perspective to avoid negative logic but it requires a bit harder changes.
I think this patch will fix the access problem for many people and this issue have been here stopped for many months. To much discussion for an small change. If anybody wants to recode the function will be great, the negative logic would be avoid. But if nobody propose a big patch i think would be good for userpoints comunity commit this changes and later study and discuss avoid negative logic and other improvements. While we are here writing, many people unknow how to hand made fix the problem and they are just awaiting the fix made at next release.

Please don't misunderstand me, i think you are right, i only try to explain we can commit and continue improving later. I just done this fix for me and i thought i must be shared with comunity, but I didn't expected 3 months later the patch is not commited yet.

sorry for my english.

kbahey’s picture

Version: 6.x-1.1 » 6.x-1.x-dev
Status: Reviewed & tested by the community » Fixed

Committed #30 to the -dev branch. It should be in the downloadable tarball in about 12 hours from now.

Thank you for those who contributed and tested.

bchristensen’s picture

Status: Fixed » Active

I wanted to reopen this issue because I found a problem with the code from #17 that isn't resolved in the latest dev download. I was able to access /myuserpoints and /myuserpoints/(uid of another user) when logged in as user 1 but still got access denied on both of those when logged in as a normal user with the USERPOINTS_PERM_ADMIN permission and no point activity. The single quotes around USERPOINTS_PERM_ADMIN need to be removed so that the code looks like

function userpoints_access_my_points() {
  global $user;
  if ($user->uid === 1 || user_access(USERPOINTS_PERM_ADMIN)) {
    return TRUE;
  }
  return ( _userpoints_user_exists($user->uid) &&
    ((user_access(USERPOINTS_PERM_VIEW) && user_is_logged_in()) || user_access(USERPOINTS_PERM_VIEW_OWN)) );
}

After removing the quotes I was able to access both /myuserpoints and /myuserpoints/(other user's uid) as a normal (not uid 1) user who had no point activity and administer userpoints permission.

JustMagicMaria’s picture

This is still not right. If a user has only pending points, they get access denied when trying to check their own points (even though they have PERM_VIEW_OWN). I took out the _userpoints_user_exists call which seems unnecessary and all is well.

robby.smith’s picture

subscribing

malclocke’s picture

Status: Active » Needs review
FileSize
675 bytes

#47 proves to be the final piece of the puzzle for me, constant name should not be quoted. Patch against 6.x-1.x-dev attached.

kbahey’s picture

Status: Needs review » Fixed

Thank you for the patch.

Committed.

Should be in the tarball in about 3 hours from now.

Status: Fixed » Closed (fixed)

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

enggpc’s picture

Ya, I've also find problem but finally i've found solution for that. The editing details are listed as:
file name: userpoints.module
path to file: C:\wamp\www\Your-drupal-project-name\sites\all\modules\userpoints

code at line 894: in function "userpoints_user()"
case 'view':
if (user_access(USERPOINTS_PERM_VIEW) || (user_access(USERPOINTS_PERM_VIEW_OWN) && $user->uid == $account->uid))
now change it to, at line 894
case 'view':
if (user_access(USERPOINTS_PERM_VIEW) || (user_access(USERPOINTS_PERM_VIEW_OWN) && $user->uid == $account->uid || $account->uid==1))

Here we will give admin, permission to view content means detailed information about userpoints.

code at line 1680: in function 'userpoints_list_my_userpoints()'
if($uid != $user->uid)
{
// If not the same as logged in user
drupal_access_denied();
return;
}
Now change it to, at line 1680:
if ($user->uid == 1)
{
}
else if($uid != $user->uid)
{
// If not the same as logged in user
drupal_access_denied();
return;
}

here $user is an object that contains some necessary details about currently logged in users. By default admin user get 'uid'= '1'. Check out this in database in table 'users' when you create and admin account. This id is only goes to superadmin not other created site admin..
If you want to show what kind of information $user object is contain.. type below code in this function at just below the line 'global $user;'
echo "

";
 print_r($user);
Now come at our point, the problem is condition is only about the currently logged in user. Means condition checking about the id passed through ulr and that is cached by $arg array "$uid = (int)arg(1);" like this. Our url will be when we click detail link on "users by points" is "http://site-name/myuserpoints/some_id(eg http://localhost/myuserpoints/3) is same with currently logged in user or not and this is wrong for admin also when admin wants to see detail about other user's userpoints access denied is displayed. So what i've done, i've put additional condition that check currently logged in user is whether admin or not. If it is admin then no condition is applied. So admin will see all detail information about other users. Ok I think this should be enough information and definitely you will get permanent solution to this problem. 
yaoweizhen’s picture

+1

Allow administror to access user's userpoints page.

halohaloplace’s picture

I dont know, I tried each suggestion to no avail. So frustrated!

halohaloplace’s picture

Addition -- the authenticated user can only view his own points when at the permission, view userpoints is also checked (with the view own userpoint also checked). But authenticated users are able to see other user's points, which I do not like. No patch I have applied has solved this yet -- where authenticated users are only able to see their own userpoints, and not the userpoints of other users.

matts777’s picture

Status: Needs work » Closed (fixed)

this tweak gets the "view own userpoints" permission, used by itself, to show ?q=myuserpoints properly

inside userpoints_list_my_userpoints....

// Check permissions
if($uid != $user->uid && !user_access(USERPOINTS_PERM_VIEW)) {

so the idea is you WANT this condition to fail if the $uid is not the current user

this would be in addition to the above in addition to the code in userpoints-362119-50.patch

i haven't checked this against all of the other use cases yet but i don't see any reason to enter the if block for !USERPOINTS_PERM_VIEW if the $uid and current user are the same because if they are it will be covered by checking for !USERPOINTS_PERM_VIEW_OWN

NOTE: this may make a complete "USERPOINTS_PERM_VIEW" permission dependent on USERPOINTS_PERM_VIEW_OWN in the case where $uid=$user->uid but shouldn't it be that way anyway? Should USERPOINTS_PERM_VIEW really be "USERPOINTS_PERM_VIEW_OTHERS"? I see some overlapping here.

ok, seriously sleepy time. i really hope i don't dream about this.

YK85’s picture

Status: Closed (fixed) » Needs work
meustrus’s picture

Status: Closed (fixed) » Needs work

OK, this is a big issue that seems to have a lot of things in it, many of which have been fixed. I just want to mention that on my site, with version 1.1, the "View Own Userpoints" permissions exists, but does nothing. Also, there should be a check on the profile page and in the navigation menu item for whether the user can access the page or not.

Berdir’s picture

Status: Needs work » Closed (fixed)

Version 1.1 is very old, try the 1.x-dev version.

I am also quite sure that #877446: perm:view userpoints, view link is displayed on other user's profiles and #611604: Access denied to my userpoints if user has no points fix the remaining permission/access issues in 6.x-1.x, please try out these patches before re-opening this one.

For example, the first issue removes the code that matts777 is talking about in #57 and instead fixes it in the access callback.

meustrus’s picture

1.1 is the latest stable release. I'm already playing fast and loose with enough modules, and it keeps me on my toes. I don't need another dev version to keep track of, I just want it to work. I've allowed everyone to see everyone's points to get rid of the error, and that's all the effort I want to put into it until there is another stable release.

And I would have said this sooner, but I always forget that "My Issues" doesn't display closed issues, meaning I never learn they have been closed. Not that saying so here will do anything about it.