Hi Rob,

About the sales begin and end dates changing on the recurrence, I think in many situations this is natural. For example if there is a friday night concert every week and ticket sales are supposed to go on sale on monday each week, then it needs to adjust as it does now and the total seats needs to be per event as it is now.

For the course or class example you describe I think what is needed is an option where the registration is for all the occurences of the event at once. Like Register for this 6 week course $200 covers all 6 weeks and the ticket should grant access to all 6 and then the total seats would be for the whole course. Say you have a classroom size of 40 then total seats for the whole course is 40.

Does that make sense? We could add a checkbox in the registration settings for "Single Registration for all repeats" or something like that.

Then if this box is checked we would also use the same sales begin and end dates across events instead of adjusting it for repeats.

I'm also thinking I need to prevent creating recurrence for events that span more than one day. Right now its weird and unexpected things could happen if you make say a 7 day event and then set the repeat to something that doesn't make sense like every mon-wed-fri.

Thoughts?

Best,

Joe

Man, sounds like fun, I used to ski a lot in my youth but haven't in years since moving to the south.

Well the button is what tests the validation and unlocks the other buttons, it indicates the user is confirming the customer information as correct. It would take a good deal of client side javascript trickery to automatically enable the button by detecting the form is filled in. it would be very difficult to implement without the button.

I did implement the pre-populating it from the most recent order, so on subsequent orders the form is pre-filled in but I still think especially with it pre-filled from a previous order the customer should confirm it. Maybe changing the button text to "Confirm Customer Info" would improve the perception of it.

Note also that if the customer is going to pay by PayPal or Google they don't have to fill out the customer info, those buttons are enabled and we get back the customer info directly from PayPal or google. If accepting direct credit card payments on the site through Authorize.NET or PayPal Direct the user must fill out the customer info. To use PayPal or google it is sufficient if the user is signed into the site so we know which site user to hook the order to when it comes back.

Best,

Joe

Hi Rob,

Again, big thanks for your very helpful testing and feedback.

1. Fixed

2 and 3 - Yes each event is supposed to be listed. Its still events we are publishing though I am trying to make it flexible to work well enough with concepts like a course or class, the events just know they are events they don't know that they are part of a course or class. I've removed the event description from list view and I've added a List View Excerpt that does allow putting information that will show on the list view. It doesn't limit how much you can put there but by being separate from the main description it gives the ability to put a more brief description on the list view.

There is currently not a built in spelling checker, but FCKeditor just released a new beta version which includes a spell checker. I will be integrating this new version into the next release of mojoPortal.

4. Fixed

Another updated build with these fixes has been deployed to the demo site.

Best,

Joe