All roles are granted when a user earns points

Oh, I set in userpoints taxonomy new category: Karma.

In Userpoints Role I set -10 Karma points for role Flooder.

But when user reaches -10 points nothing happens. Absolutely nothing.

@mxistence, could you provide a patch?

In my view Userpoints role should not mess with the uid=0 account. You can still have administrators and administrator roles with other uids, but in my view the first administrator should be rather seen as a system account, then an account for everydays administration work. So I would not like other modules to mess with this accounts permissions

When I try to use User Points Role, every time a user earns some points they get an email congratulating them on joining a new role -- even if they are already in that role or haven't earned enough points to get the promotion. I've had to turn off the module, which is pretty disappointing.

My case is that the email sent doesn't have the message...it only says "Array" and a bad message like: "This message was sent from [site name] ([site url]). If you believe this message to be a case of abuse, please contact [site email]"

and i have already set a message on the config page...

how can I set it up?

Sorry

this email issue has nothing to do with User Points modules...

I have exact same problem as described by "dRaz" in the very opening post. Has anyone find the solution yet? Please help. Thanks.

I have the same problem as the opening post described by dRaz, and #8 by ranavaibhav.
I have several roles. I want users that have 3 points of taxonomy ABC to gain another role.
When users gain just 1 point, they are upgraded!
Hope someone can help us out!
Rosamunda

the exact same problem occurs in the 7.x branch as well.

i have 9 different roles. a user logs in and gets a point for a login, and then gets added to all of the roles available. its like the basic mathematic test is totally wrong in this software. a user with 150 points should never be assigned the role that requires over 7000 points.

i think i`m going to have to permanently disable this module which is very disappointing. theres been next to no support for this issue which I would consider to be a terminal bug.

Ok, the attached patch fixes the problem in the 7.x-1.x branch. The problem was simply that the check was the wrong way round, probably due to a copy and paste error from the role removal code.

Note that the 6.x-1.x branch of userpoints_role is broken beyond repair, the only advice I can give is to not use it.

Thanks a ton Berdir

Although I must profess my ignorance in that I dont know how to apply this patch or to which file.

I'll do some digging around and try to get it figured out.

Removed a debug() call, more tests.

See http://drupal.org/patch for more information on patches.

yeah I popped through there but being on win64 its difficult to figure out how to get them applied. I'm bashing away at it though

Try http://drupal.org/node/620014 then

thanks I'm reviewing that right now and I'll try it. I'd love to get this thing working

i am gettting errors that it can't fine the file to patch at input line 5.

I have tried running patch through cygwin both from inside the folder userpoints_contrib as well as right inside the userpoints_contrib/userpoints_role/

when I specify the file to patch directly on the .info file I get hunk 1 failed at 3, 1 out of 1 hunk failed
when I specify the file to patch direcly on the module file it does not return any errors

I have only done a dry run as per the link that you sent me so in theory no changes have been applied

Could the not finding file problem be related that you have a a/userpoints_role and b/userpoints_role specified in the .patch file, perhaps you are using an in and out folder?

sorry if some of this is not related to userpoints_contrib and is really just cygwin support. i'm a quick learner as my CLI experience dates back to CP/M, Amiga and AREXX as well as of course various versions of DOS in the 80s so a little help will go a long way. :-)

EdIT::

Ok I created an a and a b directory and put copies of the userpoints_role in each.

Again on a dry run only I get this:

// the first patch "fix_and_tests.patch"
patching file a/userpoints_role/userpoints_role.info
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file a/userpoints_role/userpoints_role.info.rej
patching file a/userpoints_role/userpoints_role.module
patching file b/userpoints_role/userpoints_role.test

//the second patch "more_tests_debug_removed.patch"
$ patch -p0 --dry-run < more_tests_debug_removed.patch
patching file a/userpoints_role/userpoints_role.info
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file a/userpoints_role/userpoints_role.info.rej
patching file a/userpoints_role/userpoints_role.module
patching file b/userpoints_role/userpoints_role.test

ok so I tried just upping the patched module (the module patch itself did not give errors, so I figured I'd just give it a whack, the .info seems to just be revision and timestamp info)

I did one patch then the other in the order you provided them as above

a) The testing information is available for all users. I created a testuser and upon receiving a point I got a long debug info on a brand new user. The user received a single point for login that should have placed them into the first category (recruit in my case, 1-250 points)

b) Another user logged in during my short testing run. As you had previously said, it was applying the roles in reverse. He was granted all roles with exception of the one which he qualified for, I hit a manual cron run and it showed all of the code in the debug display. I went into his user account and he was applied all roles with the exception of MCpl which is what point range he was at. I manually fixed it.

--

Perhaps I didnt do the patch correctly somehow? I have again temporarily disabled the module and have restored it to it's original state. The version I am trying to patch is the 7.x-1.x-dev release right off the project page. It definitely modified the .module code as I saw the debug info displayed. Should I be only applying the second patch or something?

OK. (Sorry everyone for all these play by play updates)

I started over and only applied the second patch. The .info still failed with the above hunk error. The .module applied fine. I dropped only the .module file over to the site and tested it out and it seems to be working with no debug information being displayed to anyone.

It seems to be working! I will continue to test it out and see how it goes with my users as they gain and lose points.

Thank god for you Berdir. Provided this puppy is working I'll be firing you some beer or play money via Paypal before the week starts as promised. (about $46 CDN). Not a lot but thank you so much for expiditing this issue.

ok so it seems to be applying the correct mathematics

but it is still applying all roles up to the role that the user is supposed to have obtained, and not removing the roles that the user obtained prior.

I'm not sure if this is a bug or an intended feature. In my system, if I gain a point, and I am already at the rank of Captain, it then applies all the roles from Recruit thru Leuitenant to my account and sends out a variety of e-mails congratulating me on reaching each role.

Oddly enough it does miss some of the e-mails though. It sends mail for Recruit, then skips Corporal, sends mail for Master Corporal, skips Sergeant, sends mail for Staff Sergeant, and then Leuitenant. It does apply all of the roles though.

Is the module supposed to remove previous roles? Or is that known?

Yes, the .info changes fail to apply because I'm working with the git checkout, while you're using the -dev snapshot. The build script adds additional information to the .info file, so it's different and the patch doesn't apply.

As you assumed, you can ignore the changes in that file, they only tell Drupal that there is a new file that has test classes in it.

Yes, it currently grants you all roles. I think this makes sense as roles are usually just a thing that has specific permissions assigned to it and Drupal treats each role differently so we can't just remove previous roles. Sure, it would be a useful feature, but it needs to be configurable, feel free to open another issue about that.

You might also want to have a look at the User badges project, which I think can be configured to work like you'd expect it to. However, the current 7.x-1.x is quite broken right now and the userpoints integration isn't fully done yet.

Not sure about the mail thing...

on the removing roles: rats. I was hoping it would only assign one role at a time. however I guess I can try to find a workaround

Commited and pushed to 7.x-1.x

Please open a new issue if you can reproduce the problem with the sent mails.