User Points

Version 6 Progress?

yellek — Tue, 28 Oct 2008 01:07:31 +0000

Is there an update on how version 6 of the userpoints module is coming along? I notice that the last commit to CVS was around October the 8th and I was wondering whether there was still active development going on.

User Points

Testing Userpoints for version 6

jredding — Tue, 07 Oct 2008 07:20:14 +0000

There are a lot of changes that we have in store for userpoints and we are planning to get them all in before we release an official stable 6 version of UP. I, however, got a nice whipping when I released version 5.3 and I do not want a repeat of that. 5.3 was released with several tiny, stupid bugs that could have been easily avoided if I had the time to test the module properly. Unfortunately I nor anyone else had this time. Fortunately we have a new weapon. Simpletest.

I have already begun writing several tests of Userpoints and I'll be checking them off this list as I complete them. I'd like to get all of these in before any major work to the API is performed as it is currently stable and I'd like to keep it that way. My lists of tests is below, please free to add to them and, better yet, write a test.

It looks daunting but many of these tests are only a few lines and a few of them are a single line.

API tests

Points
~~Call with only points are granted to logged in user~~
~~Call with points matches transaction table~~
~~Call with points matches transaction & updates summary table~~
~~Negative points caused summary table to decrease~~
~~Transaction table and cache table stays in sync through multiple point add/deletes~~
Points Array
~~Call with no points fails~~
~~Call with non numeric point values fail~~
~~Call with only points are granted to logged in user~~
~~Call with uid & points are granted to the appropriate user~~
~~Call with uid & points for a non-existent user fails~~
~~Call with a tid that is non-existent fails~~
~~Call with points & description, description is set correctly~~
~~Call with points & event, event is set correctly~~
~~Call with points & reference, reference is set correctly~~
~~Points in transaction table match points in summary table~~
All
~~Summary tables sums to non-moderated points in transaction table~~
userpoints_get_current_points
~~Called with no arguments returns current user~~
~~Called with uid returns points for default tid~~
userpoints_get_max_points
~~Called with no arguments returns current user~~
~~Returns same number as highest point level according to transaction table~~
userpoints_get_default_expiry_date
~~Returns a valid unix timestamp~~
Moderation
Call with invalid moderation status fails
Call with points & moderation and set to moderation correctly
Call with points & moderation does not modify summary table

UI and API tests

userpoints_get_default_expiry_date
Returns a valid unix timestamp
userpoints_get_categories
~~returns an array~~
userpoints_get_default_tid
returns a valid term id
userpoints_get_default_vid
returns a valid vocabulary id
Expiration
Points added with an invalid expirydate (non-timestamp) fails
Expirydate given via API matches transaction table
Points expire correctly (add points to expire in 1 sec. then call expiration
Correcting entry is added to transaction table & summary table is updated
Permissions
User without admin userpoints permissions can not modify points
User with admin userpoints permissions can modify points

User Points

Bounty: advanced FAPI | matslats.net

matslats — Fri, 18 Jul 2008 16:04:50 +0000

I'm building a community currency trading module and I've spent several days now wrestling with Form API in 6.x. I have no income from this but I need this form built for me, so I'm offering a bounty of $200.

My modules defines a node-type called transaction which consists of buyerID, sellerID, quantity, description of trade and other fields. Here is the user story I am trying to achieve.

User goes to the page of the person he wants to trade with, where there is a 'new transaction' block. This means the system already knows both uids.

User fills in the transaction details, which are quantity, description, and the direction of the trade. Presses submit.

User now sees a confirmation with buttons to confirm or go back. The system now knows which is the buyer and which the seller, ready to put those ids in the appropriate db fields. If the user is a buyer he get's an additional option to grade the transaction.

Now when the form is submitted it gets written to the database.

I'm sure it's not so hard. To have a look at the project so far, see http://bazaar.matslats.net

I'll give you my module so far, and be available to clarify while you work. There will be no feature creep, no theming, no documentation. Most of the code is already there, this just requires a better understanding of FAPI than I can muster.

Matthew

User Points

Userpoints - how custom it can be?

baskineli — Sat, 07 Jun 2008 19:27:51 +0000

Hello,

First of all, I'd like to say that I am a complete Drupal newbie. In fact, I don't have a single production site working yet, although I do have a couple test sites. My experience with PHP and mysql is rather limited.

I am looking to create a community website, where you can evaluate other people articles and contributions. Furthermore, each user has his own value, depending on how other users evaluate his own work.

For example, we have three users: John, Sandy and Sam, each has initial rating of 1. Sam publishes an article, and John gives it a rating of 3. Sams' rating goes up according to this formula: number of points he had plus (number of points he was granted multiplied by the number of points John had), meaning 1+3 multiplied by 1=4, so Sams' new rating is 4.
Now, Sandy publishes an article, and Sam is rating it as 5. Sandys' new rating will be 1 + 5 multiplied by 4 = 21 (5 for the rating, multiplied by the number of points Sam was worth).

The idea is to create a voting system where not all votes are equal, and you gain your worthiness according to how other people see your contribution.

My question is whether you think userpoints module can develop (or be developed) to the state where it provides the functionality I am looking for, without completely rewriting it. If the answer is yes, I will try to join the developers and add this functionality. If the answer is no, I guess I will try to think whether userpoints is the right module to do the job, and try to find another module. I do believe that userpoints might be what I am looking for.

Looking forward for the discussion,

Eli Baskin.

User Points

Userpoints Roadmap

jredding — Mon, 07 Apr 2008 20:18:52 +0000

A rework of userpoints has been on my mind for the past several months but to be honest i've never had the time to put into it. Now with recent activity surrounding userpoints (morbus' post, a certain unnamed "fork" of the code) I forced myself to find the time to put my ideas down onto paper so that we can all work together to create a nice roadmap/plan for userpoints. Userpoints has a nice strong community behind it and I don't want to see that change in any way.

I think we did a good thing when we separated out userpoints core from userpoints contributed modules. I think it really helped to drive home that those contributed modules were simply submitted by various users that never wanted to maintain them thus they were use at your own risk. Now that they are separate I think people understand what is a nice community supported package and what is use at your own risk.

So this is what I propose for the userpoints core project.

#1 I want to take the core API separation one step further and make it more like the voting API. A simplistic core module with a basic administrative settings page that provides a clean API and the necessary hooks.

#2 Core should ship with 4 modules
--a) Userpoints API, the main dependency
--b) Userpoints Administrative pages
--c) Userpoints views integration (because people like it)
--d) Userpoints xml_rpc integration (because its supported)
----this does mean that workflow_ng is moved out. I suggest this because we don't have any one actively supporting it. We only only keep items in "core" that have a high chance of being supported by us or the community.
----In all honestly I'd even support moving the views module out as it also isn't really that well supported and apparently has some bugs and inefficiency according to the issue queue.

#3 Userpoints Basic moved to a new project
-- I've always understood userpoints_basic to be an example module but people are expecting a lot more of it. I think we should take a queue from the voting API / five star project and branch this out. People are beginning to use userpoints for things other that granting points for nodes. I think its time we made a clear distinction between API, administration and granting points.

In order to move forward with the branch of userpoints core API and the creation of the new userpoints_administration I propose the following split of functions.

Core API module contains the following functions.
The core API modules controls no pages with the exception of a settings pages in which it contains the default category to use.
userpoints_perm()
userpoints_admin_settings()
userpoints_get_current_points($uid = NULL, $tid = NULL)
userpoints_get_max_points($uid = NULL, $tid = NULL)
userpoints_userpointsapi($params) <-- maybe a wrapper function to shorten name to userpoints_api?
_userpoints_transaction(&$params)
_userpoints_update_cache(&$params)
userpoints_get_default_expiry_date()
userpoints_user($op, &$edit, &$account, $category = '') <-- operates on delete
userpoints_filter_cat_select($form_state, $path, $tid)
userpoints_expiry_dates()
userpoints_date_to_timestamp($date)
userpoints_expire_transactions()
userpoints_cron()
userpoints_get_vid()
userpoints_get_categories()
userpoints_get_default_tid()
_userpoints_user_exists($uid, $tid = NULL)

Administrative module (functions renamed appropriately)
The administrative module allows control over moderation, displays points on the user profile page, lists userpoints, etc. etc.
userpoints_access_my_points()
userpoints_theme()
hooks userpoints_settings
userpoints_user($op, &$edit, &$account, $category = '') <-- operates on view
userpoints_admin_manage()
userpoints_admin_approve()
userpoints_confirm_approve_submit($form, &$form_state)
userpoints_admin_txn($form_state)
userpoints_admin_txn_submit($form, &$form_state)
userpoints_admin_points()
userpoints_list_users()
theme_userpoints_list_users($header, &$rows, &$tid, &$pager_limit)
theme_userpoints_list_users_header()
theme_userpoints_list_users_row(&$row)
userpoints_block($op = 'list', $delta = 0, $edit = array())
userpoints_my_userpoints()
theme_userpoints_my_userpoints($args, $header, $rows)

I also propose the following additions to the permission sets of userpoints.
-Administer userpoints (settings, etc., also grants moderation ability)
-Moderate userpoints (only moderate points)
-View all userpoints
-View own userpoints

These have been heavily requested and would be simple enough to put in. I'm willing to put the time into doing this piece.

The last major change that I'd like to see if the change of the moderation form into an actual form as opposed to its current state as a table.

Finally we can address some nitpicky concerns with a simple find a replace.

The official single word name of the module is userpoints all lower case
We can change the admin permission to the full word "administer userpoints" (although they would be the above)

User Points

Ideas for User Points Moderation Page

kmillecam — Wed, 27 Feb 2008 01:53:18 +0000

Jredding and I have been discussing the User Points moderation page (see attached) in the issue queue and we decided to bring the discussion out here to see if anyone has any fresh, new suggestions.

With User Points 5.x-3.x the moderation table changed a bit. The changes were good and logical but in some cases made my job as moderator a bit more difficult (IMO).

With past versions, the "Operation" column listed the node type (page, story, poll) that the points were a result of. This helped me (as a moderator) make decisions about approving, declining (or adjusting) points. With the new version, the heading "Operation" truly fits the contents of the cells as they now read "insert" or "admin" or a similar named operation. I've found these labels less helpful in my day-to-day moderation chores.

In an effort to improve the table to help moderators... well... moderate, jredding has suggested hyperlinking the operative term (insert) to the node that triggered the earnings. I like that idea.

What do the rest of you think?

Another thing that (again, IMO) would make moderation easier would be a default sort based on timestamp. This would show the newest transactions at the top of the list and the oldest at the bottom of the list. This would be similar to the behavior you see when you view a node list at /admin/content/node

Does anyone have any feelings about sort order of this table?

Any other suggestions that would make your life, as a User Points administrator, easier?

Thanks (in advance) for taking the time to share your feelings.

Kevin

User Points

User Points at DrupalCon

jredding — Sat, 23 Feb 2008 17:31:53 +0000

Although I can't find it at the moment the User Points session that Kbahey proposed for DrupalCon was accepted as a Birds of a Feather session.

So what do we want to talk about?
Start throwing out some ideas.
D6 upgrade?
Modifying the administrative section?
New tables, formats?
User Contributed modules..

User Points