If I make any changes to a driven property (CCK, node, etc...) in a comment, those changes persist through comment previews and validation, but are not saved when the comment is submitted. The driven properties on the parent node are not updated.

Poking through the code, it looks like just about anytime that $form['#node']->type is used, it's set to comment. Obviously it should be set to the parent node's content type. Any idea how to trace down what might be causing this?

This is on a custom content type in Open Atrium. The only other comment-related module in use is team notifications.

Comments

danepowell’s picture

I should clarify: this specifically is a problem in comment_driven_diff_form_state, where $ned_form['#node']->type is set to comment, and so no driven properties are loaded.

I can also offer this: $node_type and $driven_props both look correct in _comment_driven_proceed_comment_form_alter. However, $form['#node']->type is already set to comment when it is passed to comment_driven_form_alter, and never gets set to the new node type.

danepowell’s picture

Title: Changes not saving: $form['#node']->type not set correctly » Incompatible with iTweak Upload

Nailed it- iTweak Upload is the module that sets the type to 'comment', which in turn interferes with Comment Driven. I have no idea which module is "at fault" here, but I'd love to hear from a maintainer so this can get fixed. Since iTweak Upload ships with Open Atrium, this is going to affect any OA installation, i.e. a lot of users.

arhak’s picture

Priority: Normal » Major

don't know where the fault resides, but definitely this is 'major' for OA

iTweak Upload is the module that sets the type to 'comment'

how did you figure?
I just reviewed the code I didn't saw anything like it (version 6.x-2.3 BTW)

however the '#node' key is used to keep a version of a node, therefore its type shouldn't be 'comment'

I'm now recalling #855312-6: Pass full node to implementations of hook_mailhandler_post_save
thats a place where a node isn't actually a node, but sometimes a comment
and I quote: "depending on $node->type"

danepowell’s picture

I put a dpm() in the drupal_alter() core function to spit out the form data each time hook_form_alter was invoked, and it wasn't until immediately after itweak_upload_form_alter was called that the type changed to comment. To be fair, it's possible that iTweak Upload isn't directly responsible, but calls some other function in another module that breaks things.

But as soon as I disabled iTweak Upload the problem went away- the proof is in the pudding, eh?

I don't have Mailhandler installed on this site, so I don't think that could be responsible, if that's what you're implying.

arhak’s picture

I don't have Mailhandler installed on this site, so I don't think that could be responsible, if that's what you're implying.

that was what I was thinking, but now I see you're using a different setup

so, it is iTweak (either directly or indirectly)

arhak’s picture

This is on a custom content type in Open Atrium

what kind of "custom"? module provided or built through CCK's GUI?

danepowell’s picture

The content type is "ct_plus_task", a replacement for Case Tracker Cases, which I built through the GUI and then put into the following feature:
http://danepowell.com/node/122

budda’s picture

Category: support » bug

I tried with iTweak disabled and enabled and had no success with either way when submitting a comment that updated CCK field values.

obrienmd’s picture

OK, now that I'm back working on OA projects... I'm having this same problem. Testing now if it will be fixed by disabling iTweak upload...

Verified - Disabling iTweak upload _somehow_ solves the problem. Having worked with Dane before, I'm pretty sure I don't need to double-check his debugging tests :)

danepowell’s picture

Just FYI, I've had several confirmed reports now in the CTPlus issue queue and elsewhere of this problem occurring and being solved by disabling iTweak Upload.

obrienmd’s picture

I can also confirm these findings (#10), more than 5 Atrium sites with different configs all solved this issue by removing iTweak upload.

mikyter’s picture

After looking at the code I found out that iTweak upload sets $form['#node']->type always to comment when the form id is comment_form. It stores the node type in $form['#node']->parent_type.
It does this so _itweak_upload_upload_form_prerender() knows the user submits a comment. Maybe the function could be changed to check the form_id just as the hook function.

danepowell’s picture

So is this more properly an issue with iTweak Upload? i.e. should it be moved to that queue?

mrfelton’s picture

subs

danepowell’s picture

Title: Incompatible with iTweak Upload » iTweak Upload breaks Comment Driven
Project: Comment driven » iTweak Upload
Version: 6.x-1.0-alpha3 » 6.x-2.4

iTweak Upload seems to be stepping on the toes of other modules, as mentioned in this issue...

iva2k’s picture

Status: Active » Needs review

I looked into the issue and code, and came up with changes that should fix the problem. I committed those to 6.x-2.x-dev (right after new 6.x-2.5 release). Please verify that it fixes this problem and does not create any other issues and post here.

iva2k’s picture

Status: Needs review » Fixed

No activity for over 4 weeks. Please reopen with detailed explanation how to reproduce if the issue still exist with 6.x-2.x-dev.

Anonymous’s picture

@#16 it works fine, thanks.

Status: Fixed » Closed (fixed)

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

ergonlogic’s picture

Project: iTweak Upload » Comment driven
Version: 6.x-2.4 » 6.x-1.x-dev
Status: Closed (fixed) » Needs review
StatusFileSize
new679 bytes

While hardly the most elegant solution, this could be fixed by special-casing iTweak Upload, as per the attached patch.

danepowell’s picture

FYI, I think the commit referenced in #16 fixed this on my installations, and it seems to have worked for other users as well. I'm not sure why another patch is needed.

ergonlogic’s picture

Project: Comment driven » iTweak Upload
Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Needs review » Closed (fixed)

This is indeed fixed in 6.x-2.x... I missed the "after new 6.x-2.5 release"