Automatic points when node becomes published?

Agree, it makes more sense only awarding points on published nodes/comments.

Hi,
I am looking for the same solution. Ideally I would rather not have to hack the core to implement my own home brew solution. Even if we could get the points to be awarded after a node has moderated would be ideal..

Thanks

maybe a solution is to use nodeapi and check when a node is updated - upon the node being updated and the status being 1 - THEN allocate the points?

since the "userpoints_basic" module already uses nodeapi and insert hook to add userpoints, I guess I would have to hack the module to implement a check. Hack the module is not something I wanna do, none the less, it is a step in the right direction though.

I'm interest to this idea too, also would be nice if user will only recieve the points when there article/node becomes promote to front page.

I mean.. I dont want to delete user content/post, substract points when not promote to front page only. it's possible?

Hi,
I have just posted a solution here: http://drupal.org/node/169898
Although this is for moderated content, it should be easy to modify it for publised.

Hello,

As requested at this issue report, #169898: Userpoints ONLY assigned when node is moderated, #169402: Substract points if not promote to front page and #228938: Points to promoted nodes, I made a patch to make two things possible (apply to userpoints-5.x-3.3):

1. Allow promoted nodes to gain extra configurable points.
2. Does not compute points of nodes with "Published" flag unset

I tested everything and it seems to work just fine.

There is no way to implement this behavior without hacking userpoints_basic as I did. An extra module would conflict with it and would have to be a full rewrite of the userpoints_basic.

The need of an additional table is impossible to skip, as explained here. The patch however handles the table creation / deletion. This table caches publishing information (published, promoted) to be able to handle publishing / promotion changes accordingly. For non-cached nodes, it is assumed that both published and promoted are disabled (see below).

Future:

- I am no DB expert, so obviously the DB code will need some improvements (although it works). For now, this is no big deal, since it will only be used at node creation, update and deletion.
- It would be also nice to implement a pre-caching of the above table at module enable (would be really pain in the ass for huge installations, but there is no way to avoid it). This would avoid the "assume unpublished and unpromoted" states.
- The contributed module userpoints_retroactive will not be aware of the extra rules and will perform as if they do not exist at all (although they will work). I will try to make a patch for it, and post it there when I finish.

That's all for now. If you guys could please test it and report potential issues, it would be very nice.

Happy user pointing!

As promised, here it is the userpoints_retroactive part of the patch.

WARNING:

There is a case (which I have not yet debugged) which when a promoted node is edited and saved, the node's author gain points again for the post he's already won points. So, to use at production environments, this has to be fixed. I'll work on that on the next couple of days.

This patch is completely unnecessary and would introduce a ton of bugs as a lot of calls are simply missed.

Everything needed to provide this functionality is already built into the module. A separate table is not needed and would only make things more complicated in the future.

Solution 1) Use workflow_ng integration and don't use userpoints_basic. Only assign points on a published state.

Solution 2)
---1) take userpoints_basic flip the nodeapi op from 'insert' to 'submit'
http://api.drupal.org/api/function/hook_nodeapi/5
---2) use the API award the points in the exact same manner, note that version 3 now tracks the entity_id, entity_type and operation of the node. Using these fields the module already tracks and ensures that a node does not get double points for the same operation. Although this is current based off the 'insert' operation it should take little more than changing the name from 'insert' to 'publish' to prevent double points from occurring.

Solution 3) Use the hook_userpoints which fires before any points are awarded thus you have the opportunity to prevent points from being added and/or to squelch the points and award your own points (modify the original call).

I sincerely apologizing for not jumping into this thread and providing this advice earlier but the patch above provided by neofpo is very much appreciated but also very messy. I wouldn't recommend using it on any production system instead opting for a much simpler and cleaner approach by implementing number #2 which should take no more than a few hours.
Yes you have to hack userpoints_basic but maybe people didn't read the README file or the documentation which clearly states that userpoints_basic is an example file (hence the name). 'Core' for this module only refers to userpoints.module; which contains everything you need to make this possible.

Again my apologies for barging in at the last second and not getting involved earlier but please consider redoing your work so that it plays a bit more nicely with the current API. If we can work the changes of #2 into userpoints_basic in a clean fashion then we'll get this into the module to be part of the download package.

Thanks anyway for the nice feedback jredding, no need to apologize. I intent to get on track on this patch (as you suggested of course) but I can not say when (I am kind of busy lately). I keep you up to date on anything I do.

I accomplished this for my site today by changing a function within userpoints_nc module.
See the post I made for the code:

http://drupal.org/node/416358

Sorry for spamming the participants in this issue. Due to the release of Drupal 7 and the lack of time from the maintainers, I'm closing all remaining 5.x issues for Userpoints.

Feel free to re-open this issue or create a new one for 6.x or even better 7.x if this bug is still open or feature is missing for these versions.