Closed (fixed)
Project:
Signup Integration for Ubercart
Version:
6.x-1.0-beta3
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Aug 2009 at 21:47 UTC
Updated:
9 Sep 2009 at 14:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
ezra-g commentedWhat version of Signup are you using?
Comment #2
jacerider commented6.x-1.0-rc4
Comment #3
ezra-g commentedAs you suggest, based on the fact that it only happens with signup-enabled nodes, it seems likely that it's coming from signup.module.
Perhaps the user is already signed up for an event that you added to the cart?
If that's not the case, since you are comfortable with code, I would suggest putting a
watchdog('debug', print_r($debug_backtrace(), TRUE()));in the top of drupal_access_denied() to see where the 404 is being generated.(or, use dprint_r if you have devel.module)
Comment #4
ezra-g commentedYou should also check to make sure that users who are checking out have the "view own orders" permission.
Please re-open this issue if you're still having this problem.
Comment #5
GregoryHeller commented@ezra-g you can't give the "view own orders" to anon users from what i recall because they can then see any order made by an anon user. so what you are saying is that the uc_signup requires purchasers to be auth users?
Comment #6
ezra-g commentedGreat point! Thanks for helping me identify the problem.
I think we can remove the access checking on the attendees forms menu callback and fix this error.
Comment #7
GregoryHeller commentedEzra, it would be really great to allow the anonymous checkout options that ubercart offers by default where a user can checkout even if not authenticated and ubercart will create an account for them, or allow them to specify a username (and password).
I would expect the workflow for an anon user attempting to signup to look something like this:
1. view the node that has signup enabled
2. click the "Add to cart" button
3. get directed to their cart with node in their cart
4. click checkout, be asked for email address of attendee(s)
a. if user is authenticated this should default to the user's email address, at least for the first attendee
b. if user is anon, and email address does match, they should be prompted to login
c. if user is anon, and email address does not match, they should be informed that they will be able to create an account on the next screen
c.i. If an address is added that does not match a user in the system, a message should be displayed that indicates such, eg "We do not have contact information for the email address specified. Please provide contact information (either here, or on the next page)"
6. Next Step: is checkout. This currently doesn't work for anon users even if anon checkout is enabled on ubercart. for an anon user, they should be provided with the opportunity to "sign in" or "create an account" in the "customer information" section of this form. This is the way that ubercart works if you have anon checkout enabled. If you specify that a user can "specify a username and password" those fields will be offered in "customer information" otherwise if left blank, ubercart will create a user from the part of the email address before the @ sign.
So here is a bit of info i just discovered (should probably be a new issue):
If i add two of a signup product to my cart (probably happens if i add one too), and i specify an email address that does not match an existing user, a new user seems to be created from that email address (the user name is the part of the address before the @ sign). But no "new user" email gets sent to that address.
Another issue i discovered, that probably should be added as a new issue but i will mention it here: After adding a signup product to cart and checking out, if the user returns to the product node page they will see the same "Add to cart link" even though they have purchased this product before, which could be a little confusing in some use cases. Where I am hoping to use this module we have changed the "Add to cart" button text to "RSVP Now", so a user presented with that text may be confused because they would also see their name in the list of signups.
Comment #8
ezra-g commentedComment #9
ezra-g commentedThis should definitely be compatible with anonymous checkouts, so I'll change the access checking on those menu callbacks.
You raise a good point about the new user emails. Please submit an issue for that.
Comment #10
ezra-g commentedHmm, I see why you would be getting access denied *after clicking the checkout button* but not after the whole checkout process. Does this patch resolve the issue for anyone?
Comment #11
echoz commentedI had access denied *after clicking the checkout button* and this patch in #10 resolved it, thanks!
Comment #12
ezra-g commentedThis is committed and marking #559666: Anonymous subscriber get Access Denied as a duplicate.
Thanks for testing, @echoz!