Drupal 7 port

Hey Berdir,

I agree with everything you wrote. I thought it might be helpful if I went through the list of sub-modules and prioritized our "Top 12." So here's my sense of the sub-modules that we should initially focus on (after completing the work that's already underway on Userpoints Role and Role Exempt). I've listed them below in order of importance (with the most important at the top):

1. User points Nodes and Comments (http://drupal.org/project/userpoints_nc): I agree about starting with this. It handles a lot of general use cases and is a primary way for users to "earn" points on a lot of sites. I created an issue for this here: http://drupal.org/node/871096

2. Userpoints Node Access (http://drupal.org/project/userpoints_nodeaccess): Using Userpoints to grant view access is another pretty general use case. It is a primary way for users to "spend" points on a lot of sites. I have a personal interest in this, too, as I will need this functionality soon. I created an issue for this here: http://drupal.org/node/871102

3. userpoints_autoapprove (auto approves outstanding transactions after a chosen period): Useful in that it provides a middle ground between the default "approved" and "moderated" approaches.

4. userpoints_no_negative (prevents transactions that would cause accounts to be negative): Negative points is a bit weird.

5. userpoints_revisions (earn points for creating node revisions): Useful for any type of wiki or workflow use case.

6. user2userpoints (allows users to send points to other users): Pretty cool feature for sites with a lot of users and a lot of points.

7. userpoints_invite (earn points when inviting others and when others register): There's a Drupal 7 port of the Invite module here: http://drupal.org/node/671818. Integration also important because User Relationships integrates with it (and we're working on the D7 port for that). And since this involves integration with another contrib module, I created an issue for this here: http://drupal.org/node/871114

8. userpoints_flag (integrates userpoints with Flag API): Flag is a very important module. There's a Drupal 7 branch of the Flag module here: http://drupal.org/node/794402. And since this involves integration with another contrib module, I created an issue for this here: http://drupal.org/node/871116

9. userpoints_email (Userpoints email notification): Basic notification system.

10. userpoints_admin_email (mails the admin when any user reached a defined points threshold): Useful if you want to use any type of "badge" system for points thresholds.

11. userpoints_pageviews (awards node owners points based on page views to their nodes): Interesting idea to incentivize fresh content.

12. userpoints_expire (Inactive users lose a certain number of points every certain period): Keeps users engaged.

So what do you think? If this seems like too much (given all of the other stuff we need to get done) we could always trim it down...

--Ben

Hmmm.... I can't get the patch in #3 to apply at all because I don't have any of the .info files for the sub-modules (except for the Role Exempt and Userpoints Rules modules that you already worked on).

I think this is because my current code is based on your github code and none of the .info files were present at github (due to the CVS to github issues).

How do you suggest we proceed? Would you like to create a 7.x-1.x-dev branch just so that I have something to base patches on? (I believe kbahey gave you commit rights.)

Or would you like to just post a tar or zip file of your entire userpoints_contrib module folder and I'll start from there?

Maybe there is a solution I'm not thinking of...

Thanks,
Ben

Berdir,

Thanks for the CVS how-to link. I got CVS installed, did a checkout, and the patch in #3 applied successfully with one exception: There was an error applying the patch to user2userpoints.info. All the other .info files were successfully patched, so I'm not sure why that particular one didn't work. So I just wanted to let you know.

In any event, I manually made the changes to user2userpoints.info (so that it can install) and will now begin testing the various sub-modules.

Thanks,
Ben

userpoints_no_negative

I started out by testing userpoints_no_negative. I've found a possible bug, but it depends on the intended logic of the module. Basically, the module seems to allow you to have negative points in any given points category so long as the cumulative points total of all categories is still positive. So it's possible to have three of four points category totals to be negative, which is probably against the intended purpose of this module for most use cases. I think most people probably would want no points categories to go negative, although this might not be universally true. It really depends on whether categories are intended to be entirely separate things or if they are merely different "tags" that are placed on essentially the same thing.

So as I see it, here are our options:

a) Update logic so that individual categories of points can't go negative.
b) Create a checkbox setting so that site admin can determine whether point categories can go negative or not.
c) Create a checkbox for each point category so that site admin can determine whether individual categories can go negative on a per category basis.
d) Keep it the way it is (but I think this is very confusing because it's permits a lot of negative numbers)

So what do you think? I like having the settings, but I'm not sure if that would involve a lot of extra coding to implement.

Also, one other fix related to the grammar of the printed message when point deductions are denied (because the points balance would be below zero). Currently, the message reads:

"User person1 losing 15 points skipped because it would move their points (further) negative"

To improve the grammar, I'd change the message to read:

"person1 cannot lose 15 points because it would cause a negative point total."

If we implemented the category non-negative logic described above, then the message could read:

"person1 cannot lose 15 points because it would cause a negative point total in the [Categoryname] category."

More sub-module testing to follow....

--Ben

Userpoints Role and Role Exempt

I did more testing of the bugs originally reported at the top of this issue thread (related to Userpoints Role and Role Exempt). Here are my findings:

A. Part of this is fixed, but one error message persists. Here's the error message I'm still getting:

Notice: Undefined variable: language in userpoints_role_send_mail() (line 287 of /Users/benkaplan/git/drupal/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_role/userpoints_role.module).

B. I agree we should postpone.
C. It turns out, this is not an issue with these sub-modules. So we don't need to fix on this thread.
D. Confirmed this is fixed. Thanks!
E. Here's how to reproduce this issue (role changes in custom categories don't work):

Step 1: Create a user called "person1"
Step 2: Create a role called "editor"
Step 3: Create a Userpoints category called "Goodwill"
Step 4: Under "Role Settings" for the Userpoints Role module, set the points needed for the "editor" role to "10" and the category to "Goodwill".
Step 5: Award 20 points in the "Goodwill" category to person1. person1 will not be granted the "editor" role (even though he should be according to the configured logic).

Note that if you change the category to "Uncategorized" under "Role Settings" and then grant person1 20 points in the "Uncategorized" category, person1 will be properly granted the "editor" role. So the problem seems to be related to changing roles in categories other than "Uncategorized" (like the custom "Goodwill" category in the above example).

Hope this makes sense... I get a little confused just writing it! ;-)

--Ben

Berdir,

RE: #7. OK, I see what you're saying. I don't want any specific sub-module to slow us down. Was just thinking that it could be a quick fix, but maybe it's more involved than I thought. So perhaps we should just postpone any logic changes for now and merely fix the message grammar bug that I mentioned.

I'll continue to mention logic/usability issues when I find them in sub-modules (so that we have a good record of all of these for future reference), but we can decide on a case-by-case basis whether to postpone or deal with them now (if they are important enough to basic functionality). Sound good?

--Ben

user2userpoints

Just finished testing user2userpoints. It's a pretty cool little module... very handy! The general functionality of the module is working well, but here are the bugs/issues I noticed:

A. In the settings (admin/config/people/userpoints/settings), the "Fieldset heading to use in the interface" isn't working. Regardless of what you type in this field, "Give !points" is what is used as the heading of the points giving interface. Also, I think this label should be changed to: "Headline to be displayed on the points gifting form".

B. Change the label that reads: 'Word to use in the interface "to" label !Points'. Change it to this: "Label to be displayed above the username field on the points gifting form".

C. Change the label that reads: 'Word to use in the interface "amount" label !Points'. Change it to this: "Label to be displayed above the "amount" field on the points gifting form"

D. The "Show category select input if categories enabled" checkbox does not seem to work. No category select field is showing up on the points gifting form even when it is checked.

E. Could we add a new field beneath the category checkbox that allows the site admin to select the default points category to be used when awarding the points? If the "show category" checkbox wasn't checked, then this default category would be used automatically and no option would be presented to the user. If the the "show category" checkbox was checked, then this default category would be the initial default in the select list.

F. The "Show 'Give Userpoints' links beneath nodes" checkbox is bit odd in its implementation. Basically, nodes of all content types except 'page' will have a 'Give points' link added to them. Could we move this to the content type edit page (like we did for Userpoints Node Access) and let the site admin specify which content types should display this link?

G. When the 'Give !points' link is being shown in the links section of node pages and teasers, it is being displayed as "Give !points". It's a little unclear that you're actually giving points to the node author. Just like Private Message's 'Send author a message' link, we should change this to: 'Give !points to author'

H. Can we open the "points gifting form" in an overlay if the user has permission to use the overlay?

I. If a user tries to gift more points than he has, here is the message that is displayed: 'You don't have enough !points for that.' I think we should also say how many points the user has in the category he is using. Change this to something like: 'You don't have enough !points available in the @category category to give away that many. You currently have @points !points available.'

J. On a user's page, "Give points" is hardcoded as the section head even when points branding is being used. We should use "Give !points" for the section head instead.

K. On a user's page, the "Give !points to [username]" link is working only in some instances. It's really weird... in some instances it will be a correct link to "user2userpoints/editor?destination=user/4". In other instances, it will link to "user/4" and nothing will happen (because we are already on that page). Sometimes just reloading the page will change where that link points to and it will suddenly work or not work. There must be some kind of conflict going on that causes that link to change on different page loads. Very strange.

L. We should hide the "Give !points to [username]" link on the user page if the currently logged in user is viewing his own user page. Otherwise, it's a little weird.

Well, that's it. I actually like this little module quite a lot! :-)

--Ben

user2userpoints continued....

I noticed one more issue with category handling in the user2userpoints sub-module:

M. Basically, to determine if you have enough points to make a points gift, it is looking at your overall points total. Yet, the points being deducted are from the Uncategorized category. So in my testing, I had a user giving points who had 20 points overall but -10 points in the Uncategorized category. When he went to make a two-point gift to another user, the gift transaction went through and his Uncategorized points went from -10 to -12. So we need to make sure that category handling doesn't allow users without points in the category to gift points that they don't have.

--Ben

I'm starting back up with this issue thread so that we can get a 7.x branch released in conjunction with the impending Drupal 7.0 release. So here is some more testing results...

userpoints_revision

I tried out the patch in #3 and I'm getting the following errors on the Userpoints settings page (admin/config/people/userpoints/settings):

A. At the top of the page I'm getting the following notice:

Notice: Trying to get property of non-object in userpoints_revision_userpoints() (line 89 of /Users/benkaplan/git/drupal-dev/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_revision/userpoints_revision.module).

B. In the "POINTS FOR CREATING NODE REVISIONS" settings area, the content type names are not being shown. This is probably related to the above notice. Basically, the field labels are being listed as "Kudos for creating a revision of a" (with the content type name missing). Because I have seven different content types on my dev site, I have 7 incomplete field labels. I also have seven instances of the notice shown in A.

C. The settings are using the old fieldset method instead of the new vertical tabs.

D. I'm wondering if we should move the per content type settings to the individual content type edit page (like we did for Userpoints Nodes and Comments) and just have global settings on this page.

E. Not sure about the "Award points for revisions by the node author" label. Shouldn't points be awarded even if someone other than the node author (who has permission) is making revisions? That is how it would be in my use case. I'm not sure if this setting is meant to enable functionality for the entire module or if it is meant to toggle whether the node author can receive points.

Once we get A and B fixed (so that I can set points per content type), I'll be able to do more testing. I'll likely be using this in production sometime soon.

--Ben

More notes...

userpoints_pageviews

This sub-module is already working pretty well. Here's what I noticed:

A. "Page limit" settings seems to work exactly the opposite as expected. Selecting "All" works like "One" is supposed to work and vice versa. More specifically, if you select "All", then only the first node view will result in a point award. If you select "One" then all node views result in points. So actually, the functionality is working, just exactly in reverse.

B. The operation listed in points transactions is "node view". This needs to be updated to our new machine name format.

C. The sub-module needs an automatically generated "Description" that would be listed in the "Reason" field. My suggestion for the format would be:

[username] viewed [nodetitle].

[username] would be the user who viewed the node, not the user (node author) who is receiving the points. In the "Reason" field, it is already linking to the node (which is great).

D. There should probably be a setting to optionally disable the drupal_set_message when points are awarded for a node view. Otherwise, the user viewing the page actually gets to see that the node author is getting points (even though they are not the points recipient).

E. The settings are using the old fieldset method instead of the new vertical tabs.

F. I'm also wondering if we should move the per content type settings (how many points are awarded) to the individual content type edit page (like we did for Userpoints Nodes and Comments) and just have global settings on this page.

--Ben

Hey Berdir and all,

I thought it would be helpful if I summarized where things stand with the various sub-modules we've been working on. So here is the latest status report...

1. Userpoints Role

Status: Initial port completed. To do: See comment #8.

2. Role Exempt

Status: Initial port completed. To do: See comment #8.

3. userpoints_autoapprove

Status: Not yet ported.

4. userpoints_revision

Status: Initial port completed. To do: See comment #14.

5. user2userpoints

Status: Initial port completed. To do: See comments #12 and #13. We also need to update this so that it places the "Donate !points to [username]" link in the links area of the new Userpoints field group on the user account page. Also, so that this works properly with the Realname module, we may need to look at a solution for this issue thread: http://drupal.org/node/976032

6. userpoints_pageviews

Status: Initial port completed. To do: See comment #15.

7. userpoints_flag (Integrated with Flag module)

Status: Initial port submitted at http://drupal.org/node/871116

8. userpoints_invite (integrates with Invite module)

Status: Port not begun yet at http://drupal.org/node/871114

9. userpoints_bulkpointsawards

Status: New contibuted module idea as discussed in IRC. Basically, a way to add/deduct points to an entire role (or multiple users) at once.

TO BE DEPRECATED (because functionality can be accomplished using UP Rules integration):

Here is my recommendation on modules to deprecate...

A. userpoints_no_negative
B. userpoints_email (Userpoints email notification)
C. userpoints_admin_email (mails the admin)
D. userpoints_expire

--Ben

@Berdir: As you suggested, I've created separate issues to include userpoints_revision and userpoints_pageviews as part of the Userpoints Node and Comments module. The issues (one for each sub-module) are located here:

http://drupal.org/node/993830

http://drupal.org/node/993844

--Ben

I tested the latest userpoints_role patch. The basic functionality is working pretty well. Here's my to-do list:

1. When doing a points award that results in a role change, I'm getting the following notice:

Notice: Undefined variable: cat_points in _userpoints_role_update_roles() (line 228 of /Users/benkaplan/git/drupal-7.0/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_role/userpoints_role.module).

Note that the role change is successful and the e-mail is being sent.

2. In the "Roles" vertical tab, I think it might be better if we made sub-vertical tabs for each role. What do you think? If there was an "editor" role, We'd make an "Editor" vertical tab as a subset of the "Roles" tab. The points and category setting for that role would go in this sub-tab. In the current layout, if you have a bunch of roles it gets very confusing.

3. Instead of having a separate "Roles email settings" vertical tab, is it possible to put this setting within the "Roles" vertical tab? Most other up-related modules just have one tab. Ideally, it would be great to have the e-mail message text as part of the sub-tab for each role. This way, you could also specify a different e-mail message depending on the role (which would be very useful). And should we change the name of the "Roles" vertical tab to either "Role changes" or "Adding and removing roles"?

4. I'd like to suggest two simple checkbox options that aren't currently part of the module.

a) A checkbox labeled "Send e-mail upon joining a role".
b) A checkbox labeled "Send e-mail upon leaving a role".

This way, you can disable the sent e-mail for each situation if you are notifying users via another method (such as a Private Message). Ideally, this would be a per-role setting.

5. Is !category a token that can be included in e-mails? It's not in the current default messages but seems like we'd want it available.

6. On occasion, I'm still getting this error when saving nodes on the site:

Notice: Undefined variable: language in userpoints_role_send_mail() (line 287 of /Users/benkaplan/git/drupal-7.0/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_role/userpoints_role.module).

--Ben

Thanks for porting userpoints_autoapprove. The basic functionality is working very well and this little module will be a nice addition. Only three things:

1. After enabling the module, I'm getting the following notice on every page:

Notice: Undefined variable: output in userpoints_autoapprove_help() (line 15 of /Users/benkaplan/git/drupal-7.0/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_autoapprove/userpoints_autoapprove.module).

2. On the Userpoints settings page, the config options are appearing in an old-style fieldset instead of a new-style vertical tab.

3. For the actual label on the setting, change it to: "Time until automatic approval". Then, add a description that reads: "Specify the time duration (in hours) that must elapse before the !points transaction is automatically approved. Entering a negative number will disable auto-approval."

--Ben

Just tested userpoints_role_exempt (using the patch in #3). Everything is working perfectly. So I only have one small change:

1. Change the old-style settings fieldset to a new-style vertical tab.

--Ben

Note that for the user2userpoints module, we still need to make the changes described in comments #12 and #13 (A to M). In addition, to those comments, I'm hoping we can also make the following small changes:

N. On the settings page, we need to move the old-style fieldset into a new-style vertical tab.

O. When viewing another user's account page, the "Give points to BenK" is linking to two different places. The "Give points to" is linking to the proper points gifting page (which is good). But the username is linking to the user's account page (which is the page you're already on). It would be better if the entire text linked to the points gifting page.

P. We need to place the "Give !points to [username]" link in the links area of the new Userpoints field group on the user account page. It would appear beneath the "View points! transactions" and "Add or deduct !points links".

Q. So that this works properly with the Realname module, the "Give !points" form should use a user's realname (if available) instead of a hard-coded username in the autocomplete field. There is a possible patch for this here: http://drupal.org/node/976032

R. We need to update the operation field for user2userpoints transactions. Currently, the operation being used is "From: [username]" (when receiving points) and "To: [username]" (when giving points). So instead, we need to use our new machine name operation style. Additionally, we need an auto-generated transaction description and link the 'Reason' field to the points giver/recipient (so that the "Linked entity" on the transaction displays as type "user" and the user's ID). My suggestions for the auto-generated descriptions are:

a) Giving: "Gave !points to [realname/username]."
b) Receiving: "Received !points from [realname/username]."

Note that in the above description we should display the user's realname, if available.

S. Can we add an optional text field (perhaps labeled "Reason") to the "Give !points" form. This would give a place for the user who is giving to write a note saying why they are giving the points. Then, this field could be used to populate the "Description (manually entered)" field on the points transaction (so long as the field is sanitized first since it's user inputted data). This would be a really nice feature (I plan on using it myself) and works perfectly with how our "Reason" displays on the points transaction list.

T. On the "Give !points" form we might want to add some description/help text that reads: "When you give !points to another user, the corresponding number of !points will be deducted from your !points balance."

--Ben

One more thing: After we implement the above fixes to userpoints_role, userpoints_autoapprove, userpoints_role_exempt, and user2userpoints, then I think that we're ready to open the official 7.x branch! :-)

--Ben

P.S. We can then work on userpoints_flag and userpoints_invite. Those integration sub-modules have their own separate issue threads anyway.

Okay, thanks. I agree with everything you said (in regard to what is before commit and what is separate feature). I'll test everything you've done, but one update on #20.6:

Notice: Undefined variable: language in userpoints_role_send_mail() (line 287 of /Users/benkaplan/git/drupal-7.0/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_role/userpoints_role.module).

This notice is happening every time points are awarded on the site. I just have points set to be awarded when new nodes are created... that's why I thought it was happening on node creation.

--Ben

Further update on #20.6... I've determined that the notice only occurs when points are being awarded via Rules. So maybe the problem is the Rules implementation not passing the language?

Also, when awarding points via Rules, I'm getting the following error message related to the Masquerade module:

Notice: Undefined index: masquerade_users in masquerade_user_update() (line 432 of /Users/benkaplan/git/drupal-7.0/sites/all/modules/masquerade/masquerade.module).

I don't have any other Masquerade problems except for that (it's been very stable). So maybe the problem is with the userpoints rules implementation?

I tested the latest userpoints_role patch and #1 now seems fixed. Most of the other items I previously reported can be changed to feature requests once we have an official 7.x branch. However, I'm now experiencing some additional issues:

1. Upon enabling the Userpoints Role module (or clearing the cache), I'm getting the following notice:

Notice: Use of undefined constant USERPOINTS_PERM_ADMIN - assumed 'USERPOINTS_PERM_ADMIN' in userpoints_role_menu() (line 43 of /Users/benkaplan/git/drupal-7.0/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_role/userpoints_role.module).

2. I have rule set up to award userpoints to the node author when new content is created. This works fine if the Userpoints Role module is not enabled. But once I enable this module, I am unable to create the new content and the following error appears in my PHP logs:

PHP Fatal error: Call to undefined function db_result() in /Users/benkaplan/git/drupal-7.0/sites/all/modules/userpoints_contrib-DRUPAL-6--1/userpoints_role/userpoints_role.module on line 248

3. I'm now getting the following error every time I award points:

Warning: array_flip() [function.array-flip]: Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of /Users/benkaplan/git/drupal-7.0/includes/entity.inc).

Not sure if this is even related to this module, but all of a sudden it started showing up everywhere.

4. The !Points for Roles fieldset is not appearing in the new style vertical tabs. And maybe we should change the vertical tab title to "Role changes".

--Ben

Just tested the latest version of userpoints_autoapprove. Looks good everything previously reported looks fixed.

Just one possible string suggestion for the vertical tab title: Instead of "Autoapprove", how about: "Automatic approval"?

And maybe I'd set the weight of this module and all of the other UP-contrib modules to appear below up-nc and up-nodeaccess in the vertical tabs.

--Ben

I tested the latest userpoints_role_exempt patch and there's nothing left to be done. The new vertical tab looks good! :-)

Just tested user2userpoints. You did a lot of great work on this. Here are my notes:

D. The category field is now showing up on the points giving form. But there's a new problem: If you have the "Show category select input if categories enabled" option unchecked, then the points donation does not get submitted and the form merely re-displays.

E. The default category selection field looks great. Only one issue: If the "show category" option was enabled, then "General" is always showing up as the default category on the donation form instead of the default category selected here.

G. The "Give !points to author" link is displaying with inverse logic. Basically, the link is only being shown to the current user if the current user authored the node. Instead, it should be exactly the opposite: The link should display if the current user didn't author the node.

N. Should we re-name the global settings vertical tab. Maybe use "Donation" or "User donation" or "Donate to others"?

O. I think just using "Give !points" is a little unclear. Even though it's on a user's page, it sounds like a general concept rather than something specific for this user. So if we don't want to use the username, how about "Give !points to this user"? Actually, we previously discussed in IRC using "donate" type language instead of "give" because it was more clear (for an admin who is awarding points "give points" sounds like using the add points form when it's not). So how about:

"Donate !points to this user"

We'd also need to change "give" to "donate" in the form header and description, too.

Q. I think you may have misunderstood what I meant here. I'm talking about using the "Realname" in the "To" autocomplete field on the donation/give form. The current problem is that if you are using Realname everywhere else, it's weird to suddenly see a username you're probably not familiar with when giving points. A user might think he's not giving to the person he intended. Wouldn't this just be the display of the realname in the autocomplete? To actually give the points, is the module using the uid anyway?

R. The operation has been successfully updated, but we still don't have an auto-generated reason. I think I'm OK with putting the word "!points" in this auto-generated description because it's a different case than all of our other modules. In the case of other modules, we're always awarding points for some other activity, but in this case, we're not awarding points for making or receiving a "donation"... the points donation is the actual activity that is occurring. So if we just just used "Received donation from BenK" as the auto-generated description, it sounds like you're getting points for receiving a donation (not that the points are the actual donation). So here are some options for the auto-generated description:

Received:

Received !points from [username/realname].
Received !points donation from [username/realname].
Received !points gift from [username/realname].

Gave:

Donated !points to [username/realname].
Gave !points to [username/realname].

If you have better suggestions, let me know.

S. The implementation of this is really cool. It really fits our concept of "donation". Just one more little tweak: After testing this, I realized that unless the user actually puts his/her own name in the reason, it is very unclear who the points donation is actually from. So before we pass the user-written reason to the main userpoints module, could we also add some clarifying text to the beginning of it? I'm thinking we could just use same text as the auto-generated description followed by colon, then the reason submitted by the user in quotes. It would appear like this:

Received !points from [username/realname]: "[Manual reason]"

So as an example:

Received !points from [username/realname]: "I really appreciated that helpful comment you made in the issue queue and wanted to give you some points. Enjoy!"

One other option would be to just do this:

From [username/realname]: "[Manual reason]"

So that it would read like this:

From BenK: "Thanks for the great patch that you posted yesterday!"

What do you think? I think I like the first example better because it is more clear that it is a points donation and not just a message.

T. I didn't realize my text would run over to two lines. Here's a shortened version: "When you donate !points to another user, they will be deducted from your !points balance."

U. (NEW) On the donation form, the "Type" field should be labeled "Category" (since that is how it is referred to everywhere else).

V. (NEW). A typo in this string: "Provide a reason that will be shown to the user recieving the points. This is optional." "recieving" should be spelled "receiving". Also, the word "points" is hard-coded. So maybe I would re-write this as:

"You may include a short message that explains why you are donating !points. This message is optional and will be shown to the user receiving the !points."

--Ben

Sounds good!

I did a final review of the 7.x-1.x git branch and things are looking really, really good. Here are my last few things:

1) "Automatical approval" vertical tab should be "Automatic approval". I don't think "Automatical" is a word. ;-)

2) For the "Roles changes" vertical tab, I think it sounds a little better as "Role changes" (singular)

3) For the "Role changes" tab, how about we put the settings for each role in a fieldset for that role (i.e. "Editor role settings"? I believe this was the best practice suggested at the DrupalCon Chicago UI session. Then, we could put the e-mail settings for that role change also in that fieldset (without having to go to a separate page.

4) I don't think we need "Roles email settings" as a separate vertical tab. It's a little confusing because it almost looks like a separate module. How about include that as a "Default e-mail settings" fieldset that is part of the "Role changes" tab?

A few small User2Userpoints fixes:

5) "Donate points" is hard-coded as the title of the donate points form. Instead, the word "points" should be "!points" so that the proper branding is reflected.

6) The "Give !Points" submit button should only have an initial capital on "Give". Also, we've changed "Give" to "Donate" elsewhere. So perhaps this button should be "Give !points".

7) In the help text under the reason field, the points branding is not being substituted. The word "!points" (with the exclamation mark) is actually being printed. And since it's going to two lines, here is a shorter version that should fit on one line: "You may include a short message that explains why you are donating !points. This message will be shown to the !points recipient."

8) The auto-generated description for donating points currently reads: "Gave !points to [user]". For consistency, we should probably change this to: "Donated !points to [user]"

9) Yeah, I like your idea about integrating how many points you have per category. I like doing that directly in the category select as you suggest. If the category option is unselected, how about a simple text link ("View your !points balance") that is directly after the description text at the top and links to myuserpoints/%uid/%tid for the default selected category?

10) I agree that we should rename the module as userpoints_donation

That's all I've got... perhaps make the above changes, close this issue, and move-on to follow up issues (with a new -dev version)?

--Ben