This sort of intertwines with the many other date handling bugs, but as I wasn't sure which one to place this under, here goes:

I can _always_ reproduce the following behaviours:
-Upon node save, error message "The Dates Are Invalid"
-Comment_driven of any field sets date field(s) to null in node data and comment_driven diff table shows original value >> today

With the following configuration:
-Turn comment_driven on for node type
-In comment_driven for node type, enable driven properties and enable comment_driven date field(s)
-In edition_hidden for node type, enable driven properties and hide date fields in node edition

Date fields can be any widget (text, popup, etc)

Please let me know if more information is required!

Comments

obrienmd’s picture

obrienmd commented

Did some more testing today. Turning off all edition_hidden properties solves the "The Dates Are Invalid" problems, but not the date to null issue. Arhak, would love the opportunity to chat with you about this live while I'm testing... Not sure how best to present the data from inspections, etc here. Let me know how I can help!

obrienmd’s picture

obrienmd commented
Title: Date mishandling » Using comment_driven programmatically sets date fields to null
Project: Driven API » Comment driven

OK, changed the description as I'm not to worried currently about the NEP thing - using comment_driven programatically as shown below sets all comment_driven enabled date fields to null (although the diff report shows them set to today) - regardless of if those date fields are specified in the variable passed to comment_driven_save...

$comment['comment'] = 'testing';
$comment['uid'] = 1;
$comment['nid'] = 10;
$node['field_equipmentlastusagecount'][0]['value'] = 150;
$node['field_equipmentlastusagerecorded'][0]['value'] = $node->field_daily_report_date[0]['value']; //a valid date value
comment_driven_save($node, $comment, $errors)

The node type in question has 2 date fields comment_driven enabled. I can set neither, one, or both, in the array passed to comment_driven_save, and those two fields are always set to null in the resulting revision - although, as stated, the diff table shows them set to today.

An inspect on the diff table shows the following:

diff_values - Today is shown as the new value.
cck:field_equipmentlastsrvtime (-) array ( 0 => array ( 'value' => '2010-10-01 00:00:00', ), )
cck:field_equipmentlastsrvtime (+) array ( 0 => array ( 'value' => '2010-10-17 09:16:09', ), )
cck:field_equipmentlastusagecount (-) array ( 0 => array ( 'value' => '9000003', ), )
cck:field_equipmentlastusagecount (+) array ( 0 => array ( 'value' => '9000004', ), )
cck:field_equipmentlastusagerecorded (-) array ( 0 => array ( 'value' => '2010-10-01 00:00:00', ), )
cck:field_equipmentlastusagerecorded (+) array ( 0 => array ( 'value' => '2010-10-17 09:16:09', ), )

Frozen and Live render both show today as the new value as well.
Live comparison shows the two date fields (lastsrvtime and lastusagerecorded) as both set to null.

Debugging aimlessly for the next few hours... :)

obrienmd’s picture

obrienmd commented

More info - If I set the other date field (lastsrvtime) disabled for comment_driven in node type driven properties, any usage of comment_driven (both via form and in code) results in 'The dates are invalid'.

obrienmd’s picture

obrienmd commented

I have been dumping variables all over comment_form_alter and comment_driven_submit in comment_driven.alter.inc, but the date variable passed looks fine at the end of comment_form_alter, and value is boolean NULL at the beginning of comment_driven_submit... so something in the middle is wrong, but I just don't know where to start!

obrienmd’s picture

obrienmd commented
Status: Active » Fixed

ksenzee helped me solve this one, looks like you have to set $node['field_equipmentlastusagerecorded'][0]['value']['date'] property rather than $node['field_equipmentlastusagerecorded'][0]['value']

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.