Issue with date picker for vacation notice

[vbrillau]

Hi,

One of our users found a bug in the date picker for the vacation notice: in specific circumstances (more on this below), defining a new vacation notice for "today" results in an error: "The end date must be after the start date."

To reproduce (reproduced on both Firefox and Chrome on desktops):

• Make sure that the vacation notice is disabled and its data is empty
  • In particular, make sure to save with `Send vacation notice during this time only` (activateTimeFrame) not selected (i.e false)
• Open the vacation notice view
• Enable the vacation notice (top left)
• Enable `Send vacation notice during this time only` (tick box)
• Do not touch the `Start` date
• Set the `End` date to today through the date picker

These steps should make the error appear. There is an easy work-around: Click on the `Start` date and (re)set it to today.

Taking a look at the code (as moment is made global, we can test it in the console through window.moment):

• getDefaultRange from the vacation model is using `+moment()` for the start date
  • This is creating a datetime of 'now'
  • Testing in the console:

    > window.moment()._d
    Date Mon Mar 01 2021 12:24:24 GMT+0100 (Central European Standard Time)

• getDate from the date mini-view is using `moment.utc(...)`, setting up only the year/month/day
  • Testing in the console (note: month are 0-11, not 1-12):

    > window.moment.utc({"year": 2021, "month": 2, "day": 1})._d
    Date Mon Mar 01 2021 01:00:00 GMT+0100 (Central European Standard Time)

• Comparing both gives the expected but buggy result (equivalent to `this.get('dateFrom') > this.get('dateUntil')` after the steps mentioned above:

  > window.moment() > window.moment.utc({"year": 2021, "month": 2, "day": 1})
  true

The problem is that the default start date are not set to midnight but to the current time.
The work-around mentioned simply re-defines the start date (without any change in the graphical representation) though getDate (AFAIU), thus reset the date to midnight.

Cheers,
Vincent

[Wolfgang Rosenauer]

Reported internally as OXUIB-764

[vbrillau]

Thanks! Let me know if my analysis was wrong/if you can't reproduce or if you need more explanation/help

[vbrillau]

I randomly figured out this has been fixed now: https://github.com/open-xchange/apps...ee202a98f2622e & https://gitlab.open-xchange.com/fron...e_requests/750
Thanks!

(I understand it will only be part of 7.10.6, so I won't be able to validate that it works before then, but thanks for working on it nevertheless )