Removing ability to register a different person

[demeritcowboy]

On the event registration screen there's a section that says:

"Welcome <username>. (Not <username>, or want to register a different person?)"

It would be useful sometimes to remove this. Since a full treatment is more work, I'd like to suggest just adding an id attribute to the surrounding div tag, i.e. this

<div class="messages status">

becomes

<div id="civicrm-registerDifferentPerson" class="messages status">

and then I can easily hide it in my extras.css.

This isn't the ideal solution, but it's a no-op for existing sites, doesn't prevent a fuller treatment later, and is a trivial template edit.

[Matt2000]

I've just submitted a patch to disable this feature when an event does not use the 'Register Multiple Participants' option.

[Matt2000]

And here it is:

http://issues.civicrm.org/jira/browse/CRM-6708

[petednz]

Hey Matt  - not sure i follow the logic of that - an Executive Assistant may be logged in and need to book just their 'boss' in to an Event - that option made it possible - your patch sounds like it removes it.

Was that the plan?

And appreciate you putting time in to sorting this, whichever route it goes.

[Matt2000]

If a particular installation needs to support that use case, they can simply check the 'Register Multiple Participants' box.

If that's not an option, the the Assistant can just log-out and register the boss while unauthenticated. If the system requires authentication to register, then the Assistant do what assistants have always done everywhere else-- log in using the boss's credentials. But if the system requires authentication to register, then we already screwed in your scenario, because the new 'feature' likely circumvents that requirement.

I know my patch is not a perfect solution, but the current state is completely unacceptable for many use cases, IMO, so something needs to be done.

[Donald Lobo]

1. whats wrong with dave's solution of using css to hide that string if not needed?

2. I dont see the connection between registering multiple participants and this feature? IMO they are separate and should not be combined

3. what use cases is the current state completely unacceptable?

lobo

[xavier]

Hi,

The patch makes sense, I should have put it a specific id since the start.

This being said, there is still the option to logout and do the registration as someone else if you want to "cheat" (that's been like that since forever, the new system just makes it more explicit).

FYI, we have some need to be able to offer anonymous registration for some events, and logged/in for some others. We tend to do the acl in the template. Works kind of ok.

X+

[Matt2000]

@lobo

1. Because it doesn't actually prevent anyone from using the feature, and using CSS for what is essentially "configuration" just feels like an ugly hack.

2. In an ideal situation, yes, both would be configurable separately. The relationship between the two is that both features relate to the question, "Should users be able to register other people besides themselves?"

The principle is: All software makes assumptions, but adding new assumptions that cannot be changed is dangerous. I'm simply arguing that the assumption "If the admin does not allow multiple registrations, then users should not be allowed to register other people" is better than the current assumption, "Always allow users to register other people."

My main reason for not adding it as a separate configuration is that I don't want to change the database schema, due to concern about the ability to apply future upgrades. So the patch I submitted is "future proof."

3. Any use case where untrusted users should not be allowed to register people besides themselves. A broken scenario does not even require custom code, although I mentioned using hooks in the issue comments. For example, consider a system using a smart group and ACLs to grant permission to register for a specific event only to contacts having a certain membership type. Almost any system using Event ACLs would be exposed to access bypass security vulnerabilities by upgrading to 3.2.


@xavier,

The 'cheat' you describe does not exist on systems that do not allow anonymous users to register for events, which is exactly the scenario where the new feature is problematic.

I agree that the system should support having both kinds of events -- those that allow anonymous registrations and those that do not.

I think the bottom line is that it's impossible to anticipate all of the possible access control issues that arise form the many possible combinations of configurations and add-on modules. So the simplest solution is probably the best -- allow administrators to disable the feature on a per-event basis.

[xavier]

@lobo

2. In an ideal situation, yes, both would be configurable separately. The relationship between the two is that both features relate to the question, "Should users be able to register other people besides themselves?"

The principle is: All software makes assumptions, but adding new assumptions that cannot be changed is dangerous. I'm simply arguing that the assumption "If the admin does not allow multiple registrations, then users should not be allowed to register other people" is better than the current assumption, "Always allow users to register other people."

I have use cases where you are not able to register other people beside yourself, but you can register another people instead of yourself.

(Not saying that my use case is more common than yours, just that your assumption they go together Isn't better, so far in 50% of the described cases

BTW, my most common usage is that an authenticated user (eg. a volunteer admin) goes to the registration page to register someone because they received an email "yes, I'm coming (but too lazy, technoresistant...) to register myself", see the form pre-filled with their name, replace their name by the name of the participant... hilarity and big mess in the db.

I agree that the system should support having both kinds of events -- those that allow anonymous registrations and those that do not.

I think the bottom line is that it's impossible to anticipate all of the possible access control issues that arise form the many possible combinations of configurations and add-on modules. So the simplest solution is probably the best -- allow administrators to disable the feature on a per-event basis.

I'm not a big fan of adding yet another option in an already confusing event creation form. Beside, layering dozen of checkbox options allows both illogical or incompatible ones ("Register multiple participants" unchecked but  "Allow multiple registrations from the same email address" checked). Offering loads of options but forcing the user to know which ones go together is bad UI.

Suggestion: Instead of a simple check box "Allow Online Registration", replace it by a select Online Registration ('disabled', 'only registered user', 'everyone').

If only registered user AND the user doesn't have the "edit event participants", then disable the user switching option.

The column is_online_registration is already there, instead of being a boolean, that'd be 3 values.

What do you think ?

X+

[Dave Greenberg]

Lobo and I discussed this further today. We think extending the is_online_registration property for events is the best way to handle the range of use cases discussed. I've detailed our recommendation as a comment in the Jira Issue. Matt - ping me on IRC or back here if proposed approach doesn't meet your requirements. Else if you can submit a patch to do "make it happen" we'll include it in the next release.

[Eileen]

Pleased to hear that you are going 3 ways on this. Probably the Wellington Circus Trust's biggest single pain point with CiviCRM is that parents only successful register their kids for events about 30% of the time and there is only one parent in our database with more than one kid who seems to have figured out how to manage that.

I would say this is our biggest pain point and if 3.2 can help with that without us having to also have register multiple participants that would be brilliant

[Dave Greenberg]

Further iterating on this w/ Matt ... Matt's latest suggestion is to extend the "Register Multiple Participants" field (currently a checkbox) to provide these 3 options ...

Register Multiple Participants:
0 = Users may only register themselves.
1 = Users may register themselves, along with others at any time.
2 = Users may register others without registering themselves.

Xavier and others - will this meet your various use cases as well?

[Eileen]

Yes, that's right. I assume the workflow will be smooth for them to register more than one other who is not them. ie. to register two of their kids in the same class

Are we at the point where they will be able to select others (or have others autofill) based on permissions? To my mind there are a couple of further variants:

- user may register other people that they have permissions over or
- user may register any other person

[Donald Lobo]

we'll need to check that the use case of doing "multiple registrations" without registering yourself works in this case. i'm not sure but i suspect people will try that with option 2 above

lobo

[xavier]

Hi,

How is this case covered in the imporved version?

 "Allow multiple registrations from the same email address"

Otherwise, looks good to me