Closed (won't fix)
Project:
Webform Associate
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
26 Apr 2009 at 08:59 UTC
Updated:
19 Sep 2010 at 13:26 UTC
Jump to comment: Most recent file
Comments
Comment #1
jdwfly commentedSame issues here, but I am using the most recent dev version of the project. I can access the components part of the webform though.
I started messing with your code and found that your If statement on 51 might be the culprit. It seems as though it's always false which takes you down to the else which returns false.
It seems as though the function is not being passed the $node->nid value. This is the third argument in line 48. Thus when you give that a default value of NULL this problem goes away, but you still have the problem that your If statement does not work because $node is now NULL by default.
Comment #2
jdwfly commentedI made a patch that allows the superuser (UID = 1) to be able to view the pages. I took a look at the code but I couldn't figure out why it was not working. This will allow the superuser to view the submissions, analysis, etc.
NOTE
This patch was made off of the current dev release.
Comment #3
jdwfly commentedComment #4
jdwfly commentedI just noticed that the patch I submitted does place Local Tabs into nodes that do not have a webform associated with them. As I said before this is not a complete patch, but it does allow you to look at results.
I'll try to see if I can iron this out properly.
Comment #5
jdwfly commentedAll right, I finally went to see what changed in the Webform module. Looks like they decided to change one simple word in their menu structure and that broke the menu alter function in this one. This patch should allow users with appropriate permissions to access the submissions, analysis, tables, downloads, etc.
Comment #6
shaisachs commentedI agree with the basic diagnosis in 5, but disagree with the patch. The latest webform module (2.9) uses both webform_submission_access and webform_results_access as access callbacks, so webform_associate should anticipate both. I believe my patch in #358252: error in webforms: 'Missing argument 3 for webform_associate_menu_access' correctly addresses the problems, both in that queue and in this one.
Comment #7
eusebius commentedThe patch from jdwfly in #5 worked in solving this for me, at least as far as I can tell.
The patch referenced in #6 did not work for me.
Comment #8
eclipsegc commentedThe features of this module are now included IN webform 3.x. This module is now obsolete.