CiviCRM Community Forums (archive)

Hi!

Today i tried to use CiviEvent but i stumbled upon a problem (My Setup: Drupal 5.2 + CiviCRM 1.9; I restrict (utilizing drupals access control) civievent registration only to authenticated users):
-I create an event and activate the online registration (without payment processor). At the "allow online registration" form i choose "name and adress" profile.
-When i register at this event a email input field is shown, where i can fill in anything i want (=Lets assume a wrong email adress...).
=> after the registration the contact is updated and the user has an altered email (which is not a very desirable outcome)

Is it possible to hide the email field (in the registration process) for registered users?  I don't see why it is necessary for users to input their email adress every time they register to a new event...

Many thanks in advance!
gerhard

Mhm. Maybe your right. But there's no check whether or not the email is taken. What happens when a user registers with the email from another user? I consider this as a room open for misuse.

It sounds to me like there are a few separate concerns here:

1. Should a registered user be able to modify the primary email address on record for them when they register for an event?
** I'm still not clear about why this is different from someone going into My Account and changing their email address??

2.  For anonymous users, how should the Event Registration process determine whether the registering participant is a new contact or an existing contact?
** As of 2.0, we are using matching on email address to determine whether the person is already registered for the event. I think we are using the configured duplicate matching rules to determine if this is a new contact or an existing one. It would be helpful to get a detailed description of what you see to be the problems in these rules - AND a specification for how you think things should work differently for both the anonymous and registered user cases.

laborg, glad you posted this.  I have also been finding the interface problematic.

Regarding Dave's point 1:

The distinction is user expectations. Editing an email on My Account you expect the email of your account to change, editing an email on a registration or transaction page you expect the email used for that transaction to change.   This is also problem with editing name on payment transaction pages.  When name is labeled 'Billing name', you expect this to only affect the current transaction billing, however it updates the account name.  Especially a problem due to people doing third-party billing (e.g. using your spouse's credit card).  'Billing Address' updates the primary account, but this is OK since it will only update the 'Billing Address' and leave the 'Primary Address' unchanged. 

As a user interface principle it should be explicit when you are changing your primary account details.  Possible solutions to improve this problem with the user interface on registration/transaction pages include:

1. Load editable email, name and addresses form fields with default values from the primary account.
THEN
a. Present a check box allowing option to update account (e.g. 'Update account with with email address');
b. Use values just for the transaction/registration and do not update primary account details;
c. Show explanatory note indicating that these values will update primary account where it's not otherwise explicit; OR
d. Add new secondary fields in the account to hold typical registration/transaction values  (e.g. in the same way addresses for transactions are stored in additional 'Billing Address' fields, a 'Billing Name' field could be added).

2. Present email, name, and address as fixed text with values from the primary account
THEN
a. Present a button to change fixed text into editable fields (e.g. 'Edit details');
b. Present a button to link to My Account page to edit values (e.g. 'Edit details on My Account'); OR
c. Do not present a link to edit (e.g. if third party billing was to be discouraged, then leave billing name fixed as account name).

Some combination of these should be tailored to each instance of account info occurring in CiviCRM forms outside MyAccount pages.   

Chris - Thanks for the thoughtful and very clear statement of the issue AND potential solutions. I think we need to allow "third-party billing" - but I'm not sure we need to save that info. I also think making the fields read-only by default for logged in users - with the option to make them editable via "Edit Details" button - seems like a good simplification of the UI.

I've extended an existing 2.1 issue which covers this problem - and added your suggestions to the issue to help "seed" the solution. As usual, if you have time / resources to work on this - that will help move things forward faster.

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

The problem with "Billing Name" over-writing an contact's First, Middle, Last Name data has been fixed in 2.1:
http://issues.civicrm.org/jira/browse/CRM-2685

With regards to authenticated users changing their email address from an Event Registration form or Online Contribution form - you can use the "customized template" functionality to create a modified version of these templates which conditionally makes the Email Address field read-only (based on whether the form is being presented to a logged in user w/ an existing email vs. an anonymous user). Along with this - starting with the upcoming 2.1 release you can set the "Strict" Contact Matching rule for Individuals to ensure that an anonymous user's data (via contribution or event registration) will NOT match / overwrite / get linked to an existing contact.

Of course, as CiviCRM is a community supported open source project - you are also more than welcome to bring resources to the table to make any additional enhancements to better meet your organization's needs.