UI for entering registration prices

[jfly]

We need to give organizers a UI to enter prices (can those prices change over time?).

[KitClement]

I've seen issues with prices changing over time, so I just thought I'd bring this up.

CUSA doesn't automatically change prices, so when a competitor pays before the price increase, changing a registration can make a large impact. For example, at BASC 5, we had a competitor register for 3x3, Pyra, and Skewb at the low prices (5 + 1 + 1 + 1 = 8). They decided to drop Skewb, and as a result, were not fully paid due to the update (10 + 2 + 2 = 14). Of course, I think people adding events should be charged the new price, but some sort of logic to prevent charging people from dropping events would be good.

[jbmertens]

CubingUSA payment options screenshot is attached.

As a note, I think the payment behavior options are stated pretty clearly on CubingUSA, although perhaps all of the implications aren't. But, if you don't want the behavior Kit mentions, just change the setting :) Registrants are told what happens if they change their registration on the payment confirmation page (not that anyone ever reads such things).

One special thing we did for WC (which probably should've been changed everywhere) was to put this message in more places, notably on the registration page itself as well as the payment confirmation page.

Doing a good job of handling fee changes with a broad choice of settings is somewhat tricky, and fees aren't often changed anyways, which is why CubingUSA has only some basic options. (Implementing some features properly could require keeping a record of all registration fee changes and registration changes, comparing them, etc.).

[KitClement]

I think it could be desirable to charge competitors for adding events but
not dropping events though, and that is not supported by CUSA.

[jbmertens]

Hm, what did you have in mind that is different from this?

Competitors will be charged individual event fees for any added events, but not refunded for dropping events

This doesn't really allow them to "switch" events; is that what you mean? The second option is intended to allow that, but then it behaves differently if you increase all fees. (I think it behaves "correctly", penalizing registrants for changing their registration within the new fee structure.)

Fee changes just lead to all sorts of messes! :) There are a lot of use cases, and I haven't really though through a clean way to handle them all. (Per-event additions and drops (for both fee increases and decreases, in the case of an uncertain organizer...), base fee changes; scheduling automatic changes, etc...)

[KitClement]

The problem is that we have that setting enabled for the case I described
earlier, and it's applying the updated fees to a dropped event. Thus, it's
technically an increase in registration fees for strictly fewer events, no
other changes. I think it would be nice if CCM could remember the old fees
so those could still be applied. Maybe this case doesn't happen all that
often and trying to cover it isn't worth it, but when it does happen, it's
a bit confusing for the competitor when their registration moves from paid
to partially unpaid for dropping events.

On Thu Jan 29 2015 at 1:51:28 PM jbcm627 notifications@github.com wrote:

Hm, what did you have in mind that is different from this?

Competitors will be charged individual event fees for any added events,
but not refunded for dropping events

This doesn't really allow them to "switch" events; is that what you mean?
The second option is intended to allow that, but then it behaves
differently if you increase all fees. (I think it behaves "correctly",
penalizing registrants for changing their registration within the new fee
structure.)

Fee changes just lead to all sorts of messes! :) There are a lot of use
cases, and I haven't really though through a clean way to handle them all.
(Per-event additions and drops (for both fee increases and decreases, in
the case of an uncertain organizer...), base fee changes; scheduling
automatic changes, etc...)

—
Reply to this email directly or view it on GitHub
#40 (comment).

[jfly]

Thanks guys. I agree that it never makes sense to charge someone for dropping an event. Jim, could explain the intended behavior of #2? Has kit found a bug, or is there some miscommunication going on?

[jbmertens]

Well this isn't a bug, just a (non-obvious) consequence of what happens when registration fees change. The option is behaving exactly as stated, rather than trying to be intelligent or nice.

I disagree that this never makes sense - for 'nats at least, this is intentional. Granted, it isn't the nice thing to do, but you are possibly causing us a hassle if we have already printed materials for you, assigned you to heats, or something else. Phrased differently, when you change your registration, you are registering under the new payment scheme, and we are crediting you with the amount you already paid. At least, this was the idea circa 2011ish.

I'm not really a fan of this mindset, but some nats organizers are (or used to be), so I consider it a viable use case. Of course I'm not really up for writing something to handle the additional use cases a "good" solution would entail, so... ;)

[jfly]

I just talked to Jim, and while we haven't figured this all out, I am very opposed to supporting any feature whereby we charge competitors just for dropping events.

[timhabermaas]

James pointed me to this issue on the delegate mailing list, so I try to give some ideas on how this could be (partially) solved. I have only a very limited understanding of the current system, so this might be completely useless.

I think it would be nice if CCM could remember the old fees so those could still be applied.

I think "nice" is an understatement. Registering for an event had a specific price in the past and that fact should never be changed.

Implementing some features properly could require keeping a record of all registration fee changes and registration changes, comparing them, etc.

Yep. That's why I mentioned Event Sourcing in my email. This would probably solve all the problems and you can decide on the behavior of some edge cases after the fact. [1]

One possible solution without going full-event sourcing: You make the prices an append-only collection (no in-place updates, no deletes) [2]:

prices(
  eventId: Id,
  competitionId: Id, // depending on what exactly `eventId` represents, this might not be necessary
  price: Decimal,
  reducedPrice: Decimal,
  validFrom: Nullable(DateTime),
  validTo: Nullable(DateTime)
)

The semantic of validTo is as follows: A record with validTo == null indicates the current active price for that event. Old prices will have the property validTo != null. [3]

The orders collection would look like:

orders(
  priceId: Id,
  registrationId: Id,
  orderedAt: DateTime
)

When creating a new order the priceId always references a price with validTo == null, but this might change in the future. The sum of orders.map(&:price).map(&:price) will always be the same no matter how the organizer changes the price of an event. Removing an event from your registration would mean deleting one of the orders. Creating a new order after prices have been changed will (of course) reference the new price.

As an alternative: You could just duplicate the currently valid prices in the registration collection. This is definitely not as nice since it has all the drawbacks of denormalization.

[1] I encourage everyone to give event sourcing a try at one point. Working with immutable data makes maintaining and reasoning about systems quite nice. Here's a nice explanation of it.
[2] Not sure how well that relational model maps to something like MongoDB. Shouldn't be too much of a hassle, I suppose.
[3] The idea of shoehorning an immutable (fact-based) database into a relational database comes from this blog post: http://www.udidahan.com/2011/10/02/why-you-should-be-using-cqrs-almost-everywhere%E2%80%A6/

[jbmertens]

One more idea from Mike H.: flexible caps on registration prices.

As an example, fees can be $10 base, +$2/event, but no more than $20 (still allowing competitors to register for whatever they like). So registering for 8 events costs $20 rather than $26.

[FatBoyXPC]

While this is a great idea, I will never put a cap on my competitions :-P
On Feb 7, 2015 7:53 PM, "jbcm627" notifications@github.com wrote:

One more idea from Mike H.: flexible caps on registration prices.

As an example, fees can be $10 base, +$2/event, but no more than $20
(still allowing competitors to register for whatever they like). So
registering for 8 events costs $20 rather than $26.

—
Reply to this email directly or view it on GitHub
#40 (comment).

[MikeHughey1]

I know several people really like the idea of having a cap. I've had some people complain (perhaps only a little, but still) because I did not use them in the past. I was considering doing a cap for Indiana, but the fact that CubingUSA didn't support it and I was going to take PayPal payments meant that didn't seem to be an option, so I gave up on it. At least that gives me an excuse for why it's so expensive. :) I do think it should be an option.

In general, I think the more flexibility given on fee options, the better. And I love the idea of event sourcing - I hate losing historic data.