Deduct userpoint after the user view a content?

This module wouldn't really support that functionality at all, but it would be a great companion module. I even started a module called Userpoints Pay Per View that would do exactly what you're talking about. However, it fell apart due to several reasons. The main issue is that it's hard to state exactly what to do when a user wouldn't have enough points to view content. It was apparently impossible to dynamically decide access rules based on points, so it wasn't so easy just to throw up an access denied page (along with a custom message, that would be ideal). Also, there would probably be an option for if a user would deduct those points each time they view the content versus just having points deducted once and then being able to view the content forever. But then, would it be fair to deduct points from a user each time they just refresh the page? There are a ton of questions here, but they are definitely for another module. I would really love to see this module come back to life, but I would really need help, because so far I haven't had any luck getting it started and all my attempts to call out for assistance have gone unanswered. Is there any way to really give this post traction so we can get some good minds in here to come up with a solution? Or maybe it's easier than it seems and I'm just not sure how to do it. Regardless, it would definitely not be part of this module, as it's a very different scope of functionality, even though it would probably be handled in a similar way.

@Billy: There's two modules on here somewhere that can be used to add an "early" or "late" hook to a node. These hooks ostensibly are called respectively at the beginning and end of a page load. Maybe you could put the deduction/balance test in one of those hooks, and just bounce the user if it fails - While this may not make sense in the context of static content, if the node contains a video or other "live" media, they should be charged for every view...

I'm not the PHP developer you're looking to collaborate with, but if you want to bounce some ideas off me, hit me up at my contact info.

If you could point me out to those modules, that would be great. I've been looking around during this time and haven't found anything that would fall under those categories. I've also been looking around and found "hook_init"; I'm wondering if that may be the right hook for this.

I'm interested in developing this module(s)
We already have userpoints_nodeaccess which doesn't work at all and is not being actively developed.

i think we should have
userpoints_pay_per_view which has CCK field integration, for CCK private field access control
userpoints_pay_per_node which is bassicly userpoints_nodeaccess but works :)

I hope there is more interest in the community!

That's an interesting idea. I started the module for userpoints_pay_per_view (used for nodes), but I never got anywhere because I always ran into some kind of road block with the idea. If you want to try and develop and would like ownership of the module, feel free to PM me and I'll transfer ownership. Each time I think I come up with a solution, I think of something to shoot that down. So, if you are interested in developing it, go for it. Let me know if I can be of assistance.

Actually i had given it more thought, and probably going to go in favor of creating userpoints_checkout instead.

Still two modules:

userpoints_purchase for purchasing credits
- Integration with different checkout/cart modules, we already have uc_store_credit for Ubercart
- We just need to port that, and implement hooks for e-commerce and simple checkout.

userpoints_checkout
- CCK private fields integration for the display of CCK fields based on role permissions.
- hook_perm / hook_access / nodeapi (i think) integration for node based access control
- user_permissions dependency. user_permissons creates a role for each user, which means user defined access rights!
- Integration with different cart and checkout integrations (ubercart, ecommerce, simplecheckout)
- Defined access privileges: pay per node, pay per view (cck field),

- Views integration of forms, node integration of forms
(Checkout forms, purchase credits forms)
- Transfer of spend store credit to seller
- Substraction of store credit from buyers account.

I'm a php programmer, but pretty new to drupal, but in theory this should work i thinkk:)

Just created some module code with module_builder, so i will see if i can get a start when i get home tonight, and hopefully start the new project on drupal :)

I don't know that userpoints_checkout would be quite the proper name for that. I think userpoints_pay_per_view and userpoints_pay_per_node like you mentioned originally would be more proper. You can go ahead and take the userpoints_pay_per_view module, if you choose that name. The purchasing of userpoints should be in one module (userpoints_purchase or uc_store_credit), and the handling of access would be in the other module. However, I don't know about making roles for users. While that would make it possible to give much finer-grained controls, there are a few issues. For one, you can't deny access to something that someone already has access for (I believe). As such, the original idea was to redirect users if they couldn't "afford" to view the content. Additionally, having hundreds of rules with a role for each one could lead to way too many roles to manage. With Views you would also need to be careful about how you manage things like showing multiple restricted fields at once and so on. You can kind of reproduce this functionality with that module that allows you to purchase items with points, so you can buy points and then buy other nodes from the store. It's not as simple as a generic pay per view solution would be, but it works.

So have not had time to get back to this, but lets try again

- I don't know that userpoints_checkout would be quite the proper name for that.

Yes i agree the original namespaces would be userpoints_pay_per_view and userpoints_pay_per_node and would be much beter suited.

My original idea was to implement the different checkout methods namely:
- ecommerce, ubercart, simple payments.

But maybe i'm looking at it the wrong way and we should just simply provide the hooks for referencing the CCK field or Node iD user and points.

- For one, you can't deny access to something that someone already has access for (I believe).
Exactly so by default we would want to deny access through these fields through the content_permissions module.

Then we can use user_permissions - ( "Provides the ability to manage permissions for individual users without the need to manually create a role for an individual user." ) -
to enable the field for a specific user.

I don't see a problem where viewing the field is not possible by views cause of the content_permissions, because we would not want that right? We would want a "Buy Now" field to display for the field, but not the field itself.

Once the node or cck field is bought we update the user role set in user_permissions which overrides the other system roles and does not interfere with them.

Hmm i'm starting to confuse myself now. I need to make a better overview when i get home in 5 hours.

Any input is welcome!!

I want to start off with:
pay per view access control

But we'll need to think of a way for fine grained (user based) access control which allows both CCK field and node access control.
Obviously for cck field control we'll need a new table scheme (rid, nid, cck field).

i still think user_permissions is the way to go, i don't see any other way for user based permissions....

for purchasing userpoints we'll use the uc_store_credit for now, since its the only payment system that allows it at this point.

actually woudln't userpoints_pay_per_field a better name? Since that's actually what we want.

Pay per view implies deducting points per content view.
While we actually want a user to buy access to the contents of a field.

This would open the door for many things, like micropayments (i.e. call cellphone number to display contact details, pay for a video, pay for articles).

I do agree that the best idea is to try and keep it simple for now. I'd recommend to start small and then move up to the ideas you've mentioned in this thread. I know there's a site that was recently featured on Drupal that did something similar in style to what we've been talking about here: http://drupal.org/node/672802. I'm guessing they used userpoints and one of the ecommerce modules to purchase points and to purchase content with those points. However, it may be worth looking into to see if they did any other method. I would start with simple access rules for nodes and then move to more specific rules like fields. The modules for purchasing and receiving points should already be completed, so you shouldn't need to worry about those.

"i almost (completely) agree :)

i'm going to create the module userpoints_fieldaccess since we already have a module userpoints_nodeaccess.
While userpoints_nodeaccess has not been maintained since october, i still think we should just build out the module under that namespace.

The reason being it would otherwise just add to the confusion by adding userpoints_pay_per_field or userpoints_pay_per_node for example.

This way we keep it clean, descriptive, and no duplicate / non functioning modules.

"he modules for purchasing and receiving points should already be completed, so you shouldn't need to worry about those."

I agree

Actually i'm starting off with fieldaccess, because well its what i need for my project, so i just need that done :)
I am writing the admin settings part right now, when i have that all "visualized" i will make the database schemes, and then the frontend part.

Hope to get a semi-working dev up in a week or so, and hopefully get more people on it!

The module is actually not that complicated, i was a bit overwhelmed by drupals api and and writing procedural code like its OOP but the pieces are starting to fall into place for me now.

Applying for CVS account now and hope to get the module up there so we can discuss functionallity further!
thanks for the input.

Actually for userpoints_nodeaccess:

Take a look at the premium module.
I think that's kinda what we want to achieve: show the teaser,, hide the rest, show custom message and pay button to buy the content.

Also we should maybe have two options for each field (in admin):
- pay once
- deduct every view, or by set time frame, so that when the users cat is sitting on his F5 key, his points wont dry up:)

Views integration would be last i think.
It should all be able to function within the node.

Hey guys,

Just wondering where this is at? I could really use something like this for a project I have.

I haven't worked on it since my initial effort so long ago because I haven't had a need for it. I also haven't heard from milan0 about his version, so you may want to reach out directly to him to see if he's made any progress.

hi

i used above two modules ,but couldn't find solution,

Please explain how it will works

Thanks & regards

Din

Not sure what two modules you mean, but I'm not sure that anything has been done in this regard. Someone probably still needs to create this functionality. If you have any more specific information, I can try to give a bit more guidance.