Testing recurring option

[eynimeni]

There is a new feature in bookingoptions that allows to create recurring options (children) of an existing booking option.

When the "Repeat this option" checkbox is activated, new options will be created according to settings in "How many times to repeat" and "How often to repeat". If for example data is set to 3 day and the current bookingoption starts on 1.1., there will be 3 more options starting on 2., 3., 4.1.
Settings of the options should be identical

• behaviour as described and expected

When a "mother" bookingoption is changed, and we click on save, there should be a validation (so not saved immediately) with the question if the changes should be applied to all of the children.

• check if changes are applied (applies to most fields but not all)

• changes in dates are not applied, if dates in children were changed or there are multiple generations of children (delta between mother and all children needs to be consistent)

• parents, children and siblings (with same parentid) are displayed correctly in the recurring options section

Note that recurring option is only available on update of bookingoption, not on initial creation and data is not saved in the database. for the behat test, we need to simulate the submission of the form of the bookingoption update

[semteacher]

@eynimeni I made some manual tests for now:

1. I have created 3 reccuring options with daily interval. Seems all OK
2. I have created again 2 reccuring options in the same parent, as before
   2.1 wiht the following settings:

2.2 and they being shown this way (names being duplicated)

2.3 when I edit parent option it looks like

3. Whem I have tried to edit a title of the parent option:
   3.1 with the following setting

3.2 got this (extra dates appears + numbers on option disappears)

4. I have decrised date in the parent option twice - no cnahges for children (seems OK?).
5. I set date of the parent option equal to the date of 1st child
   5.1. with the following settings

5.2 Dates of child does not changed

6. What of this behavior is expected and what is not?
   6.1 Extra dates in 3.2 looks definitely incorrect.
   6.2 How about disappearing of numbers (not a big deal as for me)?
   6.3 There are no "following" options after the "Apply these changes to all the following bookingoption as well?" statement. Or is it about of all children options? (but those are listed above)

[eynimeni]

@semteacher thank you for your feedback!
we know about the behaviour in title as described in 2. thats ok.
I have made a fix for 3.2.

4 & 5 I don't completely understand. the update of the children dates will only work if none of the children or the parent has changed dates before.
so in the test:

1. create children
2. update date of parent and check "apply these changes to following bookingoptions" -> should be applied
3. update date and do not "apply these changes to following bookingoptions"
4. update date and check "apply these changes to following bookingoptions" -> should NOT be applied

this would be expected behaviour.
equal behaviour if 3: update date of child

[semteacher]

@eynimeni Thank you for above explanation. Have added 2nd test to cover that case. Looks OK.

[semteacher]

I got some (little bit) unexpected finding (known but forgotten:

• current behat failures

• caused by differece in processing of Daylight Savings Time by php prior 8.1.7 and after it.
• so, having initial date 2045 March, 15: 14:20 (UTC, pre-DST),
• (represented in all php as 2045 March, 15: 3:20 PM
• even having timezone forced in behat to Europe/London explicitly,
• when I add 2 options recurring weekly - I reach 29 March 2045
• so it being shown, as 2045 March, 15: 4:20 PM if php >= 8.1.7 and as 2045 March, 15: 2:20 PM if php <= 8.1.7
• same behavor observed if all dates completely within DST interval.
  There are number of references on php web-sites about this, for example
  Since PHP 8.1.7 strtotime translates a date-time with DST/non-DST hour differently based on default timezone php/php-src#9165

Definitely I can easily fix those behat tests:

• not to check time (only dates) in those tests at all (not critical)
• place all dates in non-DST time frame.

But my concern that this behavior could (and probably already) affects different part of our projects (there are already other problems with timezone processing and filters in wb_table)
@georgmaisser , @eynimeni what do you think what we should do with this?
all related phpdocs now contains warnings like:
The Unix timestamp that this function returns does not contain information about time zones. In order to do calculations with date/time information, you should use the more capable DateTimeImmutable.

UPD: in fact, in THIS paticular case - I would expect, than even when creation of recurring new option passed fron pre-DST to DST time period - option time should remain the same?
I mean

• if I recirring option from 2045 March, 15: 14:20 by month
• than I have to expect having 2045 April, 15: 14:20 (and not 2045 April, 15: 15:20) ? @eynimeni, @georgmaisser am I correct ?