RecurrenceConfirmationPopup reconfiguration should be easy #9378
Labels
bug
Something isn't working
enhancement
Functionality improvement
forum
Issues from forum
high-priority
Urgent to have fixed
large-account
Reported by large customer
resolved
Fixed but not yet released (available in the nightly builds)
Milestone
Forum post
The
recurrenceConfirmationPopup
config in Scheduler mixin Recurring events should be made public. It is used by drag/drop.The
RecurringEventEdit.js
mixin ofEventEdit
should consult that config from itsclient
when creating its own instance in addition to honouring its ownrecurrenceConfirmation
property (That should be renamed torecurrenceConfirmationPopup
, be promoted to be aconfigurable
and made public.:In CalendarDrag,
RecurremceConfirmationPopup
instances leak because one is instantiated on every drag of an occurrence.It needs to create only one, and pull in the
recurrenceConfirmationPopup
property from theclient
Calendar
. Calendar then requires arecurrenceConfirmationPopup
config.SchedulerPro
SchedulerPro
TaskEditorBase.js
hasIt should do the same. It should pull in
this.client.recurrenceConfirmationPopup.initialConfig
to configure the confirmation. As it stands now, it is unreconfigurable. It also leaks instances because a new one is created each time!The text was updated successfully, but these errors were encountered: