Limit users to only signing up themselves?

This seems like a reasonable feature request that should probably be implemented with a permission. uc_restrict_quantity won't help here since you could still buy one signup and sign up another user.

We'd need to think about how this would affect the checkout workflow.

It would definitely need to be in uc_signup because of the way that uc_signup provides the UI and only uses the Signup module's API.

I agree that the workflow for this could get complex and require a lot of extra code.

@GregoryHeller - how common do you think this scenario is? Can you describe why this is valuable?

For point 1 - seems like they could just not use that feature if they want.

Point 2 - I've got a "merge user" module I'll be releasing shortly ;) Though I do see your point - I'm not sure just how much it makes sense to disable the multi-signup just to gain this protection.

Point 3 - how about some code that says "if we have all the data for all the signups, just forward the person to the cart"? That does seem like a workflow weakness that we'll want to make as smooth as possible.

Yeah man, I have been trying to get rid of those two extra pages in my checkout process while still allowing someone to sign up for a node. The nodes that I am letting people sign up for are not even events

@greggles - you asked for scenarios where this would be valuable. I need this for a client site where they have role based pricing. Organization members get a discounted price, non-members get a higher price, and special members (board of directors) get a really discounted price. Anonymous users get full list price.

The client want us to limit the purchase to only allow one purchase for the authenticated user (or the anonymous user at list price). Otherwise a member could purchase many seats at an event at their discount rate for non-members.

I think that makes sense, though an alternate solution to that problem is to use a coupon module with single use coupons for each board member and members.

@greggles - I'd not floated the coupon idea to the client and will. They are fairly firm on wanting role based pricing difference AND only wanting to allow purchase of a single seat to any given event. We've used the UC price per role module and the quantity restriction at 1.

Thanks for the alternate suggestion, and for the quick reply to my comments on a scenario where limiting purchase to a single seat is useful.

I am also looking for a way to simplify the signup/checkout. In perticular greggles point #3. Has anyone found anything?

subscribing

Marked #680860: Allow the administrator to decide if the user can submit multiple attendees on checkout., which has a patch, as a duplicate of this.

How hard would it be to make the patch per-class or per-item?

Per-item would need to store a nid to and setting relationship, probably requiring a new database table. Per-class would be similar but could have fewer entires than with the per-node solution, though I think either of these is reasonable.

#13 patch did work to skip over entering the email address for the user. (Awesome!)

But then in the checkout screen, if you have the "Attendee Signup Information" checkout pane enabled, you still get a "Edit signup information" link that allows the user to go and change the email address.

You could of course configure the checkout to not show that pane, but if someone wanted to show it, it might be best to disable that if you truly want to limit the user to signing up only themselves.

subscribing

I still have an issue with this one as you can still book yourself twice on the same event, which obviously should not be possible if user is only allowed to sign up for themselves.

Maybe little checking when try to sign up to event if event is already in a cart and in case user is signed in checking signed up events as well would help???

This still leaves options to try to sign up already signed up event when not checked in, but I guess some validation can be done during a check out.

@spylvas that seems like a slightly different, but still important issue. Can you create a new issue for it?

New issue created #862904: Users can sign up themselves twice to a same event

I'm posting here because http://drupal.org/node/680860 was marked as a duplicate even though it boasts the patch i'm reviewing below

Another relevant issues is:
http://drupal.org/node/862904
http://drupal.org/node/863352

As I see it:
When a user attempts to sign up, the Attendee Signup Info page during checkout attempts to verify whether that user has already registered for the event, and if so it does not allow that user to be signed up twice. That's at least my experience (note: i haven't tested an unpatched dev so i can't say definitively, i'm currently testing teh sept 15th dev with this patch applied.)

After applying the patch from #680860 and unchecking the Allow Other Attendees On Checkout so that one is not able to sign up other attendees, you go through the cart page and then the verification step from the Attendee Signup Info' page is skipped to take you to the checkout page (however, you can still select multiple tickets from the cart page - perhaps that could be an option per-event where an event owner can allow/disallow people from purchasing multiple tickets).

Stpaultim commented that if the 'Attendee Signup Info' pane (not page) on the checkout page is enabled, one can go back and alter the signup information. A few scenarios I've tested:

1. If you checkout with the Attendee Signup Info pane ENABLED, everything works when you're logged in or not logged in
1a. you can sign yourself up for an event multiple times whether logged in or not logged in
1b. if you go back and edit the attendee signup information from the checkout page, it will kick out an error message stating "the attending with the email address ___ is already signed up for this event (I have not attempted to continue through with checkout after going back to this page)

2. If you checkout with the Attendee Signup Info pane DISABLED, the event does not register the user under any email address, and you will receive the proper emails suggesting a successful signup.
2a. also, you get two errors:
warning: Invalid argument supplied for foreach() in . . . on line 662.
warning: Invalid argument supplied for foreach() in . . . on line 705.

Summary:
It seems that the only way that currently successfully prevents a user from signing up multiple times is through the validation step embedded in the Attendee Signup Information Page. It may be prudent to expose this validation step as a more general function that can be called at any step (or on multiple steps).

upon even further testing . . . you can potentially edit your information both in the Customer Information pane and the Attendee Signup Info pane!

If not logged in:
when you go from the cart page to the checkout page you can only edit Attendee Signup Information because the Customer Info pane is expanded to allow for email addresses and new account details.

Editing Customer Information -

1. Could we have a login/register page here to force only that a logged in user can register? This would make the patch in http://drupal.org/node/865384#comment-3411424 useful excepting that that patch sends an email and doesn't force an automatic login. It would also bypass the problem i fount and posted at http://drupal.org/node/680860#comment-3491978.

2. If we leave it as is, after clicking Review Order and fill in an email address that is already registered for the site you do get a message saying "An account already exists for your e-mail address. The new account details you entered will be disregarded." Note that there is no check to see whether this user is registered for the event. And, we could have a check here to see whether the username and password fields were empty, potentially getting rid of the unnecessary use of "the new account details you entered will be disregarded" or we could just put an "if" at the beginning of that statement.

Editing Attendees Signup Information -

1.When you click the Attendees Signup Information and fill in information for a registered user you get the message saying whether it's a duplicate or not. This works great.

2.However, if you enter a email not registered for the event, it will recognize this as a new signup, send you to the Attendee Contact Information page and then send you right back to the checkout page from whence you came. (if we want to eliminate a step, we can test to verify that the user is in fact signing up only themselves, and if this is the case we could potentially skip the checkout page and go straight to review order)

If logged in:
when you go from the cart page to the checkout page you can edit the Customer Information as well as the Attendees Signup Information.

Editing Customer Information -
This takes you to your profile page giving you the option to change your username and such. I'm not exactly sure this is useful.

Editing Attendees Signup Information -
When you put in an email address that is not the currently logged in user, the system accepts it, so apparently the patch i'm working with/testing (http://drupal.org/node/680860)on isn't verifying at all for a match between the user email for the signup and the logged in user. This potential loophole could easily be avoided by hiding the 'edit signup information' link (yeah, avoiding a loophole, not closing it, sound like extra work doesn't it?). And, if continued, the

When you put in your own email address things go as planned. And "[insert obvious Hannibal quote here]"

I've created a rough patch that adds a permission "signup other users on checkout", and if a user does not have this, it locks the default e-mail, and limits the signup to 1 per event. It also removes the link to "Edit signup information".

Possible additions:

* Since having a quantity of more than one doesn't make sense if a user can only sign themselves up, some sort of restriction mechanism may be needed. It has been suggested that we use uc_restrict_qty for this, but that would not respect this new permission.

I have applied the patch and can confirm it works.

The patch in #23 works, but I think it can't go in as is as it breaks the signup workflow if a user has more than one of the item in their cart, and we can't assume uc_restrict_qty is being used. Maybe add some conditional logic that only uses the default email if there is only one item in the cart? Or only if uc_restrict_qty has been added for that particular product?

Also, the patch doesn't seem to skip the email step, as mentioned in comment #4: "If you limited the user to only signing up themselves, you could also take 2 pages out of the checkout workflow, shortening the checkout path considerably" The patch would be much more useful with that being done.

Another issue: the $default variable can be empty if you are logged in and already signed up, which leads to the user getting the email form when they shouldn't. I don't see why that variable shouldn't be set to the account email address even if the user is already signed up.

Here's a re-roll that includes the following changes:
- Renamed the permission to "purchase signups for other users" which seems like a more self-explanatory description of the permission's purpose.

- Enforced this restriction on anonymous users, otherwise a user could simply log out and then enter an email address of an existing user in the uc_signup attendee email form.
With the present patch, if an anonymous user uses an email address for an existing account, she is prompted to login and provided with a login link that has the destination set to the current page so she can easily return to the uc_signup workflow.

- Enforces quantity limits on signup-enabled products when the user can only sign up herself, eliminating the need for uc_restrict_qty for this feature.

- Adds some code comments

> I don't see why that variable shouldn't be set to the account email address even if the user is already signed up.

My feeling is that we shouldn't set the user up with a default value that we know will fail validation.

This needs some more testing before it's RTBC. I expect to make at least one more round of revisions.

[Edit, not sure how I got to that patch filename ;)]

Actually, that was entirely the wrong patch.

With the latest patch, the user can still click the "sign up" (add to cart) button repeatedly and while the quantity in the cart is displayed as 1, the price in the cart is actually product cost times number of times "add to cart" was clicked. We need to improve the limit on adding items to the cart.

Also, following the patch in #24, authenticated users are prevented from entering an email address other than their own. However, wouldn't we want them to have the same ability as anonymous users to register any email address not already associated with an account? I think so.

Following the uc_restrict_qty module, I implemented hook_add_to_cart() to limit the quantity of a particular signup-enabled node.

I think it's ok to only let authenticated users purchase signups for themselves while anonymous users can enter any email address not already associated with the account. This is consistent in the sense that it's "a person can only sign herself up".

I plan to commit this soon, but it could definitely use more testing, as well as a bit of improved documentation.

After further testing, this patch overzealously removes items from the cart.

I revised this patch to skip the email address form when authenticated users can only purchase signups for themselves and committed. http://drupalcode.org/project/uc_signup.git/commit/ca71caa00b7d478e882bd...

This was my first git commit, and I misunderstood the workflow so I apologize for not providing attribution in the commit message. Thanks, @jhedstrom and folks who provided feedback!