Processing all day events via drag and drop

Created on 14 May 2021, over 3 years ago
Updated 17 June 2024, 6 months ago

Problem/Motivation

Within Smart Date we need to process date and time changes from drag and drop events in the Fullcalendar View. In the process, we need to distinguish between all day events and zero duration events, which is currently difficult.

In our FullcalendarViewProcessorBase implementation we set any events that Smart Date consider to be all day to have an "end" value one day after the start, and we set the "allDay" value to true.

In our controller that processes the request at the end of a drag-and-drop event, the request has identical start and end values for these all day events, and the allDay property is not passed.

Proposed resolution

Probably the easiest would be if the allDay property could be included in the request if set, but open to suggestions on other ways to handle this, especially if they could be supported by the current version of Fullcalendar View.

πŸ› Bug report
Status

Fixed

Version

5.0

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada mandclu

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¦πŸ‡ΊAustralia mingsong πŸ‡¦πŸ‡Ί

    This module is under 'Bug fixing only' status.

    So this new feature won't be delivered.

    Sorry.

  • Status changed to Active over 1 year ago
  • πŸ‡¨πŸ‡¦Canada chrisck Vancouver, BC πŸ‡¨πŸ‡¦

    Hi @Mingsong there is a bug with the event dragging as previously reported by @mandclu. The bug is in the eventDrop callback function in fullcalendar_view/js/fullcalendar_view.js on line 221:

     // Event drop call back function.
      function eventDrop(info) {
        const end = info.event.end;
        const start = info.event.start;
        let strEnd = '';
        let strStart = '';
        let viewIndex = parseInt(this.el.getAttribute("calendar-view-index"));
        let viewSettings = drupalSettings.fullCalendarView[viewIndex];
        const formatSettings = {
            month: '2-digit',
            year: 'numeric',
            day: '2-digit',
            hour: '2-digit',
            minute: '2-digit',
            second: '2-digit',
            timeZone: 'UTC',
            locale: 'sv-SE'
          };
        // define the end date string in 'YYYY-MM-DD' format.
        if (end) {
          // The end date of an all-day event is exclusive.
          // For example, the end of 2018-09-03
          // will appear to 2018-09-02 in the calendar.
          // So we need one day subtract
          // to ensure the day stored in Drupal
          // is the same as when it appears in
          // the calendar.
          if (end.getHours() == 0 && end.getMinutes() == 0 && end.getSeconds() == 0) {
            end.setDate(end.getDate() - 1);
          }
          // String of the end date.
          strEnd = FullCalendar.formatDate(end, formatSettings);
        }

    I've read through your comments and I understand why we need to subtract one day from the end date, however the following if() statement isn't triggering. So I printed the end date value to an alert and found the issue:

        // define the end date string in 'YYYY-MM-DD' format.
        if (end) {
          // The end date of an all-day event is exclusive.
          // For example, the end of 2018-09-03
          // will appear to 2018-09-02 in the calendar.
          // So we need one day subtract
          // to ensure the day stored in Drupal
          // is the same as when it appears in
          // the calendar.
          alert(end);
          if (end.getHours() == 0 && end.getMinutes() == 0 && end.getSeconds() == 0) {
            end.setDate(end.getDate() - 1);
          }

    The end date alert is showing as:

    17:00:00 GMT-0700 (Pacific Daylight Time)

    This is why the if() statement isn't getting triggered, because the hours don't match up. So I updated the if() statement and the end date is now getting subtracted by one day as originally intended.

    if (end.getHours() == 17 && end.getMinutes() == 0 && end.getSeconds() == 0) {

    I'm not sure if this is the ideal solution, but definitely highlights some work needed here. I'm not sure where the 17:00:00 GMT is coming from, is this just a default value if the date value is null?

    Lastly, the same issue is present in the eventResize() callback on line 84.

  • πŸ‡¨πŸ‡¦Canada chrisck Vancouver, BC πŸ‡¨πŸ‡¦

    I've just tested this issue with FCV and Drupal core's date range field type and the issue still exists.

    Steps to reproduce issue:

    1. Create Event content type with date range field type, with field settings Date Only.
    2. Create FullCalendar view with date range field. In the Format: Full Calendar Display, settings select Start Date field and End Date field to be the same date range field (be sure when adding the field, select the first option and not the one that says [fieldname] - Duration, [fieldname] - End etc.)
    3. Create Event with a date only date range.
    4. On the FullCalendar view, drag and drop the event. Refresh the page. The event is saved as one day longer than intended.
  • πŸ‡¦πŸ‡ΊAustralia mingsong πŸ‡¦πŸ‡Ί

    The 17:00 should be coming from the jet lag, that saying it depends on what Timezone the server is in and the client browser is set.
    We can’t simply use the specific time difference as the indicator, in your case is β€œ17:00:00”. As a contribute module, it should work for all Timezone.

  • πŸ‡¨πŸ‡¦Canada chrisck Vancouver, BC πŸ‡¨πŸ‡¦

    There seems to be a mix up of the date functions used getHours(), getMinutes(), getSeconds() with local and UTC time.

    The if() statement is not getting triggered because end constant is not 00:00:00 in local time. It is 00:00:00 in UTC time. I'm uploading a patch that takes this into account, which I've tested to be working in my setup.

  • Status changed to Needs review over 1 year ago
  • πŸ‡¨πŸ‡¦Canada chrisck Vancouver, BC πŸ‡¨πŸ‡¦
  • πŸ‡¦πŸ‡ΊAustralia mingsong πŸ‡¦πŸ‡Ί

    Sounds reasonable move.
    Let's see what feedback on the patch from others.

  • This patch fixed the bug for me. I think it would be a very good idea to approve this patch because without it the wrong date is set when you drag and drop or move the end date on the calendar. This means that without the patch every time the event is dragged to a new start date it adds a day to the end of the event.

  • Status changed to RTBC 6 months ago
  • πŸ‡ΊπŸ‡ΈUnited States erutan

    The patch in comment #7 has been working great for months across a few different calendars built.

    • 7651f406 committed on 5.x
      Issue #3213979 by chrisck, mandclu, Mingsong, Jeff-DavRF, erutan:...
  • Status changed to Fixed 6 months ago
  • πŸ‡¦πŸ‡ΊAustralia mingsong πŸ‡¦πŸ‡Ί

    Thanks everyone.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024