This looks great.

Re Dedupe Rules and contact data edition/editing, i think it is mportant to highlight this process (how dedupe rules are applied, where they can be configured), and also the consequences of letting people access your database to update contacts via profiles (which applies to events, membership sign up and contributions).  The questions you need to ask and data security questions should be addressed in the docs (I've started this for event registration) - any system where you allow people to assert they are who they are just by typing in an email and first name last name combination isn't very secure - some options to make it more secure that spring to mind:

• put new data in a parallel to be verified queue.
• ability to enforce login
• some fields only available to logged in people
• general history/undo mechanism for contacts

Couple additional ideas:

• Configurable registrant confirmation emails (both for frontend and backend registrations). The current automated emails are text-only (they *really* need to be html emails), fairly ugly, and can only be modified via the .tpl file -- which is not helpful for non-tech end-users, and also is very limiting, as it requires a one-size-fits-all approach (I can't have one email structure in place for event 1, and a different for event 2). The emails should be configurable in the headers/footers/automated msgs admin tool. Additional token values for events would need to be created, some of which cycle through multiple values -- for example a token value that lists all custom fields for the event. There may also need to be some logic tools introduced into the email configuration tool. When configuring an event, I'm envisioning selecting that you want automated emails sent, and then selecting the specific email template you want to use.
• Re: deduping per the above: I'd like to see a place where potential, but low-value dups are stored for review. So the functionality would look like this:
  • Confirmed dupe (fname, lname, email) > track with existing record
  • Confirmed not-dupe (no match on three values) > create new record
  • Potential dupe (two of three fields match) > temporary record created (so the user can complete whatever function they were doing on the frontend) and stored for review by admins (email notification as well). Admins have the ability to review this list of temp records and accept as a new record OR merge with an existing record (search tool to look up the existing record and cycle through the merge records dialog).
• Since this deduping concept does introduce additional administrative responsibilities, maybe there should be an option where it can be turned on/off as an advanced feature. When off, the existing behavior is followed -- only match with an existing contact if all three values match.

My vote for Approval!  It can be used in a variety of scenarios.

Please consider the ability to cancel registration - that has to be done manually.

Great stuff!

I'd really like to see "default" and templated values for all of the following:

Event Information:

• message if event full

Online Registration:

• Introductor text
• footer text
• Confirmation screen title
• Confirmation screen introductor text
• confirmation screeen footer text
• thank you screen title
• thank you screen introductory text
• thank you screen footer text
• confirmation email

Tell A Friend:

• Title
• Introduction
• Suggested Message
• Info Page link
• Thank you title
• Thank you message

The way i imagine this is that for each "section" as in Event Information, online Registration (maybe event the 3 sections within online registration) and tell a friend, the user could choose from a set of predetermined values.  Think of it like this: i might have a set of values i use on EVERY fundraiser event, a different set of values for every house party.  I would select the template set of values i wanted, they would be "read into" the fields, and i could update them from there.

These features are really good ideas.  Brian's point above about customizing emails is probably a global issue in Civi.  For example the acknowledgement email sent by CiviMember on new and renewed emails, automated contribution reminders, and so on.  All of these would be experienced as more powerful, more welcoming to constituents if the could be customized to the organizations culture/language.

Can't wait for these new features. Couple of suggestions:
1. Multiple owners for an event
2. Sub type of events. For example our organization has events and courses. Each event or courses can have their own type.
3. Region ACL levels. Like, show me all events or contacts in my region.
4. ACLs for group of events
5. Ability to show custom tabs, if user has permission for the custom data used for the custom tab.

Couple of suggestions for multi registrants

1) Allow for a different profile for secondary registrants - use case is a family registers for an event, the data needed for the primary person might be email, first name/last name, age, city, state, country. But for secondary registrants we might only need first name, last name, age

2) Allow for event fees to be paid at the end, i.e after entering data for all the registrants. This would be more in line with the way typical ecommerce systems work -

a) enter order data details

b) review summary of the order

c) Pay for the order

d) confirmation of order completion

These all sound great. Here are a couple of other ones that our clients have requested:

• Event reminder messages that can be set to go out to registrants a few days before the event
• Room reservation feature that would allow admins to assign a room to be connected to an event. It would also be great to have it act as a scheduler that keeps rooms from being double booked

Thanks for all the great features so far!

This is great to see. And of course, like everyone, I can just think of a few more things I'd like....

1) - Multiple participants.  Will people be able to register others without registering themselves? e.g. parent registering children. In a perfect world people it would be configurable whether people could register people they don't already have permissions over or whether they are restricted to those they do (e.g. a company admin can only register people from their company and they would get a drop down box to select the people from those and their details would be pre-filled.

2) Dedupe - I'd like to see a bit more control on e-mail field weightings. At the moment if they have a main e-mail and a billing e-mail in common they get points for both and you can't stop that which can tip the balance when you don't want it to.) Simply only allowing e-mail to count once would be enough in our case (or being allowed to determine who many e-mails can match)

3) Leila;s room reservation could be more of a resource reservation as there are other types of resources that need booking

4) note tabidi's comment about payment processor at the end currently applies to button mode & form I think but notify mode is at the end already

5) tokens available for the event name & maybe some other details that can be put in the e-mails to go out. I think someone mentioned this

6) The bit about setting template defaults by Gregory Heller - I strongly agree. I would like to have the option to set them to be 'default and supressed' meaning that any fields set up like that would have a default and would not be present on the add new event screens at all. This would allow the form to be much compressed (to about 8 fields in our case) in quite a flexible way (I'd also argue for not having so many pages or at least supressing some if all the fields on them are supressed. This also allows admins to prevent those who create events from editing things they don't want them to.

We typically set :

Title

Dates

Description

Pricing

7) Further to Brian's note about configurable confirmation e-mails - I suspect the biggest thing that is a problem for non-technical users is adding enough information for a receipt (ie. GST / VAT no, Charitable donation status, charities number or whatever)

8) One of the biggest problems we have with events is dealing with part-payments and partial refunds. Part-payments could be some negotiated rate or because they have taken it upon themselves to pay in installments. part refunds are always because we choose not to refund the whole fee. Ideally we could make more than one receipt against the same event 'invoice' but failing that at least allowing back end admins to override the price sets or whatever. I don't want to add a free text field to the front end users because the ability to enter non-standard amounts should be an office function

9) Ideally the participant listing page would group different types of participants in different sections - ie speakers separate from attendees. I also think there should be an extra template in the defaults - with status like the new one but without personal information (e-mails). Going into dream mode different confirmation e-mails for different types of attendees would be great

A few things I'd like to see...

I work with some groups that hold events where a person need to be able to register multiple people. For instance, a teacher may be registering herself as well as her team of students. For the students we'd only need their names and nothing else. The cost for the students is less than the cost for the teacher. All would be paid for at once.

The ability to easily add workshops to an event, set the maximum number of participants, and allow people to sign up for those workshops.

These are the two things I've run into the most when helping groups with CiviCRM.

How would event sign up work for a parent signing up their children, when no one has an existing contact record?  Would a "household" be created with the appropriate household members in it?  Ideally if the people sre not in the system, all this would happen automatically.  If the household already exists, the parent should be able to register existing kids ( and add new contact info for new children as needed.  )

What is the status of Brian's suggestion of record multiple contributions (payments) against a single event/membership/pledge? Is it going to be part of the 2.3 version?    That is a common scenario for an organization I am working with.