Update mwlCalendarHourList.js

[0xDanr]

When the start time of the day view of a calendar does not start at an hour with 0 minutes (i.e. day-view-start="09:15") the calendarDate object passed on the on-timespan-click event for the first hour span has the wrong times. For example in the time span of the first hour (9:15 - 10:00, assuming you are day-view-split="15") you'll get calendarDate objects 9:00, 9:15, 9:30. The correct calendarDate objects should be 9:15, 9:30, 9:45

[mattlewis92]

Thanks for reporting this! Sadly I'm away on holiday atm so won't be able to review it until late next week 😄

[0xDanr]

Hey, I wanted to let you know about an issue I found. I don't consider it a bug but it's something I found that is peculiar that I think people should know. It's possible to reset the vm.events array without causing its watcher in mwlCalendar.js to call the refreshCalendar function, thereby removing the $id property from event objects and throwing exceptions in the ng-repeats of the calendar templates. This happened to me during a server call to reset the vm.events array where I was getting all the exact same events I had before and wasn't checking for deltas. Therefore, I was resetting the vm.events array to a new array with the exact same items as before while making a change of view. The exceptions happened because I was doing a change of view from day to month which made my application trigger a request to my server for events for a whole month, and I was resetting the vm.events array to the new array with the exact same items in the thread where I got the response back from the server because for the month I only had events for the day I was in while in the day view. Therefore, the watcher in mwlCalendar.js thought the vm.events array hadn't changed but it had since the event items did not have the $id property anymore. A quick solution was to empty the vm.events array in the thread that made the request to the server, then set the vm.events array to the new array in the thread where I got the response from the server. That way at the end of the first thread, the watcher would get activated and see that the vm.events array changed, and the watcher would be activated again when I set it back to a new array in the thread where I got the response back from the server.

I think it would be ideal if the watcher could know that the event items lost the $id property and therefore changed or simply just not rely on using the $id property in the ng-repeats but maybe a hashcode made from the fields in each event object.

[mattlewis92]

@dam417 thanks for the detailed explanation, I understand what's going on now. The $id field is required for the ng-repeat, so that drag and drop and resizing of events would work properly. The events array is deep watched but the $id is set as non enumerable which is why the watcher isn't picking it up. I think it'll be enough to just make it enumerable so the watcher will detect when it's been removed and re-add it. Tracking this in a separate issue at #457