From what I could test from the current version of the plugin, when editing a recurring event, it seems that the recurrence end date (or “until” date) isn't updated when setting the event start date to a later date.
To reproduce:
Create a new event.
Leave everything as set by default in the editor: the start and end date for the event should be the current date (e.g., 2022-10-07 in yyyy-mm-dd format).
Pick a regular recurrence (daily or weekly, for instance), so that the “until” date shows in the form. This date should also be the same as the start and end dates above (i.e., 2022-10-07, following the same example).
Set the start date to a later date (e.g., 2022-10-31).
The “until” date hasn't changed (it is still 2022-10-07).
From what I could read from the code, it seems that this bug comes from the fact that the element ID of the start-date datepicker in the event editor has changed: it is not from_date (as written in the test on line 267 above), but eo-start-date.
A simple fix would be to write eo-start-date instead of from_date in the above test. However, since the role of each datepicker is now accessible using $(element).data('eo-datepicker'), it seems to me that matching this string should provide a more robust test for figuring out if we are currently handling events for a particular datepicker. The exact same test is already performed on line 263 of the same file, in the same function:
https://github.com/stephenharris/Event-Organiser/blob/65c4e3b0f40a601bebf7d5fc2203da02bbb4d7e9/js/event.js#L263
This is therefore the solution I'm proposing in this PR. From what I could test, this fixes the issue.
Another solution would be to use the jQuery selector views.start_date, retrieve the element matching the query, and check that it is the same as this. Something like
if (this === $(views.start_date)[0]) {
...
}
Of course, I'll gladly update my PR if you think this is a better solution!
I hope this will help! :)
In any case, thank you very much!
Hello,
From what I could test from the current version of the plugin, when editing a recurring event, it seems that the recurrence end date (or “until” date) isn't updated when setting the event start date to a later date.
To reproduce:
2022-10-07
inyyyy-mm-dd
format).2022-10-07
, following the same example).2022-10-31
).2022-10-07
).However, one would expect the “until” date to be updated as well, since it now falls earlier than the event start date. This behavior is actually expected, as per the comment on line 268 of
js/event.js
: https://github.com/stephenharris/Event-Organiser/blob/65c4e3b0f40a601bebf7d5fc2203da02bbb4d7e9/js/event.js#L265-L271From what I could read from the code, it seems that this bug comes from the fact that the element ID of the start-date datepicker in the event editor has changed: it is not
from_date
(as written in the test on line 267 above), buteo-start-date
.A simple fix would be to write
eo-start-date
instead offrom_date
in the above test. However, since the role of each datepicker is now accessible using$(element).data('eo-datepicker')
, it seems to me that matching this string should provide a more robust test for figuring out if we are currently handling events for a particular datepicker. The exact same test is already performed on line 263 of the same file, in the same function: https://github.com/stephenharris/Event-Organiser/blob/65c4e3b0f40a601bebf7d5fc2203da02bbb4d7e9/js/event.js#L263This is therefore the solution I'm proposing in this PR. From what I could test, this fixes the issue.
Another solution would be to use the jQuery selector
views.start_date
, retrieve the element matching the query, and check that it is the same asthis
. Something likeOf course, I'll gladly update my PR if you think this is a better solution!
I hope this will help! :) In any case, thank you very much!
Zosterops