Posted by deviantintegral on February 1, 2010 at 1:55am
6 followers
| Project: | Resource Conflict |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
If you create a content type with an optional date field, when you leave it blank the content type is disabled for resource checking. For more info, see:
http://drupal.org/node/623332#comment-2509572
and
Comments
#1
First, thank you for this great and very flexible module for booking.
I have very similar experience as described here: http://drupal.org/node/623332#comment-2509572, but I don't understand what's the solution, if this (referenced) issue was changed to "fixed". My problem is related neither to CAPTCHA, nor the blank date field. The problem appears periodically without clear reason and makes the module almost unusable.
I hope it will be fixed soon. Thank you in advance for help.
#2
Any idea? The module is almost unusable for this reason. Thank you in advance for help.
#3
I haven't had much time to do work on this module lately. As far as I know, this is only an issue if the date field is not required. Are you having the problem when it is required? Have you tried updating to the latest -dev release on a test site to see if it's fixed?
#4
"If the date field is not required": I don't understand it: I think that if it is not required, the activation of resource conflict is not possible at all (so, it cannot be deactivated, as it has been never active). Maybe I missunderstood something?
But I'll try the latest dev... thanks.
#5
subscribing,
my date field is required. it is also required that the user enter a to date. I agree this bug sends the module from my awesome list to my unusable list.
#6
This happened to me the other day. A user created a booking with repeatiing dates and it just disabled the checking mechanism kicking out all the bookings that were in the way.
Basically a repeating date situation was created by this user: 28th May 2010 till 24th of December 2010, every week 10:00 to 11:00 no exceptions. (I suspect he tried to save and then added the 24th to have it end at some point)
Resource-Conflict got disabled (watchdog says so) and two dates (4th June and 18th of June) were ignored.
One note: The actual watchdog message is missing it is just an entry like this:rsrc conflict 27.05.2010 - 15:22
#7
Ah lol I think I found it: If you do not set a "Until:" date it happens! Lets say you forget to set it: A form error will be set, but watchdog also goes off!
#8
@Niels Hackius: do you mean "to date", or something other? When setting the CCK field, or when posting the node? I think I have this problem even if everything is filled in OK.
#9
Field type is: "Datetime" w/ all date modules (date_repeat etc.) enabled.
I attached a screenshot w/ the field in question.
Obviously the field is required, but once form_validate runs and returns the form error resource_conflict already disabled itself, because it has detected a "non"-required datetime-field.
#10
I think this should fix it, at least for date-repeat fields? The array is accessed incorrectly, you only notice this error however if form_validate fails, because only then $op='validate' is run.
#11
#9 Thank you very much for explanation, but I don't use date repeat. So should I enable it and apply the patch? But then, my users will have additional field in the form, which is redundant...
#12
Actually it does not matter if you use date repeat. It should be enough if you leave one required field empty and try to save it. Once hook validate runs (and fails) resource_conflict should disable itself - its a typo in my opinion.
#13
The "to" date is always required to enable resource conflict for a content type. So it seems like what's noted in #12 is more likely "by design". If you initially create it as required, and then go and make it not required, RC *should* disable itself.
If there is an issue with date repeat, let's try and get a reproducible case down for it.
#14
I experienced that RC disables itself even if I didn't change the setting and "to date" was always required. The only "solution" for me was to comment line 36 in the resource_conflict.module, according to http://drupal.org/node/623332#comment-2518430. But I would like to run my site without this hack. Unfortenately, I am not able to test -dev version now, because it is on production site... and I have no idea, how to estimate, that everything works (or not), because the "disabling behavior" was totally unpredictable for me. I would need at least an idea, how to test it reliably.
#15
Sorry for getting back this late. deviantintegral is correct my debugging was a little insufficient, so disregard the patch above.
But here is my test case now:
Setup
I am using a simple content type derived off the "page" content-type with a Node reference and a Datetime field.
The Datetime field is set to be Required and also requires a To-Date, the repeat display is expanded.
I use Firebug for debugging (http://drupal.org/project/drupalforfirebug),
so I inserted this after line 27
<?phpfirep( $node->{$date_field},'field');
firep( $node->{$date_field}[0]['value'],'proposed start time');
firep($node->{$date_field}['value'],'actual start time');
?>
A little further down after line 39(originally line 36, after _resource_conflict_disable($type);)
In inserted
<?phpfirep('disabling');
?>
Test case 1
The problem can now be seen in the console: As a result Resource-Conflict is disabled, because the field is empty.
It is insufficient to check if the field is empty. It must also be checked if the field is actually required.
Test case 2
The problem can now be seen in the console: 'Proposed start time' stays empty while 'actual start time' provides the time it should be providing.
As a result Resource-Conflict is disabled.
This is a strange behavior of the date-module - maybe a legacy problem of them?
Thank you for the attention and sorry for the bogus patch.
#16
This is an awesome report. I second it. :) Same probs here. Disabling-the-disable works, but it's not ideal...
#17
Here's a patch which tests whether the date field is no longer required, before disabling resource conflict checking.