Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I've created a new type of content (with nothing else, just a simple new type of content). Then I change this type into an Assigment type. I tried to create a content of that type and add an attachment. And it seems to work until I save it. After save it the attachment have been uploaded but It doesn't appear to be attached to the node. I've been looking the permissions and the configuration and all seems to be right.
I tried to disable as an Assigment type and add an attachment to the node and works. If I restore the Assigment type (after save correctly with the Attachement the attachment appears).
It's seems that something is failing when Gradebook tries to save the node with the attachment.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 404718_form_fix.diff | 2.04 KB | MGN |
Comments
Comment #1
MGN commentedChanged the title to avoid confusion with gradebook file attachments (which are not attached to nodes). I have been able to verify this bug. The problem must be with the way gradebookapi is handling hook_nodeapi. I'll look into it and post a patch as soon as I can. Thanks for reporting it.
Comment #2
MGN commentedIf you change the weight of the upload module in the system table to 1, file attachments to assignment nodes work correctly. I am not sure why upload_nodeapi($op='view') has to be called after gradebookapi_nodeapi($op='view'), but it seems to be the case.
Comment #3
manolopm commentedMmm no, the problem still there. I look into upload table and there isn't any entry associated to the node.
Comment #4
MGN commentedInteresting, on two test sites (one with og_gradebook, one without) and with or without any of the gradebook submodules, attachments to assignment nodes work fine as long as I have the weight of the upload module greater than gradebookapi.
I will keep looking into this problem, but don't have another solution at this time. If anyone wants to help track this problem down, I would appreciate it. It really looks like its the order in which nodeapi is called, so the first place to look is gradebookapi's nodeapi function....
Comment #5
manolopm commentedOk, I try some values to the weight and it seems to work for me with weight=3 (maybe because og_gradebook has weight=2?). As temporal solution works for me but I'll try to find a better solution looking the code to find where is the problem.
Comment #6
MGN commentedJust trying to better document the problem...
When the weight of the upload.module is not greater than gradebookapi.module and og_gradebook.module, file attachments to assignment nodes fail. The file is uploaded (appears in the files directory) and an entry is added to the {files} table, but there is no corresponding entry in the {upload} table.
So the problem is not in the $op='view' operation, its in the $op='update' and/or $op='insert'. I am wondering if it might depend on the order in which the edit form submit functions are called...
Comment #7
MGN commentedI think I found the problem. Form elements were added via hook_form_alter using php array_merge. This function will overwrite array elements with the same (string) keys. To avoid this, I sum the form arrays instead, which appends data with duplicate string keys. In this case, it appears that the upload.module $form['#submit'] was being overwritten. It makes sense that adjusting the upload weight so that its hook functions are called after these functions would fix the problem.
This affects all the gradebook hook_form_alter functions that act on assignment nodes. I don't believe that og_gradebook is affected.
Attached is a patch for the 6.x-2.x-dev version. Please let me know if this solves the problem. If so, I'll commit the patch.
Comment #8
manolopm commentedI've been reading the code of gradebookapi and upload modules to reach the same conclusion. I've tried the patch and works perfectly.
Thanks
Comment #9
MGN commentedThanks for the feedback. Committed to 6.x-2.x-dev.