repeat dates are not checked for conflicts

Implementing repeat support will require additional code, as Date Repeat doesn't expose repeating dates as nodes.

I'm working on this for one of my clients. Hope to have a patch out until 2010-03-14.

I'm having potentially related problems:

If I have a EventA that is every sunday from 10:00 to 11:00, with the exception of April 4. And, then I added an EventB for sunday april 4 at 10:30, I get a resource conflict and it won't save.

Is this related?

@keith_k: thank you for adding a further test case, so I tested that this 'gap filling' is indeed possible with my patch. I hope I understood your scenario right, please test it again at your site. If it fails, we'll go into the details. ;-)

Please review!

PS: outputting a correct error message makes only sense after applying #590200: Revisions causes wrong conflicts as we need the values of nid, vid and delta from the date_table for that.

This patch is exactly what I need as well! I tried applying the 2.0 patch and, although it applied without issue, the conflict checking still isn't working on repeat events.

**Edit** by the way, I'm using node repeat which may add additional complication since it's actually generating nodes...note that it DOES use the Date Repeat API to create it's functionality, though. So I assumed that any date repeat implementation should also work here...

Thank you for taking the time to test this!

I have no experience with http://drupal.org/project/node_repeat so far. Will only have time to look into it after 2010-05-12, though. From just glancing over the http://drupal.org/project/node_repeat project page it could well be that your suspicion is right.

As far as I got with http://drupal.org/project/resource_conflict and Date Repeat API the date sequence is stored inside ONE node as multiple value field, and as I understood in such a short time with http://drupal.org/project/node_repeat the date sequence is stored across SEVERAL nodes, so maybe my patch considers only the data suitable for the first use case.

Ahh, yes, this makes sense. The date information is indeed stored across multiple nodes with node_repeat (it's actually creating nodes with a sort of 'reference' between them to get them to relate to each other). So, while it may use Date API for it's node creation, the actual creation may not be checked for conflicts.

Unless you can somehow hook into the actual node creation process and check every node being created (no matter the method) I have a feeling that this would need some 'glue code' to function with node_repeat. I will file a follow up support request on the best way to create that code.

Thanks!

Here is an untested reroll of #4 that works with node revisions. Anyone care to test it?

I tired, but the patch failed against current resource_conflict-2.x-dev

drush dl resource_conflict-6.x-2.x-dev
patch -i 641850_date_repeat_9.patch
patching file resource_conflict.module
Hunk #1 succeeded at 28 with fuzz 1.
Hunk #2 succeeded at 331 (offset 6 lines).
Hunk #4 succeeded at 379 (offset 6 lines).
Hunk #5 FAILED at 400.
1 out of 6 hunks FAILED -- saving rejects to file resource_conflict.module.rej

But I applied manually and it seems to work. However I have variable_del('rc_type_'. $type); commented, but there is no watchdog entry.

resource_conflict-2.0-641850.patch in #4 worked like a charm for me.

thanks to raphaelhuefner for sharing this solution with the community!

Thanks for the testing - let's try this gain.

The patch applies nicely to current dev release.

I extended it with a fix for the DATE_DATETIME issue mentioned here #821884: date_is_valid does not sufficiently distinguish between DATE_ISO and DATE_DATETIME this way it also checks for repeating datetime fields.

Further I added and ORDER BY clause this way the most recent conflict comes first.

For resource_conflict-641850-14.patch, I think this line (around line 31)

$overlapping_node_ids = _resource_conflict_overlaps_from_date($start, $end);

needs to be removed.

jromine, you are right - thanks:-)

Any way to get this into head?

Updating the patch.

This patch is working for me with Drupal-6.17.

Here's an update that just clarifies some of the function comments and cleans up a few very minor spacing issues.

If someone tests it successfully, please mark it as RTBC and I'll commit it.

I've tested this patch, and it works fine for me.

:-) The patch applies fine against 6.x-2.x-dev of today. Please commit this.

This patch applied fine for me and it works with either node_repeat 3.x dev version or with just regular date repeat.

Patch works great (6.x-2.x-dev). If someone could merge this patch with #700864: Resource conflict disables itself if a date field is empty and not required. My patch merging skillz just aren't up to it.

Attached is a patch which merges #641850: repeat dates are not checked for conflicts and #700864: Resource conflict disables itself if a date field is empty and not required. The patch was made inside the 6-dev resource_conflict directory so it can be run with "patch < resource_conflict_date_and_disable_bug_fix.patch"

I have tested the patch in #24 and it appears to be working -- for the most part.

I am not using node_repeat, but instead just using date_repeat. Because of this, when there is a conflict with a repeating event, it only lists the first date/time for the node. It should really be listing the individual dates/times that are conflicting (similar to how it would list each node when using node_repeat).

Any ideas?

Closing this due to D6 being EOL and to clean-up the queue. Please feel free to let me know if you think it is relevant to D7 and I'll re-open.