Event instance threshold count warning doesn't display

Confirmed still occurs on 3.x.

So it turns out that this is working as designed, but what it actually does is far more limited than what it sounds like it does (and arguably what it should do).

How it works now

The warning as currently designed only applies to the Consecutive Event recur type. If you try to create a consecutive event that will yield more instances than the configured threshold, a warning message appears inside the Consecutive Event field widget saying "Saving this series will create up to # event instances. This could result in memory exhaustion or site instability." Likewise, if you edit an existing consecutive event series and try to change the schedule to more than the threshold, the same warning appears on the "Confirm Date Changes" screen. If the "prevent save" option is enabled, attempting to create/edit a consecutive event with a schedule that exceeds the threshold will raise a form error on the Consecutive Event field and prevent the save.

Problems with the current approach

1. While Consecutive Event is, by its nature, the recur type most likely to generate a large number of events if not carefully configured, it's certainly not the only type that could do so. Creating a Daily series for an entire year, for example, would easily exceed the default threshold.
2. The series settings form doesn't indicate that these options only apply to Consecutive, so it confusingly looks like it's not working at all when the threshold is exceeded with another recur type.
3. The warning message that pops up inside the Consecutive Event field widget is wrapped in <span class="form-item--error-message">, which on the default admin theme doesn't get styled as a warning; it just appears as plain text. It's also awkwardly positioned between the Event Duration and Event Buffer fields, so it's possible to scroll it off the screen while still changing subfields that would affect it. That all makes it easy to miss.
4. The in-widget warning only appears as a result of an AJAX refresh when you change a subfield. That refresh isn't instantaneous, so it's possible to scroll past it before it pops in, and having it trigger on every field change somewhat slows down form entry for Consecutive.
5. On create, the confirmation screen doesn't appear, so if you missed the warning in the widget and the "prevent save" option is off, there's no "are you sure?" confirmation before it proceeds with creation.

Recommended solution

• Change the threshold to apply to all recur types.
• Style the AJAX message as a highly visible warning, and position it at the bottom of the widget so you can't help but scroll past it on the way to the save button.
• Provide an option to disable the AJAX warning, for those of us with users who prefer faster data entry.
• When the "prevent save" option is off, force a confirmation screen before saving in excess of the threshold, whether creating a new series or editing an existing one.

The changes in #3605486: Add constraint validator to prevent invalid recurrence patterns may make some of this a bit easier to implement, so it's probably worth waiting for that fix to land before starting on this.

Amending the plan a little: The AJAX warning that currently appears inside the Consecutive field widget is problematic because it doesn't take into account the excluded dates range or the pre_create alter hook, so it's not necessarily accurate to what will actually be generated. I also find it kind of annoying that it starts popping up before you're done filling in the schedule. Fixing that and making it work with all of the widgets would be a little complicated, and I don't think I like the impact on performance.

I think the better approach would be to lose the AJAX warning and just rely on the confirmation screen to make the user aware that they're exceeding the recommended threshold. That's easier to implement, it works consistently for all recur types whether creating or editing, you can't scroll past it, and it removes the lag from all the AJAX calls.

Fix is in progress, but depends on #3460881: Error when trying to create event series where config Event Series Time Intervals = 0, so working on getting that wrapped up first.

If you already have a series that exceeds the threshold, then enable the prevent save option, resaving that series without changing the date scheduling should not trigger the constraint violation. It should only trigger if the instances will be recreated.

This passes testing for the following scenarios (all with threshold warning enabled):

• New event with instances > threshold, prevent saving off
• Existing event with instances > threshold, no changes, prevent saving off
• Existing event with instances > threshold, changed to instances < threshold, prevent saving off
• Existing event with instances < threshold, changed to instances > threshold, prevent saving off
• Existing event with instances > threshold, no changes, prevent saving on
• Existing event with instances > threshold, dates changed, prevent saving on
• Existing event with instances > threshold, changed to instances < threshold, prevent saving on
• New event with instances > threshold, prevent saving on

Thanks for the patch!