1st question:
I have 2 node references on a content type. Is their a way to make naar ignore one of the node ref fields so it doesn't use it to grant permissions?
Field1 references the content profile of the person I want to give access too.
Field2 references the content profile of the person I am talking about in the node (don't want to give access).
2nd question:
Is their a way so that naar will ignore node-reference-field1 if node-ref-field2 is filled out?
Comments
Comment #1
kenorb commentedCurrently not.
Some workaround could be to override permission by: hook_node_access_records() in your module and set the module weight higher than NAAR.
Then make the condition to return always FALSE when specified field is in the path connection (nodeaccess_autoreference_find_connection())
Comment #2
that0n3guy commentedI created a patch that I would like you to look at (attached). It does a few new things:
- Adds the ability to disable NAAR on specific fields. (fixes this issue)
- Adds the ability to enable reverse checking on spacific fields (please note I added this then never tested it out)
- Adds the ability to set nodes as private (ie no NAAR checking unless through defined fields, see example below)
- fixed this http://drupal.org/node/910614 with kind of a hack
- adds the ability to enable owner checking only through content profiles
How to use the "private" feature:
Example setup:
-3 referencing fields: field_project, field_proj_manager, field_member
-field_project is on a "task" content type and it references a project content type
-field_proj_manager & field_member reference content profile content types.
-the referencing looks something like:
task1->project1->proj_manager(content profile of user2)
project1->member(content profile of user3)
To show you how this works I will have to use an example. You have a project node (project1), then a task node (task1) that references it through a called field_project. Project1 references the content profile of user2 through a cck field called field_project_manager.
Project1 also references user3's content profile (I'll call it user3_cp) threw a field called field_member.
On "task" content type I have a "select" text field called field_private. I can select "yes" or "no" (yes meaning I want the field to be private, no meaning normal. In the text fields settings I mark it as being a "private" selector for NAAR. If this select field is set to "yes" then NAAR will be disabled for all ref fields on that node...UNLESS the field is permitted in the NAAR settings (admin/settings/nodeaccess_autoreference).
So for my example, I'm going to allow private fields to use fields field_project and field_proj_manager in the settings.
User2 and User3 can view both task1 and project1. I create task2 but make it "private", now only user2 and I can see task2 because NAAR is ignoring field_member.
Comment #3
kenorb commentedFollow-up: #754164: Feature Enhancement Patches
Comment #4
kenorb commentedIGNORE THIS PATCH.
Comment #5
kenorb commentedI couldn't apply attached patch against HEAD version, so I done some small clean up.
Comment #6
kenorb commentedTagged previous version with: DRUPAL-6--1-1-BETA1
In case of any issues.
Committed to HEAD:
http://drupal.org/cvs?commit=437820
Comment #7
that0n3guy commentedKenorb,
I finally got some time to test out the "reverse referencing on a per field basis" and it doesn't work. I didn't look at this code as I don't really have that much time to do so.
I figured since your familiar w/ the reverse ref code you may be able to get it to work quickly. Do you think you could take a quick look at it?
Comment #8
that0n3guy commentedKenorb,
You can forget my last comment :), I had some time after all. Attached is a patch that cleans-up and fixes some of the variables.
I also got reverse checking for specific fields working. It doesn't work for views though. For the node to show up in views you have to go to the node first, then it will show up in a view.
I have no idea how to fix the views thing. Can you look at that?
Thanks,
Peter
Comment #9
that0n3guy commentedHere is the same patch w/ some modifications, the one in #8 acted funny. This one is better:
Comment #10
that0n3guy commentedA couple of items that should have been in patch #9:
At about line 162 of .module, we should have a:
right in front of
$reverse = nodeaccess_autoreference_reverse_check($node);Also, line 62 of the patch should be:
Comment #11
that0n3guy commentedOk, so after some more testing, that patch causes some issues...
Comment #12
kenorb commentedThanks for the work.
Sorry for late reply.
How you solved that issue?
Comment #13
kenorb commentedClosed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.