FullCalendar library is providing dragging and resizing support for events. FullCalendar View module is also providing this feature.
Smartdate is already providing support for viewing events with FullCalendar #3101524: Provide FullcalendarViewProcessor plugin to support Fullcalendar View
Now Smartdate should also support drag and resizing editing of events in the FullCalendar views plugin.
Trying to provide this with a patch.
Regarding recurring events my current proposal would be that drag and resize editing of recurring events in the FullCalendar view always results in overriding instances and not in changing the rule. This seams to be reasonable, but can be discussed and maybe solved different.
Info: This patch is about 3.x-dev of FullCalendar View
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | interdiff.txt | 1021 bytes | stefan.korn |
| #12 | smart_date-provide_drag_and_resize_editing_support_for_fullcalendar_view-3117690-012.patch | 9.51 KB | stefan.korn |
Comments
Comment #2
mandclu commentedI would agree that changing/dragging a specific instance should not change the rule. I have also opened #3117719: On Instance override, prompt for "only this instance" or "change all from here" to track a possible approach of prompting the user if they want to change only the once instance or all instance from the specified one forward. If that gets implemented then potentially it would ideally be implemented here too, but I wouldn't say it's high priority.
Comment #3
stefan.kornSo this is my first version of the patch. This seams to work out fine for:
#3114128: Adding rrule_index to smart date field schema and #3117745: Make csrftoken protected class member is needed for this to work
I will do some more testing on this (considering this somewhat "alpha" at this stage). But if someone is eager on also doing some testing on this, I am surely curious about any results.
I have not considered yet:
- changing recurring events rule by drag and drop
- external event dropping as featured by FullCalendar, did not look into how this works in general
- using smart date and core date fields in combination (either in one view or different views). In theory this should work, because I am passing to the CalendarEventController from FullCalendar View module if field is not from type smartdate. But I did not test this yet.
Comment #4
mandclu commentedIs there a recommended version of Fullcalendar View to use/test this against?
Comment #5
stefan.kornI just discovered that there is also a small patch necessary for FullCalendar View (against version 3.x-dev). Obviously I had changed that in my setup and forgot about that ...
I just created an issue at FullCalendar #3117745: Make csrftoken protected class member. So this patch is necessary too (I am also amending #3 about that)
Comment #6
stefan.kornComment #7
mandclu commentedThis looks great! Everything appears to work as expected. I checked the error log and everything looks clean, even after editing events.
Is there anything you're still working on with this?
Comment #8
stefan.kornI think it would be good to go. Especially as Mingsong has already accepted #3117745: Make csrftoken protected class member and therefore no patch of FullCalendar View is needed anymore.
I probably will do some more testing and maybe (later) have a look in the things I mentioned in #3 that have not been considered yet.
Comment #9
mandclu commentedOK looking at the code I wanted to change how some of the conditions were handled, to make the code more readable. Also cleaned up some comments to meet Drupal coding standards. Overall it could probably use a few more comments, but as long as we don't see any functional issues (e.g. I haven't broken anything with my changes) I think this is ready to merge. Please test and let me know.
Comment #10
stefan.kornThanks, that code is truly nicer.
There is just one issue that breaks resizing of Allday events.
This is amended patch to fix this and interdiff to your last patch
Comment #11
stefan.kornAhm ... Just currently asking myself why I have put the controller in the smart_date_recur submodule. Think it should be in the smart_date main module ... I will check and see if there is a reason for having it in smart_date_recur submodule.
Comment #12
stefan.kornOkay, there was something weird going on with my git. As I have applied the patch from #9 against origin/8.x-2.x my git put the FullCalendarController.php in the smart_date_recur submodule. Only if I first created an empty Controller directory in the main smart_date module the FullCalendarController was put in the correct directory. Strange behavior from git ...
So now I provide once more the slightly amended patch and the interdiff (against patch from #9). Please completely ignore the patch and interdiff from #10. Sorry for the confusion.
Comment #13
stefan.kornComment #15
mandclu commentedThanks so much for your work on this! It's fantastic to have this functionality available. Merged in, and will likely get out a fresh release to make this available.