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)
Comments
I have mixed feelings about
I have mixed feelings about the removal of workflow_ng support. I can understand why some people like it (even though your point about support is well-taken) and don't want to have to worry about coding a custom module. On the other hand, it really is duplicated functionality since hook_userpoints with a 'points after' operation takes care of the same functionality.
Workflow-ng simply gives the flexibility to non-coders to chain actions to the userpoints event, and it would be nice to continue that support. What would need to happen for you to reconsider dropping that?
I have mixed feelings about
I have mixed feelings about the removal of workflow_ng support. I can understand why some people like it (even though your point about support is well-taken) and don't want to have to worry about coding a custom module. On the other hand, it really is duplicated functionality since hook_userpoints with a 'points after' operation takes care of the same functionality.
Workflow-ng simply gives the flexibility to non-coders to chain actions to the userpoints event, and it would be nice to continue that support. What would need to happen for you to reconsider dropping that?
someone to support it..
that would change my mind. ;)
but really I'm fairly down with it,
I'm more curious, concerned about the other pieces (i.e. creating a core API module and an administrative module as well as possibly moving the userpoints_basic into its own module).
I'm trying to figure out the best way to make the core pieces lean/mean with a ton of functionality while also addressing the needs of how people are using it (i.e there are a lot of requests for additions to userpoints_basic)
-Jacob Redding
-Jacob Redding
I like the direction
Jacob,
I just wanted to chime in and let you know I really like the idea of making the User Points API even more free standing than it already is.
It would be nice if someday in the future we could build a pseudo-custom User Points system by selecting a collection of modules from the shelf and putting them together to create a solution that does specifically what we want.
One suggestion would be to package the API (and its related modules) separately. With the advent of the update status module grouping common modules raises some issues. For example of an issue I face, whenever someone makes a change to any of the modules in the userpoints_contrib collection, I'm notified by Update Status one of the modules (not sure which one) has been updated and should be replaced. If I try to outguess the system and only copy the module I need out of the userpoints_contrib collection, I still get the notification.
Thanks for all your help on this.
Kevin
to be a bit clearer
I don't want to create 4 separate projects. I still want to leave just one project but create separate modules within. This is just like views does it currently. Views API and then View UI.
We'd have
Userpoints API
Userpoints Administrative Interface (i.e. UI) heck would could call it the UI
Userpoints Views (maybe we just throw this with the API...?)
Userpoints Workflows (again maybe just with the API ?)
Userpoints Basic becomes its own project. Maybe not know but it'd be put on the path to be branched out into its own project, thus we'd have 3 main projects; Userpoints API, Userpoints Basic, Userpoints contrib modules (the hodge podge). Possibly other items branch out like the ubercart userpoints did.
My main reason behind this is that things are getting more robust and as a result more complex. I think separating these items not only only for a more streamlined userpoints installation if need be but only focus attention on the necessary parts (i.e. we don't have to call the API broken if we have a problem with a report).
-Jacob Redding
-Jacob Redding
That makes sense
I like your thinking.
It's a lot like how Organic Groups is managed. There's the API and a few wrapper modules with the core project.
Then there are a slew of other, independent modules, that support the project. Maybe there will even be a User Points modules category on d.o someday.
I've released a couple of my modules as separate projects (http://drupal.org/project/userpoints_votingapi and http://drupal.org/project/userpoints_top_contributors) so users can use update_status. module to more easily manage updates to these modules when they're released.
Keep up the good work.
Kevin
also I like this
I like this branching out of individual modules and the creation of a UP ecosystem. My goal it to continue to encourage this. Keep the contrib modules small and the API mean & robust.
-Jacob Redding
-Jacob Redding
cool kbahey...
OK I'm just waiting for some sign-off from the big man himself ;) and then I'll try to schedule sometime over the next few weeks to do this. I'd be fully down for reworking the userpoints hook to pass off the full $param array, adding in some other feature requests into core and then rolling a v4 for d6 and.. as they say.. stepping it up a notch ;)
I think good things are ahead.
-Jacob Redding
-Jacob Redding
while we're talking api...
http://drupal.org/node/306514#comment-1011808
This simple addition to the API would make everything so much easier and much more flexible. The ability for a module to instantly query all of the possible userpoint integration points is crucial to the extensibility of userpoint, imho.
Doing a bit of work this weekend
We had a need for assigning points for actions in a d6 project we're working on, so I've been evaluating userpoints this weekend and it seems to have most everything we need. I've done a bit of work adding support for core drupal actions (as a sub-module) and have some thoughts for changes to userpoints_basic as well.
The core actions support is working but needs a little bit more polish before I post it to the issue queue. I'll try to get that up today though.
We were hoping to use userpoints_basic for assigning points based on creation of certain types and comments however I'd like to make a few minor changes by changing the $param['operation'] to reference the content type being created rather than 'insert', etc. I'd also like to add an administrative UI to specify some flood control settings so that points are only granted once per a specific time period. This could be per content type or as a global value. I'd like to get thoughts on this before I put much work into a patch, especially considering the reworking you're planning on doing.
Let me know what you think!
A few thoughts
In working out some of the needs we have for our implementation I've come up with a few other changes I'd like to request as well. I thought it'd make sense to bring them up here before submitting them as patches to the current d6 branch.
1) In working on my core actions sub-module I set up a new hook, userpoints_params. This hook currently passes the context of the action as well as the $object of the action by reference, allowing a custom site module (or other modules) to produce overrides for the $params array before it's passed to userpointsapi. I'm using this currently so that I can properly map things like tid, entity_id and operation. It seems to me that a hook like this to manipulate the $params array makes more sense directly within the userpoints module.
2) I'd like to request that the current hook_userpoints be reworked to simply pass the entire $params array that currently exists, rather than passing only the few values it does currently. This will allow modules to make more explicit decisions on whether or not points should be granted.
As an example for both points above, we're using the flag module on our project so that users can recommend content posted by others. If a user's post is recommended, we award that user X points. This is being handled through the core action support within the flag module. When the action is fired a basic $params array is built with the points being awarded, the uid and the operation which is mapped to the hook the action was triggered from. Once this basic $params array is generated hook_userpoints_params is fired and I manipulate the tid, description, operation, event, entity_id, and entity params from a custom module.
The manipulated $params array is submitted through userpoints_userpointsapi() where hook_userpoints is fired. In my custom site module I call this hook and pass it the full $params array. This lets me perform a SQL query to see if this entity_id has already been awarded points for being recommended. If it has I return false.
Let me know what you think of these suggestions. If you'd like me to submit patches to the issue queue let me know!
Jer
change hook_userpoints
We don't need userpoints_params we need to pass the entire $params array via hook_userpoints. This was discussed as happening for the 6 stable release. Removing all other parameters. http://drupal.org/node/288985
-Jacob Redding
-Jacob Redding