Posted by artatac on August 17, 2009 at 12:38pm
5 followers
| Project: | UC Node Access |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Is it fair to say that uc node access ONLY works if the purchaser already has an account and is logged in BEFORE they purchase the right to view a premium node?? Because that is what I am finding.. Could I request a feature that checks if an account is about to be created (during the checkout process) and allows this to be done BEFORE the node is assigned. Or at the very least that it displays a warning along the lines of
"do not proceed with this purchase untill logged in as a user"
Comments
#1
Surely this is a major bug in that it does not work as you would expect, am I the only one who would be surprised if a sale by a user NOT signed in fails.
#2
I was able to get node access working for a purchase that uses Anonymous Checkout. I'm using UC 2.2 and a stock uc_node_access dev version, or at least no code modifications I have were required to get this to work.
I did it entirely with Conditional Actions.
Due to other Conditional Actions that I added/modified to get role granting and file access to work properly, the fix isn't exactly straight forward. To get role granting and file access to work properly no matter whether the order status ends up as Payment Received or Completed after the payment is processed, which is dependent on the shippable/non-shippable by item makeup of the order, I followed the instructions in comment #21 in this post:
http://drupal.org/node/479836#comment-2023356
I have been running with those CA modifications in a production Ubercart membership site that also sells physical products to allow role granting.
So following a similar method to add in node access, I added in another 2 CAs.
1) Name: Grant node access for non-shippable items only
Trigger: Order status gets updated
Conditions:
a) If original order status is not Completed
b) If updated order status is Completed
c) Check if the original order cannot be shipped
Action: Grant node access to customer at a later time
2) Name: Grant node access for orders with shippable items
Trigger: Order status gets updated
Conditions:
a) If role of the user is not anonymous
b) If order can be shipped
c) If updated order status is Payment Received
Action: Grant node access to customer at a later time
Weights don't matter in this case.
If you can follow what is going on in the link that I gave above, then you will see that these 2 CAs are just duplicates of the trigger/conditions for what was done for role granting and file access.
So in addition to adding these 2 new CAs, you just disable the default CA provided by uc_node_access, which is under the trigger "A payment gets entered for an order".
I was able to successfully grant node access going through Anonymous Checkout using an order with all non-shippable items, an order with non-shippable and shippable items, and also was able to test an order with someone who was already logged in. All cases worked.
I'm very certain there are much better methods to do this, especially if you don't have to try and fit into an existing site that has CA modifications to get other things to work as I do. But I'd suspect that at the very least this might give someone an idea of where to start playing around to find a much more elegant solution.
If someone has the ability to try this method out, I'd appreciate any feedback.
Thanks,
Jeremy Zerr
http://www.zerrtech.com
#3
Jeremy.. Thanks for the wisdom on this.
I think I understand this in principal … the default CA grants access too early before the user is created?.. I'm hazy on the details, for some reason I find Conditional Actions hurt my brain.
So.. if I only have non-shippable items to worry about I should be able to get this done with your first CA? Or does this need to be a two step process as with the RS Taylor solution?
Presumably for the action will works equally well if granting immediate node access?
#4
Exactly, the default CA runs before the user is created.
If you only have non-shippable items, I bet you can get by with a lot less complicated CA setup than I did, I wouldn't wish my ugly CA setup on anyone, definite brain pain there.
Basically, I bet if you follow the model set forth by the default CAs that come with the role granting or file granting modules that use the "Order status gets updated" trigger, create a new one using the same trigger and conditions, but use the action for node access, I suspect that would work. If you have time to test something like that, I would be interested to know if it works, and also many others would too I bet. If we were able to figure it out using a very basic CA change like that, instead of my ugly CA setup cause by other setup specifics for me, it would definitely be workable into a patch to commit to the project permanently.
Thanks, Jeremy
#5
Finally had a chance to check this..
Jeremy is correct, the default action created by UC Roles is the right way to approach this:
Title: Grant or renew purchased roles
Trigger: Order status gets updated
Condition: Original order status was not Completed
AND
Updated order status is Completed
Action: Renew the Roles on order
Adapting this for UC Node Access:
Disable Default UC Node Access Action
Add Action:
Title: Grant appropriate node access on ORDER UPDATE
Trigger: Order status gets updated
Condition: Original order status was not Completed
AND
Updated order status is Completed
Action: Grant node access to customer
This works great on a site with no shippable products.
#6
@anthonyjhall
Great job! Would you be able to create a patch to use this new CA as the default CA? Then we could have this problem fixed for the future. If not, just let me know and I can work on it too, it would definitely be worth it.
Thanks, Jeremy
http://www.zerrtech.com
#7
Attached is the patch that corresponds to replacing the current default CA with the new one detailed in comment #5. I elected to not just disable the current default CA, and instead just remove it completely. Tested this out using Ubercart 2.2 uc_node_access 6.x-1.x-dev and it worked perfectly, allowing Anonymous checkout to get access to a node they purchased.
Thanks,
Jeremy Zerr
#8
I'm marking my own patch as needs work because all the patch does is add a new CA and doesn't do anything about handling (disabling) the original one. If both CA's would be enabled at the same time, that wouldn't be ideal. This patch will work but you will have to delete the original CA by hand.
#9
Jeremy, thanks for stepping up to help maintain this module. I'm putting your patch back to needs review because for me it did indeed replace the original CA. I think it's an improvement over what's currently committed, however in my case it didn't actually solve the problem. I believe the root cause of this issue is the new user login redirect triggered by the Ubercart core uc_cart module as described at #794756: Login redirect causes uc_checkout_complete trigger not to be pulled.
#10
Subscribe
Cannot get uc_node_access to work at all. Perhaps it is related to the default out of the box CA settings for the module. So I disabled the default uc_node_access grant CA which really only gave the directive to 'grant access at a future time' when the order status changed to 'payment received' with a balance <=0.
So for a brute force test I just created a CA to grant node access when checkout is completed, but node access was not granted.
There is another post http://drupal.org/node/662438#comment-4638488 which suggests that uc_node_access doesn't work with Ubercarts attributes. Maybe that is the problem.
Help!
#11
I have committed this patch into dev 6.x-1.x. Patch tested with Drupal 6.22, UC 6.x-2.7, ACL 6.x-1.4, and Content Access 6.x-1.2.
Jeremy Zerr
http://www.zerrtech.com
#12
Oops, meant to mark as closed (fixed).