CiviCRM v2.2

Allowing people to cancel event registration is is very important. They should not be able to delete themselves, just change their status to cancelled. What I am not sure about is should they then be able to reinstate themselves. Consider the following:

Early Registration (before 1 July) costs $100
Regular Registration (between 1 July and 21 July), less costs $150
Late Registration (between 21 July and 30 July) costs $200
Registration closes on 30 July, the event is 7 August.

Bill registers on 30 June and pays $100.
He then cancels his registration on 10 July and wants to reinstate on the 12th. Should he be required to pay the $50 extra (i.e. should this be treated simply as a new reservation?) Is it different if the refund has not been processed (or if no refunds are provided)?

Tom registers on 30 June and pays $100.
He then cancels on 25 July, but on 4 August wants to reinstate his registration? Again, assume that no refund was allowed (or just no refund was processed).

Including a link in the confirmation email to cancel one's registration, would be a really good thing.

Related would be the ability to add other status items to a registration that would also be user editable.

For example:
How will you be arriving at our event:

On foot or public transportation
Driving - have room for others
Driving - full car
Need a ride

This could be used to help match those who need rides with those who can offer them.

or

Entree choice:

Fish
Chicken
Beef
Vegetarian
Vegan

Both things could change (and in the second case, there might be a cutoff date for allowing changes).

/carmi

It is great that one can now easily create publicly accessible participant lists. What would be very nice is to be able to chose which fields get displayed and how the lists are ordered.

For example:

Registration form collects this data:

First Name
Last Name
Nickname
Year of Graduation
City
State
Gender

One might want to only include first name and city/state or only nickname. One might want to order by year of graduation (so that one could see who of one's classmates was attending), or by city/state to see if one might want to arrange to drive together).

Also, it would be nice to allow a registrant to include/exclude himself on the public list and to choose which items get displayed.

/carmi

As was suggested, an attendance list would be great. Related would be a very lightweight mechanism to make certain changes, so that one could have a check - in desk that had the list of all registered guests with a check boxes for checked ID, accepted payment, gave badge, (etc.) that did were immediately communicated to the database without having to refresh the entire page (there also needs to be some way to notify other open pages of these changes so that one could not pick up ones materials from one person, then walk over to another person and "check in" again).

/carmi

CiviEvent: name tags for participants, based on address label functionality, but allowing a broader set of fields eg job title, including custom fields.

I think CiviMail is often used for newsletter management. We often include a list of events in an email.  also the ability to see archived newsletters would be useful.  finally, there are a few different opt-in / signup scenarios, and i think they could be enabled at the group level:

1. when user is added to a group they are automatically signed-up to a newsletter subscription

2. when a user is added to a group they are asked to opt-in to a newsletter subscription

3. the group emails / rules / opt-out are managed independantly (at the group level)

 I have some code that i can contribute that may help add events to an email - but that will be a very powerfull feature!  Could also add a calendar!

Add to CiviEvent an explicit ability to have an event participant require approval.  many events are open to people who have not yet registered (anonymous).  They can request event participation (and payment) but we want to make sure they are appropriate for the event.  This would work similar to moderated forums.

hi All,

i think the recurring events will be huge for CiviEvents. It will open up the whole realm of training sessions, ongoing advocacy forums, regular classes. I'm working on a project for BayNVC and this will be perfect, so...

+1 for recurring events.

you can see more possible permutations here: http://forum.civicrm.org/index.php/topic,4648.0.html

thanks!
m

A request for the upcoming redo of price sets in CiviEvents. If we have a single Event there is a maximum allowed number of tickets that can be sold. But when you use price sets you can't really take advantage of this feature fully. As an event limit it can only be used to limit the total number of people allowed to purch tik, but can not differentiate between the diff types of tickets. For example for an upcoming event we have three diff admission types with diff prices and diff max tik sales. Now the price sets can handle the diff prices, but can not restrict the number of each type. What I would like to be able to do is the following

Standing room - $20.00 / 200 people

Seating - $50 / 40 people

VIP (Front row seating) - $100 / 20 people

Now I believe that I can do an event tik sale limit of 260 people, but I can't break that down to the different tik types. Something like that currently has to be tracked manually, and when I hit the 20 VIP seats, disable that type of tik. Otherwise I could have 50 VIP tiks sell and i run out of places to put them. Now while the extra money is nice, my attendees will be rather unhappy. And unhappy attendees don't make good donors.

Thanks

Paul aka MacRonin 

Awsome.

 On civimail, it's been discussed to be able to change the format of the email enveloppe to something like news+uniqueID (the + separator allowing a single mailbox to get all the bounce)

X+

It doesn't seem like it would be too much additional code to enhance the CiviMember proposal from "Batch create" to "Batch create or renew" from search... That would probably save some of us a lot of work!

The spec is looking pretty good. Things are progressing along nicely.

I think CiviCRM can make a lot of improvement in the area of front-end performance. A CiviCRM page generally gets a YSlow score about 20 points lower than a similar Drupal page on the same site (YSlow gives scores betwen 0 and 100).
For those of you unfamiliar with YSlow you can find it here: http://developer.yahoo.com/yslow/

I think a full audit of the front-end would really offer a lot of suggestions for improvements. But here's a few things that I can think up off of the top of my head:

• Take advantage of the host CMS's CSS and JS aggregation features.
• Combine Images into sprites to reduce the number of http requests.
• Avoid the use of inline images for UI widgets (ex. +/- buttons for fieldsets). Use CSS images instead so that images are cached.
• Simplify the html where possible. (ex. fieldsets use separate divs for closed and open fieldsets. Take a look at the Drupal approach which uses only one. While being more semantic, this has the side benefit of making it easier to manipulate CiviCRM's default behavior (ex. I want this fieldset open by default and CiviCRM wants to close it)).

I think there's possibly many more little things that could together offer a big decrease in page-load times.

In CiviMember, one thing I'd like to see enhanced --

For those with organization-based members (membership is attached to the organization, not the individual), CiviMember does a nice job of allowing membership inheritance through relationships (from the org to the indiv). However, it's not easy to do a search for just the "primary" member -- the organization itself, because an actual membership record is created for all of the inherited indivs.

Inheritance is handled through the owner_membership_id field in civicrm_membership, so a search for NULL on that field yields everyone who doesn't have a "parent" and thus is the "primary". I think we just need a field in CiviMember search that allows the user to query by primary member only.