handle drag and drop: creating events, rescheduling events

+1 subscribe

+1 subscribe as well, although I don't know if this feature could be made in the first release; it would require a bit of back-end work to get it going. Would make Drupal + Calendar much more usable, though—dare I say, a killer feature...

The tricky bit is finding a way to define which users can use the drag'n'drop and which one can just view on a per-view basis.

But yes, this would be an awesome feature.

I'm thinking you could check perms - if the user has permission to edit the node and the date field, then drag/drop will 'work'. If not, they either can't 'pick it up', or upon dropping it 'flies' back to the original spot and gives an insufficient permission message. Not that I'm saying doing all of this is trivial - but I think it's solid permission logic.

A problem are also -not yet implemented- repeating events.
How should they be moved with drag and drop?

subscribe - This is actually the main feature that I and a number of others locally were initially interested in. Love the way it's shaping up.

[edit: I changed the title of this feature request to be more descriptive, but please let me know if I actually hijacked a request for http://arshaw.com/fullcalendar/docs/dropping/, which appears to be different entirely! I am referring specifically to http://arshaw.com/js/fullcalendar/examples/selectable.html ]

Agreed w/ greggles, new title is not at all what I'm after.

+1!

I'm working on this, will have a working patch tomorrow. I also added the ability for multiple datetime values on a single node.

@jwhat, do you think you could open a separate issue for the multiple values per node feature? I could REALLY use that, and if you have that finished I can test your patch.

Sorry, separating the changes for the drag/resize features vs. the multiple values per node would be a significant amount of work.

I kept going back and forth trying to decide if I should patch HEAD or DRUPAL-6--1. Head had some changes that I haven't seen yet, so I went with DRUPAL-6--1. This required updating the 2 views-plugin files to match the currently available version of 6.x-1.2-beta2. Please let me know if there was a better way to do this.

The attached patch solves the following:
1. Ability to drag/drop or resize events, saves the new value and displays a status message to the user.
2. Only allows updating the fullcalendar events if the user has proper access.
3. Ability to display multiple event times for a single node.

Please let me know what you think. I plan to help out with this module as much as possible.

I've been patching everything against HEAD, but you're right, it is a confusing situation.

I have five patches that need review, all of which are against HEAD, none of which conflict with each other. Your patch will break all of them, or they'll break yours. But I can't really test yours now because I need those for the two projects I'm using fullcalendar for.

#932854: Support datestamp
#962474: Add more options to the views interface
#910546: Support for weekMode
#910510: Add support for event class / assigning colors to events
#906232: All day events

What we really need right now is some input from the maintainer.

+++ views_plugin_style_fullcalendar.inc	7 Nov 2010 14:58:55 -0000
@@ -1,17 +1,20 @@
-    $options['url_colorbox'] = array('default' => FALSE);
+    $options['fullcalendar_url_colorbox'] = array('default' => FALSE);
+    $options['fullcalendar_header_left'] = array('default' => 'today prev,next');
+    $options['fullcalendar_header_center'] = array('default' => 'title');
+    $options['fullcalendar_header_right'] = array('default' => 'month agendaWeek agendaDay');

This is a change made between versions, not by you. There are a bunch of these, and it makes it impossible to apply or review the patch. Do you mind rerolling against HEAD?

Also, I understand what you mean about not splitting the patch in two, don't worry about that.

Powered by Dreditor.

I hear ya. I can try to reroll the patch against HEAD tonight or tomorrow, but this will be a bit of work since I'll probably need to rework some of the changes that were introduced after beta2 was released.

If you feel like doing so, you could check out the current beta2 version and apply the patch to that, just to see the functionality.

I rolled this patch against HEAD. I have 2 new files; don't know how to include them in the patch so I'll add them here as separate files.

Awesome, I hope to have time for this tomorrow.

I've try to apply the patch but don't know why some part aren't patched. Can someone put a patched release here?

Thanks

I'm not sure what you mean by 'some parts aren't patched', can you please elaborate? This patch needs to be applied to HEAD.

Thanks, jwhat - Looking forward to testing out your patch!

After all of the recent commits, this is broken.

Also, for adding new files, read up on fakeadd.

To clarify, I meant the patch was broken. None of the functionality should be affected by the other changes.

Also, keep rolling against HEAD, ablondeau's going to get the version number thing resolved soon.

What i try to say by "some part aren't patched" is that fullcalendar.info,views-view-fullcalendar.tpl.php and views-view-node-fullcalendar.tpl.php files failed when I used the patch.

My change makes a big modification to the structure of the code, which is required for handling multiple values since it requires looping over the CCK fields instead of accessing it directly. And more values need to be passed through to the tpl.php files so that the calendar is aware which one of those multiple values is actually being dropped/resized.

I'm concerned that I'll re-roll my patch again but then there will be a fair amount of more changes submitted and this will continue to occur. Suggestions?

I promise to not write any more patches until I review and work to get yours committed. How's that?

I added #971034: Add Option To Load Events Via Ajax to get everyone's feedback on ways to make sure that changes implemented with the drag and drop support work here can mix well with adding ajax support.

Thanks guys, I should have some free time tonight to do this.

Subscribe. This might be a good replacement for the calendar view that comes with the cod_support project.

This is still on my radar. Converting my patch to work with the latest changes has proven more work than anticipated, but I will get this done shortly.

Ok here we go! Thanks for the tip about fakeadd; worked perfectly.

Initial code review looks okay, but it was just a glance, mostly for the ui and basic functions. I'll try installing this on one of my sites in the next few days... and by then, this patch might already be in the module!

Assigning to myself for review, hopefully tonight.

For anyone else testing this, it requires jquery_ui. Probably a reasonable module to have a dependency on. :)

Just trying it out, it works great until you try to drag it to another day. I'm going to look through the code and see if I can figure out why.

There are a ton of things going on in this patch, most of which is some crazy awesome jQuery.

But you snuck whitespace changes in here! Sure, trailing whitespace and tabs instead of tabs are bad, but this is REALLY not the patch to do that in. Even things like fixing implementation of hook_views_api() just distracts from the real changes. CVS is really stupid about whitespace, and it can be really hard to tell what's changing and what's just being indented. So here's a git patch, excluding all whitespace changes.

Also, I'm confused about fullcalendar_update in fullcalendar.update.inc. What's with the separate file? And it doesn't look like hook_update with the extra parameter, maybe you should rename it?

Okay, can I get a play-by-play of some of the changes here? The jQuery parts are honestly the most straightforward part. The changes to the date/timezone handling are really throwing me for a loop.

Dragging an event to another date is working correctly for me. The fullcalcendar.update.inc does not contain a hook_update. This file is called via ajax when you drop/resize an event. That's how the new data is saved. Take a look at fullcalendar_menu() to see its calling that file.

I use Zend Studio and find it very straightforward to be able to apply the patch and visually see which files were effected and the exact lines that changed are highlighted until I commit to my own SVN. When I save a file it deletes erroneous whitespace automatically.

Scrolling through fullcalendar.module, I see the following big changes:
- Adding a new, custom (and by custom I mean not packaged with the fullcalendar library) CSS file.
- Adding some jQuery UI files; required for dragging, dropping, resizing and then 1 more for highlighting.
- Adding a permission named 'update any fullcalendar event' so that you can display this calendar to the public but restrict them from editing the events.
- Adding a hook_menu() which contains 1 item: an ajax callback to save the drop/resize event data.
- Setting required $vars that are passed to the tpl.php files.
- One of those $vars is 'data', which contains an array, keyed with an index; this is how we can now have multiple datetime values from 1 CCK field.

Let me know if you have any more specific questions that I can help to clarify.

Make sure you clear your menu cache first, since there was a hook_menu() change, otherwise drag/resize will result in a 404 on the ajax side.

I completely forgot that you were adding multiple datetime values per CCK field, that explains all of the major changes I was confused about. Hot damn this is a killer patch.

I still can't drag an event to another day. If I drag a Tuesday 1-2pm event to Wednesday 3-4pm, the event saves as Tuesday 3-4pm, and then opens in a new tab. Maybe its this MacBook Pro magic trackpad? I'll try it with a real mouse later.

Eek! I forgot all about the Week and Day view. I just did some quick testing and drag/drop is working for me, albiet there is definitely some work that needs to be done. Here's a screencast of my test: http://screencast.com/t/OYqHDQH5D8d

There's a good chance that this depends on either jQuery UI 1.7 or jQuery 1.3, will report back later.

Yup, I was right. This does depend on jQuery UI 1.7 and jQuery 1.3. But I think that is a reasonable price to pay. ablondeau, any thoughts?

Perhaps drag and drop of repeating events is a separate issue but doing it the way iCal does it - only move the dragged instance (i.e. not all repeats) - is entirely possible using the exception and additional date features of the repeat date module.

The pseudo code would be something like:

if event is repeating
  if event instance date is already an additional date
    change the additional date
  else
    add current instance date as an exception date
    add new date as an additional date

Ideally, we would replicate the entire way Google Calendar works. For example, when you drop an event you get a prompt that asks if you want to move all instances or just this instance. But we should have a new issue for that.

Here's a reroll, partially due to #980180: Extra trailing comma breaks Fullcalendar in IE 7 & IE 6 [BROKEN AGAIN], partially to consolidate. I don't think we need fullcalendar.update.inc as a separate file, and we'll have to revisit how to handle the CSS in #980886: Require Libraries API, so I don't want to add fullcalendar.custom.css yet either.

I also removed some of the whitespace cleanup, because it just makes the patch harder to read. That can be taken care of in #984438: Coding style clean-up.

If everyone can give this one more test, I think we can get this committed.

Just applied the patch, and everything except the .info file applied correctly. Here's the patch error message:

patching file fullcalendar.info
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file fullcalendar.info.rej

Testing now, and will report back with experience/results.

[Edit: Updated jQuery UI and added in jQuery Update to my site, and this patch makes FullCalendar so much more full of win that I can't begin to describe how awesome it is. Even if you just used fullcalendar for your admins, and then the Calendar module for public calendar display (if you're worried about people without JS enabled, etc.), this is awesome.]

I would mark RTBC, but I haven't fully tested all the different views, and different roles/permissions-based editing.

Besides the hunk failing, nothing is wrong at all. This is an awesome patch, and you just need to make sure people upgrade jQuery UI and add jQuery Update to their sites—make sure you include links for how to do that...

Basically, something like this:

This version of FullCalendar requires both jQuery Update (the 6.x-2.x branch or later) AND version 1.7 of jQuery UI - instructions for installing each can be found in their respective README.txt files.

I agree that this is RTBC, but I'd like jwhat to approve the changes I made before this goes in.

This patch applies cleanly for me. Awaiting jwhat's approval.

I truly think that this module will make Drupal a viable solution for calendaring for a lot of my use cases. I formerly recommended people stick with Google Calendar embeds, but this module makes the UX so much better... wow.

The problem with adding custom CSS to fullcalendar.css is that this is a 3rd party file. When we get around to using the Library API module, this will be broken, which is why I originally created a new, custom CSS file for this module.

The patch in #50 would not apply correctly for me in the file views-view-fullcalendar.tpl.php, so I copied the changes in manually. But I'm noticing a problem when dropping events on the month display that it's incorrectly changing the time.

I'll need a few hours to dig around in this tomorrow.

If you look at the spot where I added your custom CSS, there was already a "custom for drupal" section. We'll cross that bridge when we come to it.

Not sure what the issue is with your patch. Running cvs update -dPCr DRUPAL-6--1 before patch -p0 < fullcalendar-906112-50.patch works. Also, it applies cleanly to the CVS directory I use to commit, which is all that matters :)

Oddly, I just found that repeating events are not handled gracefully... see the attached screenshot.

Someone marked #918144: Support Repeating events as a duplicate - but perhaps that issue should be reopened and this issue should be finished off?

I reopened #918144: Support Repeating events, let's keep this issue within some sort of scope.
Who wants to mark this RTBC?

I do!

http://drupal.org/cvs?commit=457858

This module is now one step closer to being absolutely killer.

Follow up: I think some of the array indices are misnamed for All Day support.
Can someone test this out?

While working on this came across some other issues, moving over to #992812: Date field discovery code fails on edge cases.

I installed the latest dev version of the module and I ran into a couple of issues:

1. Dragging and Dropping a node on the calendar causes the page to redirect to the node full view. I just expected the nodes position within the calendar to be changed.

2. Dragging a node to a new date does not seem to update the node's date field.

3. Dragging a node does not seem to snap into place on the destination. I can position the node anywhere within the calendars column.

Can someone let me know if this is expected behavior, or if I have installed the module properly.

Thanks.

Please be sure that you are running jQuery 1.3.2, jQuery UI 1.7.3, and Date 6.x-2.x-dev. I need to put that on the project page...

Also, please open a new issue if you find any of these problems after you've updated jQuery. (I've also noticed the first issue in certain browsers, but I need to do more testing to make sure it's not simply a configuration error).