I removed a node reference set up with the na_nr. There are still other content types using this field.

Every time I rebuild content permissions, this error is thrown:

user warning: Not unique table/alias: 'project_bug' query: SELECT n.nid FROM node n INNER JOIN content_type_project_bug project_bug ON n.vid = project_bug.vid INNER JOIN content_type_project_bug project_bug ON n.vid = project_bug.vid INNER JOIN content_field_project field_project ON n.vid = field_project.vid WHERE project_bug.field_project_owned_nid IS NOT NULL OR project_bug.field_component_nid IS NOT NULL OR field_project.field_project_nid IS NOT NULL in sites/all/modules/nodeaccess_nodereference/nodeaccess_nodereference.module on line 397.

CommentFileSizeAuthor
#4 nodeaccessrebuild.patch918 bytessnufkin

Comments

RoboPhred’s picture

RoboPhred commented

I am also getting this error when viewing the node containing the changed field

user warning: Duplicate entry '8-1-nodeaccess_nodereference' for key 1 query: INSERT INTO node_access (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (8, 'nodeaccess_nodereference', 1, 0, 1, 0) in modules/node/node.module on line 2249.
user warning: Duplicate entry '8-3-nodeaccess_nodereference' for key 1 query: INSERT INTO node_access (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (8, 'nodeaccess_nodereference', 3, 0, 1, 0) in modules/node/node.module on line 2249.
user warning: Duplicate entry '8-530-nodeaccess_nodereference' for key 1 query: INSERT INTO node_access (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (8, 'nodeaccess_nodereference', 530, 0, 1, 0) in modules/node/node.module on line 2249.
user warning: Duplicate entry '8-759-nodeaccess_nodereference' for key 1 query: INSERT INTO node_access (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (8, 'nodeaccess_nodereference', 759, 0, 1, 0) in modules/node/node.module on line 2249.

RoboPhred’s picture

RoboPhred commented

Uninstalling and re-enabling the module did not remove this issue. However, the error disappeared when I pulled the -dev version and ran the content permission rebuild again. I do not think this is related though.

The actual nodeaccess_nodereference_fetch_nodes_sql will still have issues of content_fields() returns the same field multiple times, perhapses if the content type specific settings are different between types?

psynaptic’s picture

psynaptic commented

I am getting this error too: http://bit.ly/clBupq

snufkin’s picture

snufkin commented
StatusFileSize
new nodeaccessrebuild.patch918 bytes

I am not sure what this patch does, but seemed to solve the problem for now. We are still getting errors on rebuild about duplicate inserts, but at least nodeaccess now works as intended.

psynaptic’s picture

psynaptic commented
Status: Active » Reviewed & tested by the community

Yep, we still get errors when we rebuild but it actually works now when it didn't work before.

Could someone who knows this module a little more intimately have a look into this please?

snufkin’s picture

snufkin commented
Status: Reviewed & tested by the community » Needs review

Should be still in review stage imho, since we have no clue whats happening :)

danielb’s picture

danielb commented
Status: Needs review » Active

I don't agree with the patch. That code is there to check whether the site is in a particular state. The patch changes it so that it always says "yes it is". If that logic change happens to be correct, then it would be better to remove that static function, references to it, and that if statement, completely - but I would think it is necessary to keep those. It may seem like it works to you now because of the order you created your test nodes in, but reverse them and I bet it won't.
I don't understand why there is a duplicate error, I would have to reproduce the problem.

snufkin’s picture

snufkin commented

Yeah, I had the feeling that this bypasses some stuff it shouldn't, but I think that logic is broken then.

Here is how you can easily reproduce: set up two content types, one with user reference, one with nodereference. Install nodeaccess_userreference as well (without the nodeaccess_userreference I could not reproduce). Create one node of each type. Add a test user to the userreference, and the second node should refer to the first one. If you pop devel node access open, it will show that a user 0 entry has been added for the second node (the node with userreference works perfectly) and nodeaccess_nodereference entries are marked as 'alien'.

danielb’s picture

danielb commented

Hmm that is interesting that you have nodeaccess_userreference as well, I could potentially see a conflict between those two modules. I would have to look into it though.

snufkin’s picture

snufkin commented

I have the feeling that it would fail if you have any sort of acl on the master node, but haven't had much time to test this yet. But the reason why i think its not necessarily the useraccess' fault is that forcing this rebuild sort of thing I managed to get it to work.

I would love to help if you could explain a bit what the current code does when it does this static checking.

bobodrone’s picture

bobodrone commented

subscribe

danielb’s picture

danielb commented
Status: Active » Fixed

This module is changing significantly and this issue may no longer apply in future

Status: Fixed » Closed (fixed)

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