Add setting: Maximum registrations per user.

Here a patch that contain a view that displayed in tab for registrant users.
I also add permission level for users to manage their registrations.

I'm not sure it's obvious that a user couldn't register more than once since this tool is designed to allow a person to register other registrants. It also certainly wouldn't be done with Views integration. Probably needs to be a settings on the node/entity level dictating whether or not an authenticated user can register more than once.

I am sorry, I guess the patch is not directly relevant to this issue. This patch is an interface for the user to manage registrations he created.

I will move it to a new issue.

I don't understand why the module allows a user to register any person in the world up for an event. There should be some kind of verification process.

Suppose this module, and or third party modules, were to send an email to registrants of an event. How could the user opt out of further emails per CAN SPAM/Spam Act etc?

Unfortunately I think this isn't the best of design decisions.

• Registrations should be associated with Drupal users (author_uid)
• Per-registration email should be dropped.

I'm not saying that a user should not be able to register for an event more than once, although a good default would be once.

Whether a user can register for an event X times should be a registration_type or entity setting.

I think it would make sense to add `maximum registrations per user` setting to {registration_entity} table. Provide a sensible default, `1`. And allow admins to change the default on a per registration type basis.

Related: #1430870: Automatically Create Registration Settings when Entities are Created

This issue is the only major blocker for me using this module on production.

@dpi

You guys are really kicking this modules butt so thanks

One thing that I wanted to make sure of is that I can register as many different people as possible.

My use for this module is to integrate with conferences and in higher education a secretary will need to register 20 different faculty or students and pay for them all at once. This feature is really HUGE in higher Ed and probably in high level corporate gigs.

Hey gang - I'm seeing several issues getting included here and it probably needs to get split out.

1. Allowing users to register more than one registrant / having a max registration setting
2. Viewing your own registrations
3. Registrant verification system

Re: #1, there's already a setting for allowing multiple registrations on a given event, and I don't think it makes sense to add a max registrations per user setting. Not applicable in enough use cases and easy to enough to add-in with custom validation. As a correlary, the question this ticket initially posed is whether authenticated users should be able to register more than once. We're already preventing duplicate registrations based on email, so this might just be a messaging question.

Yes, we need a mechanism allowing authenticated users to view existing registrations.

Yes, it'd be great to add an optional verification system for registrants that are added by another user. We currently have a registrations schema, and it might make sense to add a registrants schema as well in this case. Need to think this part through ...

In regards to #3 (registrant verification), you could in theory just generate a hash and associate it with a registration. Then in the email you send them a link to confirm that registration, and when they click it, it sets the hash to blank and a "verified" field as being verified.

I don't think you need extensive schema changes to do this, unless you're wanting to verify a lot of things or have multiple steps in the verification process.

I don't think you need extensive schema changes to do this, unless you're wanting to verify a lot of things or have multiple steps in the verification process.

At the least, we'd need to keep tabs on a registrant's status. If registrations / registrant mapping is 1-1, we could store it there. But if we need to verify additional registrants, we'd need a separate schema. Probably more flexible in the long term anyways.

@levelos

Re: #10

there's already a setting for allowing multiple registrations on a given event

I think you mean maximum registrations in total (capacity)?

I don't think it makes sense to add a max registrations per user setting

In my situation, I do not want a user to be able to register any other user/anonymous email to registrations. I need author_uid == the human that the registration actually is associated with.

In this scenario, the mail field is completely useless and user_load(registration.author_uid) to get the **current** email the Drupal user is associated with. Registration should default `mail` to to NULL, causing the code to autoload the author_uid email.

I have created an issue for `Viewing your own registrations`: See #1462796: Allow user to manage his own registrations.

No longer need a max-setting per user as per registrant uniqueness is enforced since #1517756: Control access to registration_form based on permitted people types.

Re: #10

• #1517756: Control access to registration_form based on permitted people types hides the Register tab if the user already has a registration, addressing the original issue.
• #1462796: Allow user to manage his own registrations covers viewing existing registrations (input needed!)
• #1525252: Allow anonymous users to unregister from entities for allowing anonymous registrants to de-register from a host entity.

I think we can close this issue.

Thanks @dpi, I agree.