No announcement yet.

Issue with date picker for vacation notice

  • Filter
  • Time
  • Show
Clear All
new posts

  • Issue with date picker for vacation notice


    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})
    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.


  • #2
    Reported internally as OXUIB-764


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


      • #4
        I randomly figured out this has been fixed now: &

        (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 )