Closed (fixed)
Project:
Node access node reference
Version:
6.x-1.0-beta2
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
29 Jul 2009 at 08:18 UTC
Updated:
30 Dec 2010 at 08:00 UTC
When i try to rebuild permission i got this error. Cold be that this module is in conflict with other permission modules?
An error occurred. /batch?id=11&op=do { "status": true, "percentage": 0, "message": "Remaining 1 of 1.\x3cbr/\x3e\x26nbsp" }<br /> <b>Fatal error</b>: Allowed memory size of 134217728 bytes exhausted (tried to allocate 9437256 bytes) in <b>Unknown</b> on line <b>0</b><br />
Comments
Comment #1
vistree commentedHi, I have exactly the same problem. I try to use together with nodeaccess and Node Access User Reference. Is there a way to solve this behaviour?
Kind regards
Comment #2
alvinet commentedAt this moment i haven't find any solution.
Trying to disable node access module doesn't solve the problem.
Comment #3
danielb commentedTry lowering that nodes per request number in the module's settings? How many nodes and users do you have? If you set that nodes per request setting to 1 and it still won't work - well ... I dunno... to update each node, this module must load every node of the types that can have node references, and load every user to see if they should be allowed - quite an expensive operation and if it turns out to be problematic perhaps we will start having to break it down to how many users to process at a time as well.
Comment #4
vistree commentedHi danielb,
I tried to use the module with just a fresh content type with only one test page. Having 5 users, only one is referenced in this node ....
OK, I will try the settings you mentioned.
Regards
Kai
Comment #5
vistree commentedHi again,
OK, I changed the limit from 20 to 1 and now the rebuilding of permissions work!
But, I have one question now - using your nodereference module, are only linked child nodes automatic visible or also the parent note?
If I have 3 content types:
Person, Contract and Note
Contract contains node- and userreference --> nodereference contains the name of a person
Note contains a nodereference --> to contract
If there is a link from contract to USERx, USERx can see the contract and the child note, but not the person linked in contract. Is this correct??
Is there a way, that the FIRST parent is also visible (but no other childs of the parent??).
Kind regards
Kai
Comment #6
kenorb commentedAre you sure that it was not caused by PHP memory exceeded?
Try to increase your PHP memory limit.
Method 1: http://drupal.org/project/drupal_tweaks
Method 2: http://drupal.org/node/40965
Comment #7
alvinet commentedi think that 128MB memory limit is enought... Don't you think?
Comment #8
kenorb commentedAh, ok.
It's probably it caused by some recursion depth.
Comment #9
danielb commentedany success alvinet?
vistree I don't understand your question it's confusing and you might need to experiment, also it's not really on the issue of memory problems.
Comment #10
hefox commentedTo my understanding the reason this module is so complicated and intense is the need to consider node modules like blog, etc.
an idea for a "light" node reference node_access that doesn't pay attention to node modules
something like
foreach nodereference as nid
$grants = node_acquire_grants(node_load(nid));
(or maybe
db_query('SELECT * from node_access where node = %d',nid); etc.
// then some further checking if node access module is not in use, ie access for $user->uid,
)
// set grants to grants, alter based on 'view', 'edit', 'delete' settings
return $grants
Less processing time perhaps mm!
Comment #11
danielb commentedthere is probably a way to do it using an idea along the lines of node_db_rewrite_sql except with the custom table this module creates not the node_access table. Might be able to reduce the looping calls to user_access() and do fewer queries. The real pain is that to do a call to user_access() you have LOAD the user and LOAD the node, which is where all the memory goes.
Comment #12
danielb commentedThis module is changing significantly and this issue may no longer apply in future